On projects and their goals

Posted Apr 7, 2010 6:52 UTC (Wed) by Yenya (subscriber, #52846)
In reply to: On projects and their goals by eru
Parent article: On projects and their goals

I am not sure whether even Subversion can count as a "long-term" solution.

A month ago I have tried to make a modification to a relatively old project which I wrote, and which did not need maintenance until then. It had the source code in a SVN repository. I have discovered that current SVN cannot access the repository of this project because of repository format changes. So instead of spending time trying to determine which intermediate version of SVN (and probably BerkeleyDB) I should compile to access pre-1.0 SVN repository, I have just ditched the project history altogether and imported the current snapshot to Git. I am well aware that five years from now I may have the same problem (but then, reading the SVN mission statement, they discuss a yet another repository backend there, so SVN would not help either).

On projects and their goals

Posted Apr 7, 2010 8:03 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

SVN has been extremely backwards compatible: there hasn't been an incompatible repository
format change since version 0.34 in December 2003. (And 0.28 before that). Those were done
when svn was basically still being designed, pre-1.0. It seems a bit overreaching to fault them for
dropping compatibility a couple times in their pre-release infancy!

See:
http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

It has links where you can grab the source for the old versions, even.

On projects and their goals

Posted Apr 7, 2010 10:05 UTC (Wed) by Yenya (subscriber, #52846) [Link]

If I can remember correctly (I no longer have the said SVN repo), it said that the version 1 repo is not supported, only versions 3 to 5 are. And yes, 2003 is probably the correct time frame. The GP post said something like migrating repo from early 1980s, which I doubt would last so long with either SVN (the new repo format is already being discussed) or Git. The later is more feasible, though, because the data (commits and trees) are in plain text form.