Looking Past CVS: The Future is Distributed

Posted Dec 2, 2004 13:35 UTC (Thu) by ncm (subscriber, #165) [Link]

The cure for fear is learning.

We have a lot of experience with CVS, and know what problems it has, and some people have good ideas of how to fix them. A distributed system is easy to make work centralized, but the reverse has not been demonstrated. CVS's flat files are reassuring, but Arch's are no less so. What's different is that if you mv a CVS file you have made it impossible to reconstitute, or branch, old versions.

Monotone puts its stuff in a database file, but that's easily extracted as a text file and operated upon. It doesn't depend on setting up http servers or anything. Subversion puts its in a bdb file, though, which makes me a bit queasy too. It can use a DAV server attached to Apache, but it doesn't need it.

Certainly these are not mature systems. There are lots of things to tune or add. The only way to know what they need is to use them, and discover it, and then code it. Some may take the wrong path, but at least one will emerge as industrially ready. They will keep one another "honest", because anybody who cares enough can compare them, and the laggard will either stagnate or adapt. CVS may be familiar, but it's also practically impervious to improvements. The code has just got too crufty, and the design is not compatible with improvements; it stagnated long ago.

Someday soon you'll be as comfortable with one of the new ones as with CVS, and the thought of going back to CVS will make you queasy instead.

Posted Dec 2, 2004 16:37 UTC (Thu) by gdt (subscriber, #6284) [Link]

Well, why should the future of SCM's be distributed?

Because it's an easy feature to add. The fundamental change isn't the move from centralised to distributed source management, but the change in emphasis from files to patchsets. Once you've got a patchset-oriented configuration control system then you get the distributed feature for near-free.

And the future of CCS's is patchsets, it's simply a better paradigm.

...a good idea to have one central server where the current official version of the sources lives

And a distributed CCS gives you that. But what you also get is the ability to trivially take a copy of that "official" source and modify it. When you are done you can provide a set of changes back to the official source, a set of changes which the official maintainer finds simple to integrate. And it's this trick that CVS doesn't do well. As a small experiment, take a copy of a CVS tree of a big project, spend a month working on a change, and see how hard it is to patch back to the official-but-improved CVS.

I really have trouble with your notion that CVS is easy to set up. I've found it near-impossible to securely configure an anonymous CVS which allows a few maintainers to update the repository.

In a large company SVN leveraging off Apache is a good thing. Sysadmins already have authentication and authorisation configured for Apache and extending this to SVN is trivial. So you get to use your "real" userid and password. And it runs over HTTPS no there's no fiddling about with SSH tunnels and craziness.

The opaquness of the SVN repository is a practical problem, especially if you want to invisibly repair a stuff up (such as creating a directory tree in the wrong place, something SVN's syntax makes easy to do). Once you've got a big repository the only choice is to pretend the error was a project change. I imagine you can check out a revision of /branch rather than /${project}/branch out of most SVN repos.

To my mind the problem with the new batch of systems is that they don't play nicely together. When CVS was the only free game in town, all the interesting tools which add value to the configuration control system worked with CVS. But now there's no single interface for tool writers to target. The IETFly-correct might target DeltaV, but there's no real support for that protocol outside of SVN.

Configuration control brings some basic programmer productivity gains. But to improve process productivity we need tools which work on top of the CCS. Stuff that answers questions like "which module costs the most to maintain", "how long did it take to make change request Blah", "who is responsible for the change that broke the nightly regression tests". At the moment there's no viable target for authors of those interesting tools to aim at, and there seems little interest by the authors of this generation of CCS in interoperation or standardised interfaces.

Posted Dec 2, 2004 17:13 UTC (Thu) by Wummel (subscriber, #7591) [Link]

Regarding your fear of putting the data in a database: since version 1.1 subversion has a plain file backend.

Posted Dec 2, 2004 22:38 UTC (Thu) by iabervon (subscriber, #722) [Link]

IMHO, the biggest advantage of a distributed SCM is the ability to version control things that don't work yet. If you're working on a big project with a lot of people, and you need to make a change which will take three days and not build successfully while you're working on it, and you're using CVS, you can't check in each of the steps or check in each day's work without breaking the tree for everyone else. This means that you don't end up with a good commit message (set), because you've got changes in there that you haven't thought about for days, and you have to make sure you don't mess things up. If you accidentally delete something in the evening that you wrote in the morning (assuming overnight backups), you have to redo it.

With a distributed SCM, you can check in each logical change to your own subrepository, and then check your complete set into the official repository when it works. A distributed SCM doesn't mean that there isn't a central server; it means that there isn't *only* a central server.