Slashdot Mirror
Tom Lord's Decentralized Revision Control System
Bruce Perens writes: "He'll have to change its name, but Tom Lord's arch revision control system is revolutionary. Where CVS is a cathedral, 'arch' is a bazaar, with the ability for branches to live on separate servers from the main trunk of the project's development. Thus, you can create a branch without the authority, or even the cooperation, of the managers of the main tree. A global name-space makes all revision archives worldwide appear as if they are the same repository. Using this system, most of what we do using 'patch' today would go away -- we'd just choose, or merge, branches. Much of the synchronization problem we have with patches is handled by tools that eliminate and/or manage conflicts -- they solve some of the thorny graph topology issues around patch management. Arch also poses its own answer to the 'Linus Doesn't Scale' problem. This is well worth checking out." If you're asking "What about subversion?", well, so is Tom.
Here is a comparison to cvs
Subversion was deliberately designed to address CVS's shortcomings, not to break new ground. Our philosophy was essentially conservative: CVS basically works, but has some bugs and maintainability problems. Let's keep the model and fix the problems. Result: Subversion.
The ideal situation is a world where both models have good, free implementations. Then we'll all very quickly find out which model works better. :-)
-Karl
http://www.red-bean.com/kfogel
Adds renaming over top of CVS and some other niceties. Can be used to create patches that contain versioning changes. With Meta-CVS, people can restructure directories in conflicting ways, and then resolve conflicts when they merge the structure.
http://users.footprints.net/~kaz/mcvs.html
This doesn't add anything else; no atomic commits or distributed operation over multiple repositories, etc.
Of course, you can use branches to track foreign code streams, as you can with CVS. The nice thing is that you can rename things on your own branch and keep up with an unrenamed source of patches. Or if the other people are using Meta-CVS, they can give you patches that include restructuring.
Meta-CVS is currently about 1600 physical lines of Common Lisp (with some CLISP extensions and bindings to glibc2) scattered in twenty or so files. A lot is done with little!
CVS hasn't invoked rcs or diff or anything for ages.
Infuriate left and right
I'm surprised this one got modded up. The poster clearly knows nothing about the topic; it's just an ignorant flame.
In case anyone's wondering, arch supports and uses write permissions; however, it also allows you to start your OWN server, and people can hook up to it in parallel with the main server, and get all the branches which appear on either.
You can commit all the crashy code you want on your own server, but it won't affect anyone who isn't using your server.
The genius is that your server is hooked up to the original server, live, and you can track the changes they make, merging when and where you like. If the project manager for the original server feels like it (and if you let him), he can track the changes on your server as well. If someone else has started their own branch server, you can merge directly with them as well.
VERY clever.
Although I don't dig the Subversion trashing; Subversion is also very cool for its own purposes. I'm glad Tom took the time to underline the differences, but I'm unhappy that the result is so slanted. It didn't need to be: both arch and Subversion stand on their own as superb projects, and there's even another one coming out of IBM "sometime" which has its own merits.
-Billy
Excellent point; poorly worded on my part. In general, your statement ought to be true about all version number schemes inside a repository. (Cederqvist, section 4.3)
Labels are our friends. Though, I've actually heard people using phrases like "We're modifying the 1.19.3.4.7.x branch today." That doesn't convey a lot of meaning.
However, based on real world practices, people tend to use revision numbers as version numbers. They shouldn't. And there is a difference between the two. Your point illustrates that well; thank you for raising it. I'd like to think Sun didn't tweak their internal revision numbers to mirror product version numbers.
Where I was going was, if numbers are going to be used to convey repository structure, it should be hack free. If revision numbers are going to be used to convey information, the user should have control over what gets used. The reserved use (which personally I like), in CVS's case came from [Cederqvist section 13]. PVCS is pretty darn good about giving the right level of control for those who want to twiddle numbers directly.
I'm simply saying it's up to the person running the repository to decide -- ideally they should have a clue of what works well.
You'd think that using an rdbms would give you lots of control over your source tree, but think again. Any decent rcs works incrementally- i.e. you are storing deltas, not always whole lines of code.
The indices (stuff this "indexes" crap) would be really bad and slow on all your tables.
Also RDBMSs suck at representing hierachies, which source trees naturally are. In fact, I dare say the only reason that RDBMSs are so widespread and accepted today is that originally it was much faster to do this rather than use an OO, hierachical way of doing things.
The way you store things has to be written specifically so that it fits in with the way projects work and evolve.
Forgive the lameness. Haven't had my 2nd coffee of the day yet...
graspee
Well, it's not *entirely* in sh:
Totals grouped by language (dominant language first):
ansic: 61064 (66.48%)
sh: 27853 (30.32%)
lisp: 1868 (2.03%)
awk: 1044 (1.14%)
sed: 24 (0.03%)
(If you want more detail, run sloccount over it yourself)
Anyay, it could be worse; it could be written in Perl ;)