User: Password:
|
|
Subscribe / Log in / New account

Looking Past CVS: The Future is Distributed

Looking Past CVS: The Future is Distributed

Posted Dec 2, 2004 13:07 UTC (Thu) by aleXXX (subscriber, #2742)
Parent article: Looking Past CVS: The Future is Distributed

Well, why should the future of SCM's be distributed ?
I know more or less nothing about distributed SCM's, but I think it is a
good idea to have one central server where the current official version
of the sources lives. If you need the current version, get it from this
server. Which advantages do distributed systems offer ?

One thing about cvs: it has some problems, these problems are know. It's
damn easy to set up, run it's daemon, and all files exist as plain text
files on the server. If something goes wrong, you can just go and delete/
move/rename/whatever the files on the server directly.
That's currently my main "fear" of svn: I read about the installation,
and found something about apache, LDAP (or was it WebDAV ?, I'm no expert
in these topics) and that the sources are kept in a database.
So if I would switch to svn, I would switch to a SCM which does a lot of
things I don't understand and where I can't "debug" stuff. So I'll stay
with cvs for the near future.

Alex


(Log in to post comments)

Fear of the future

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.

Looking Past CVS: The Future is Distributed

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.

Looking Past CVS: The Future is Distributed

Posted Dec 9, 2004 22:23 UTC (Thu) by anton (subscriber, #25547) [Link]

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.

If you find that hard, don't do it. Give accounts to your maintainers, and let them use it with ssh.

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.

It runs over what? Our sysadmin wouldn't know how to make Apache authentication use our "real" userid, and I don't know it, either.

We have sshd running on every server, and Apache on exactly one, and that's a pretty crufty machine, where Subversion is guaranteed not to install (it's even too picky for my Fedore Core 1 AMD64 box, and my bug report about that to users@subversion.tigris.org vanished in the void).

In contrast, using CVS over ssh is easy and trouble-free, and I don't even have to use a password (thanks to .ssh/authorized_keys). No tunneling necessary, just set

export CVS_RSH=ssh
and use a command like the following for checkout
cvs -d :ext:user@host:root-path checkout directory
Any chance that svn will ever be as convenient and simple?

Looking Past CVS: The Future is Distributed

Posted Jan 24, 2005 19:11 UTC (Mon) by jhohm (guest, #7225) [Link]

export CVS_RSH=ssh
cvs -d :ext:user@host:root-path checkout directory
Any chance that svn will ever be as convenient and simple?

How about this:

svn checkout svn+ssh://user@host/root-path directory
I'd say that's just as convenient and simple.

Looking Past CVS: The Future is Distributed

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.

Looking Past CVS: The Future is Distributed

Posted Dec 2, 2004 17:55 UTC (Thu) by vmole (guest, #111) [Link]

But the files are hardly transparent. Which isn't to imply that the FSFS backend isn't a useful thing, but it's not equivalent to the CVS flatfiles.

Looking Past CVS: The Future is Distributed

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.

Looking Past CVS: The Future is Distributed

Posted Jun 26, 2005 16:34 UTC (Sun) by HR (guest, #30682) [Link]

=====
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
=====

The way we handle this situation in CVS (committing changes that span days to complete) is to create a private branch for the intermediate work. When you're done you just merge that branch or, if it doesn't work out, you can simply abandon the branch. Either way you can source control your work along the way.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds