On projects and their goals

Posted Apr 6, 2010 3:36 UTC (Tue) by eru (subscriber, #2753)
Parent article: On projects and their goals

Developers looking for fast-moving, distributed systems have a variety of offerings to choose from. Subversion, instead, will focus on what it does best: better serving the users that it has now. It seems entirely likely that there will be quite a few of them for some time yet.

Indeed. Version control systems can live a very long time, because they hold long-lived data, and migrations are inconvenient and risky, especially in large organizations with thousands of developers. I know of one big company that is gradually moving to Subversion as its standard version control system. The system it is mostly replacing is an in-house variant of SCCS that dates back to the early 1980's!

On projects and their goals

Posted Apr 7, 2010 6:52 UTC (Wed) by Yenya (subscriber, #52846) [Link] (2 responses)

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.