Looking Past CVS: The Future is Distributed

Looking Past CVS: The Future is Distributed

Posted Dec 2, 2004 16:37 UTC (Thu) by gdt (subscriber, #6284)
In reply to: Looking Past CVS: The Future is Distributed by aleXXX
Parent article: Looking Past CVS: The Future is Distributed

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.

---

(Log in to post comments)

export CVS_RSH=ssh

cvs -d :ext:user@host:root-path checkout directory

export CVS_RSH=ssh
cvs -d :ext:user@host:root-path checkout directory

svn checkout svn+ssh://user@host/root-path directory