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.

POSIX!

In his FAQ he states it works on any system that's POSIX compliant.

/me high-fives Tom

why FTP?

I guess I'm wondering why arch uses FTP as its network protocol. The FAQ says that it should be workable behind firewalls since the data is all transferred in passive mode, but this still seems like a huge step backwards.

So, what am I missing? I only got to read a little bit of the site before it got DDOS'd by slashdot.

Re:why FTP?

I guess I'm wondering why arch uses FTP as its network protocol.
It's because this "Decentralized Revision Control System" is just a guise for a p2p filesharing. It's really cool: you check in all your files and they automatically get replicated, having become part of the "master tree". No one can shut down the master tree. No one can tell you not to put your files there. (Hey, it's part of my project!)
Slick.

Re:why FTP?

hmm...

wouldn't rsync over ssh have been a much better choice for an "off the shelf" component? Most ftp servers tend to have a few (read: waaaaay tooooo maaaany) security concerns for my taste.

And others

Not only 'what about Subversion' but also 'what about CVS, what about Aegis'. If you include non-free systems then what about Perforce or Bitkeeper.

This is getting worse than journalling filesystems :-(.

er...

A global name-space makes all revision archives worldwide appear as if they are the same repository
I don't know whether to laugh or cry...

This sounds like it could be good, if...

I used to work for a company (let's call them ACME, because I don't want to be sued) whose hq was on the other side of the contry, and with programming groups all around the world. We used VSS, with the server at HQ, and it literally took 10 seconds or more to change directories, and much longer to retrieve or update! This hobbled our office's ability to work (HQ didn't care, they just made us work weekends to make up for the loss of efficiency).

A more distributed source control system could obviously circumvent problems like these, but with this caveat: the code that different groups work on would need to be sufficiently black boxed that most changes wouldn't require changes in other projects. It's just good programming style, but I know that this wasn't the case at ACME, and given my experiences with Corporate America I doubt it's true in most places. Maybe I'm just being pessimistic...

Anyway, it sounds like a good idea if it's used right.

As a replacement for patching?

That sounds like hype. In the real world, selecting the aspects of software we want to compile from on remote sites would have serious implications. The first being security. The second being quality. Linus may not scale, but he has good judgement. That's the fundamental problem.

Re:As a replacement for patching?

Whether Alan Cox (or whomever) uses patches or some other source control (like arch) (a) you still have to download the software from a remote site (i.e., the Net) and (b) Alan still has control over what makes it into his repository.

The point is that it allows separate developers (AC, AA, LT, etc. in the kernal case) all to maintain their OWN trees while enjoying the powers of source control software. The added benefit of arch is that their separate trees are all connected without having to give write-permission to each other.

sounds like ClearCASE

The ability to do distributed development, manage multiple (possibly hostile or private) branches at once, good merge and diff tools, etc. sounds sort of like ClearCASE. Except of course that ClearCASE costs money, and doesn't have the global namespace thing going on. Rational had better be careful or their customers are going to move over to arch (especially since their Unix GUIs have sucked more and more with each successive release).

Bravo to the author on this tool - it sounds like a great advance of the state of the art if it works like he says.

Question

Other than CVS and arc, are there any other (GPL)software revision control system available, and how best you rate them ?

Subversion

Call me a dummy but I assumed he meant the possibility of corrupting a distributed global namespace. I presume this features some form of strong authentication system (couldn't reach the site) but it could be pretty hairy if you were doing a make world out of this using any "unofficial" patch sources, but we all audit all the code we run don't we!

ClearCASE

ClearCASE has been doing this for many years now.

Nothing new. not revolutionary...

i know. I'm just an AC, but i am right.

From his faq

On, subversion and arch...

Both systems provide repository transactions with ACID
properties.

ACID (Automicity, Consitancy, Isolation and Durability) is only something that has been implemented and tested well on high read RDBMS such as Oracle.

When you think about that, why is it that no one is using a DB backend to source control? Wouldn't that just get rid of so many ambguities? For one, we wouldn't have to deal with all the nonsence and create a million wheels, when a nice pair of rolls royces resides with a good RDBMS.

People need to think outside their brains, and in regard to source control, I feel we need to make more packages that interface well with a good RDBMS rather than create our own RD functionality in 40ks. What's the use?

Anyone know a good system of incoroprating source control with a databases? Oracle and Postgres would do.

This is pretty nifty

This looks really cool, if only for the fact that it finally has a sane way to rename files. It's annoying renaming, deleting, removing, and adding with CVS.

THIS is why I read slashdot.

I've been struggling with CVS for a while now, and while it does the job I've always been thinking "There's got to be something out there with recursive add built in."

Now here comes slashdot with an actual useful story about source control and some of the options and development outside of CVS.

The only thing to find out now is if the discussion will be of any use, obviously I'm not helping...

Seems like a big step backwards...

It sounds like it has a lot of nice features, but then you realize the whole thing is written in sh? One of the nice things about CVS is that the client-server nature allows someone to use pretty much any operating system as a client. Subversion takes this to the next step, by making all connections use the client-server model.

Forcing everyone to use sh is a major hassle. I know that it would work with any "reasonably POSIX" OS, but then developers can't get arch accessibility built into their favorite tools, like NetBeans or whatever.

Creating local branches is pretty cool, though.

Mike

I can suggest a name

He'll have to change its name, but Tom Lord's arch revision control system is revolutionary.

How about polyfork? Sounds like a great way to give equal weighting to every trivial disagreement over design.

I smell trouble

From the article, it looks good.
But let me say that I've sometimes been in the position of having to merge branches. In my first hacking job, I had to take code that had been written by 2 crazy Polish programmers, and merge 37 non-working branches into one branch that worked. It was *not* fun, and I enjoyed a well-deserved beer when it was done.
IMO, a distributed system of archive management that doesn't make ongoing reference to a central tree is a sure recipe for chaos, and poses the risk of making software harder to install/use for the non-skilled, and creating a lot of work in merging disparate branches for the skilled.

You want package xxyzz? OK - go to Jim's store in San Diego. It's easy to set up. Oh, I forgot to tell you, you've gotta get some bits from Lucy's store in Manchester, and Frieda's fixed a few bugs too - get her fixes from Bonn. And don't forget Peter's enhancements - his store is at the Adelaide University site. What? it doesn't compile? What kind of idiot are you? Just hack it till it does compile, then put it together in your own tree!

is arch CVS compatible (like subversion)?

It is an important feature of subversion that it will be CVS compatible. I manage a 10+ year old/1+GB CVS repository. CVS has a lot of faults, but I can't throw that version history away. It's too valuable. subversion gives me hope that I'll get something more usable than CVS (we'll see, won't we!) without much pain.

I'm really hoping the subversion developers succeed.

Having said that, I'm all for arch succeeding too. Perhaps it will be better for new projects. Who knows.

gasp--a mess of shell scripts

The feature list sounds nice, and using the file system in the way it does is also pretty nice. But I just can't deal with 40kloc of shell script for a version control system. How am I supposed to run that sort of system on a non-UNIX system? What kinds of oddball dependencies is it going to have on the shell, path, and environment?

This seems like it's worse than CVS. Functionally, I'm quite happy with CVS. The main complaint I have about it is that it isn't self-contained but invokes rcs and other shell commands in mysterious ways. "arch" seems to make things worse, not better in that regard. What I would like to see is something mostly like CVS, but something that is implemented as a clean, self-contained library with a single command line executable (with subcommands) and a built-in HTTP-based server. Until that comes along, I think I'll just stick with CVS.

Subversion or Arch or both?

I hope both systems (Arch and Subversion) get some widespread use. Like a lot of Subversion developers, I'm genuinely curious to see a) how well the Arch model works in practice, and b) how well Arch's implementation of that model works out. If it turns out to be winning, then that'll be a big step forward for collaborative projects & free software. Arch sounds a lot like Bitkeeper [bitkeeper.com] only without the license problems, and I've talked to some happy Bitkeeper users before (a small sample, so it's hard to know whether we're dealing with a Shift To Better Paradigm or just good software).

Subversion [tigris.org] 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

Check out Meta-CVS.

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!

So what's the best?

We recently started using CVS [cvshome.org] with Chora [horde.org] and WinCVS [cvsgui.org]. While CVS is much better than no revision system at all, I am a little disappointed.

So here it goes...
What is your favorite revision system and why?
What is the URL?
Is it open source or proprietary?

Great Approach!

Having just gone thru the regexps arch docs it looks like Tom has done an excellent job.

The concepts Tom discusses are right on target. It appears there is plenty of flexibility to implement policy based on project requirements.

At first glance (have not installed yet) 'arch' has many of the same concepts as does BitKeeper and Sun's Teamware.

I'd like to see software like this dual licensed i.e Qt/BitKeeper style licenses.

Regards,
Kramer

Dialup?

Maybe I don't quite get it...

Let's say that I don't have write access to the Linux kernel tree. So I go grab a copy and make a branch on my machine and fix it. So then I post to the kernel mailing list saying that I've fixed this bug. Linus gets all excited and want so merge my branch in, but he can't because I am offline. So he forgets, and nothing happens.

Now you could say that I could upload it to the central server, but I don't have write access to that. I wouldn't imagine that they would give me (a non-kernel developer, trust me, I'd break something) access to the tree.

I guess I just don't get how useful this will be.

Some SCM Observations

I've done SCM for a number of years, professionally evaluated version control product, and helped edit an Anti-Pattern book on the subject. It seems, at least to me, that the majority of version control systems out there have the basis covered when it comes to check-in, check-out, branching, and labeling. The standard features, if you will.

However, most of the reasons that I've seen companies change version control systems is because of completely different reasons. Here are a few that come to mind:

- A version control system must be fast. I worked at one company where we tried to use Visual SourceSafe over a WAN; it took HOURS to share code. A good VCS should transmit the minimal amount of data.

- A version control system must provide security. All too often management uses the SCM repository as kind of a shared directory (BAD, BAD, BAD) -- and people who have no need to see or modify the code, do... implicitly.

- A version control system should provide extensive auditing and notification capabilities that can be discretely turned on and off. Allow logging the positive, the negative, and letting people know when particular operations happen to a set of files. In once case we attempted to get PVCS to automate scripts on a change to send mail to the PM. Checking in a directory flooded inboxes, since it could audit collections of code.

- There MUST be a recovery mechanism. Ever try to recover a lost SourceSafe password? Yikes. (Gaining re-entry is possible, back stuff up, change your password, do a diff. Copy pattern into the admin record with hex editor. Login as admin with new password. Change admin password. ...this worked at least twice for me.)

- Again, there MUST be a recovery mechanism. I love RCS, SCCS, and PVCS for their file-related mechanisms. Why? I've had SCM systems go down hard when the database got munged. Yes, you can recover from a backup, but a lot of work gets lost. With an open file format, you can at least hand fix localized problems.

- That said, good version control systems should allow you to check in collections of files as atomic units, move files and directories, and operate on projects as a whole. Anytime I have twiddle with a repository, thereby breaking past history, something is seriously wrong with the VCS system model.

- Good systems must have an IMPORT / EXPORT capability that PRESERVES HISTORY. The less I feel locked into a solution, the more likely I'll be to try it out. Porting between system is usually painful.

- SCM systems must conform to how the CM manager wants to run things, not the other way around. Let's face it, users can and will make mistakes, and that's okay. Mistakes should be fixable. I'll never use StarTeam because it was too easy for users to check in accidentally branches that couldn't be removed. Tech support argued that version control should reflect the history of the product, where I maintain (and still do) that it should reflect the intended history. If I want to include user errors, that should be my policy, not the tools. My users should be able to reflect upon the project history and know why things changed. Period. You don't use a hack to undo a mistake.

- Branching notation should be clear and to the point. CVS has it's magic numbers, StarTeam has god awful views. Let me choose the numbering scheme, don't play games with odd/even numbering. Version numbers should not be overloaded to carry additional meta-information by the product.

- A good SCM tool should remember tag history. Suppose I accidently move or delete a tag, now I want to put it back. Suppose I want to see where it's been. This case is rare, but anyone who's had a user twiddle with the wrong tags feels this pain as sharp and deep.

- More ADMINISTRATIVE control. My big beef with CVS is when I have to twiddle with the repository structures and permissions directly to accomplish what I want done. No. No. No. There should be a tool (that audit's change) for standard operations.

- An admin should have the ability to define, enforce, and audit user permissions that should be applied cross dimensionally against repository, commands, and elements within the repository.

- Data should be stored in a manner that can be parsed by custom tools. It allows me to write extensions and automation.

- Nothing should be possible in a GUI that is not possible from the command line. The inverse holds true as well. Everything should be automation friendly. Early versions of PVCS pissed me off for this reason. As a SCM manager, I've used both, and I'll take a command line over a GUI any day. My novice users want a GUI, my advanced ones usually revert back to command lines (and integrate it with their editors).

- There must be readable 2 and 3 way diffs.

- A good SCM tool will be able to produce reports, or at least make it possible to export information that can produce reports.

- A good SCM tool should know how to handle binary files efficiently, rather than just storing the whole copy.

- A good SCM system should not put a limitation on comments.

- A good version control system should not try to "do it all" (CCC/Harvest) and do none of it well. When GUI's pop up off screen, or you have to artificially create packages for simple files, something's wrong. Which leads into...

SCM systems should operate the way the users of that system do.

There is a BIG difference between how commercial houses run things verses OpenSource projects.

Commercial groups usually have a smaller set of developers, they are known in advance, and commonly use the locking model. OpenSource models tend to use concurrency a lot more, and operate on the applying diff's procedure. (Yes, I know, exceptions are out there.)

Thus, some tools that feel more natural in some environments get quickly rejected in others. I've yet to see someone produce a readable guide about version control abstracted at a high level bringing all the terminology together. (Incidentally, I'm about to release one; email me for a draft.)

The overall problem in tends to be that people look on the side of the box for features, rather than asking if the features are even applicable for what they're doing.

Worse yet, proper SCM often gets sidestepped in commercial world. Ask: Do you want branching? You get, is it a feature?...yes! Now ask: Do you know when it's appropriate to branch, how to do the branch efficiently, how to graft branches back to the root, or how to physically do it... and you find out this is where a lot of bad CM happens. It isn't fun to inherit a screwed up repository.

The most common downfall of SCM, as I've seen in the commercial world, is a failure of the those running it (quite often over-tasked infrastructure people) failing to understand the product being built with the tool, failure by team leads to communicate repository structure, failure by management as they use the SCM tool as a substitute for communication, and failure by the developers who don't know how to use the tool and when to use the appropriate features.

Revolutionary or playing catch-up?

Problems with the Arch vs Subversion comparison faq listed in the article.

1. Allowing the "smarts" to reside within the clients means you are stuck with however a client is configured--how do you handle modification times if the client's clock is skewed, or messed up hard-drives? Administration of such a distributed system would be a heck of a job and not one I'd enjoy doing when you get up into the hundreds of clients.

2. SCM based on a server-client system can be unerringly fast--blindingly so. Even if communication is entirely over TCP channels, an SCM system can be built to be a speed demon.

Some interesting ideas: I like the idea of being able to mirror the files to a backup server--but there are still some pretty annoying replication problems that would need to be worked out. Does development stop while the backup is brought as up to date as possible? Do developers still have to check in their files once more if those were ruined since the last backup or mirroring cycle?

I really think these projects need to stop playing catch-up to the larger SCM systems and start leading the field with advanced and stable functionality. :)

Too bad I shouldn't build one. :) No worries. :)

SCCS to CMS to Sable

RCS to CVS to arch, same story, a decade later. However, arch is far more competively priced. ;-)

Uggghhh.... [OT]

I am getting soooo tired of this notion:
Arch also poses its own answer to the 'Linus Doesn't Scale' problem.

Look people, the "Linus doesn't scale" issue is NOT something that can be solved by replacing the use of 'patch'. Putting the Linux kernel on CVS (or Arch or whatever) would just allow people to commit stupid changes.

The reason Linus doesn't scale is not because he doesn't have enough time to run 'patch'. It's because changes to the kernel MUST be approved.

conflict

Which (arch or subversion) manages conflicts best? And how do they differ from cvs? Looks like subversion uses a different version control of per commit not per file. Anyone could shed some light on this?

simultaneous writes

if it's using FTP as it's transport, how does it handle simultanous writes to common files?

i thought you needed some sort of atomic test/exchange method to ensure consistency in such situations?

Cross platform?

Everyone,

I'm about to set up a source repository at my place of employment for a new project that we are working on. I was set to use CVS, as we have in the past, until I read this article. Arch seems pretty spiffy, and would be fun to try out. My only concern is that some of our developers use non-posix (ie windowsXP) systems for development. CVS is great because there are clients available for all oses, and integrated into many IDEs. Are there any cross-platform Arch clients?

If not, one must think that perhaps this design be better implemented in Python || Perl || Ruby || Java instead of awk/sed/sh.

Thanks,

Andrew Murray

Subversion corrections

I'm not addressing Subversion vs. Arch, but rather Tom's evaluation of Subversion, which isn't entirely accurate.

I'd also like to say, up front, to the Anonymous poster who asked:

Anyone know a good system of incoroprating source control with a databases? Oracle and Postgres would do.

Subversion does. The backend it currently uses is Berkeley DB, but the backend is pluggable. After version 1.0 comes out, expect to see a backend for one of the SQL databases pop up.

Now, on to Tom's comparison to Subversion. Caveat: I am not a Subversion guru. I lurk in the developer mailing list, and I use Subversion myself. Therefore, I may make mistakes about details, but I'm fairly certain I won't provide completely bogus information. I got some reviews on this post from the Subversion dev list, including some comments from Tom, but any mistakes in here are my own, and they're copyrighted mistakes, dammit.

I'm not going to quote whole sections; just enough for context.

1. Smart Servers vs. Smart Clients. Subversion clients are also smart, although perhaps not as smart as Arch. Diffs travel in both directions, so a minimum of network traffic is used. Many Subversion operations (status, diffs against the last revision, etc) are purely client-side opereations.
2. Trees in a Database vs. Trees in a File Systems This is misleading. You *can* get stuff out of the Subversion database with the standard BDB tools, so Subversion isn't required. Also, because Subversion is based on WebDAV, access to the database through a web server is a freebee; also, Subversion is very Windows friendly, from many points of view, which should help its adoption in a corporate setting. Subversion only stores the differences between two versions of a file or directory, which is space efficient. The advantage to being able to access a filesystem-based repository of diffs is arguable.
3. Centralized Control vs. Open Source Best Practices In practical application, there is no advantage to the ARCH system over Subversion. Subversion allows per-file/directory sourcing, so you could create a project that includes sources from any number of different repositories. (This code is not currently working in Subversion.)

These are simple mistakes. There is also one statement that is wrong: arch is better able to recover from server disasters The argument was that, because arch is a dumb FS, it is easily mirrored. The implication is that databases aren't easily mirrored. BDB is just as easily mirrored, and most other databases are easily replicated.

Other comments pointed out were:

• Subversion does not require Apache. It works over a local filesystem just fine. If you want network access, you need Apache.
• Subversion has all of the strengths of Apache. You therefore get Apache access control (well defined and understood), SSL, client and server certificates, and interoperability with other WebDAV clients, among other things.
• With Subversion, you have both client side and server side hooks, as well as smart diffs.
• Arch has both revision libraries and repositories. The comparison document doesn't differentiate between them. In some cases, the comparisons made aren't meaningful. Revision libraries, for example "... also have to be created and maintained by the user. So comparing them to accessing past revisions through normal means in subversion is not a fair, or even really meaningful, comparison." (Daniel Berlin).
• When comparing Arch's repositories to Subversion's there is no speed advantage. Arch's storage is either diffy (storing only differences), in which case it is not easily browsed and is no faster (at best) than Subversion; or the storage isn't diffy, in which case it isn't efficiently stored (imagine multiple copies of each file for each revision).
• Subversion's choice of BDB as a backend was not accidental. Some of the tools Subversion got from using BDB are: Hot backup and replication, all kinds of existing tools that know about BDB databases (e.g. Python or Perl bindings). A body of - "community" knowledge. etc (Greg Stein).

I've left out vaporware features, such as the future SQL backend of Subversion 2.0.

Misses the point

As I understand it, the real issue right now is not shoveling bits around but figuring out which patches or changes or whatevers are worth using and which aren't. A super duper, multi-server bit shoveler won't fix that--anyone wanting to use the code base to make something useful will still have to know exactly which pieces of code to include and which to ignore. Barring the invention of true AI, that's a big burden on any software project that isn't going away.

Perforce does all that

it's also free-as-in-beer for use on opensource projects.
http://www.perforce.com

Stop complaining

Hello there, I'm reading these Slashdot comments, and start realizing very slowly that people are missing the point of our software community hopelessly. People find stuff to complain about, even the sh dependancy! Well, AFAIK, the reason I love GPL software is because, if there is something bothering me about it, I can CHANGE it. That's right, boys and girls, you can take those sh scripts, and write some proper C code from that. From the original developer's point of view, he just wanted a system up *that worked* ASAP, using whichever tools he can to get it that way. Now that it's in the wild and known, it can be refined and perfected and fixed and whatever else and we can have a beautiful piece of software like CVS or Linux or Apache or whatever in the end (not that most of them will ever meet their end :)

NOW is the time to stop complaining and getting those hands dirty and taking those things that bother you about the very first implementation, and go make some code. I see those sh scripts as nothing but prototyping code, and changing prototype code into C code is one of the easiest tasks a programmer can ever get to do (since the THINKING has already been done for you).

So please everybody, take this brilliant idea and let's make ourselves another open-source success.

ciao

Linus doesn't scale?

answer to the 'Linus Doesn't Scale' problem

I'm sure that given proper gear and some rock-climing lessons Linus could scale quite easily.

--

anyone for WebDAV?

I didnt see anyone else mention this... in all the discussion of whether using rsync/ftp/whatever is the best protocol for versioning software, I didnt see anyone mention that WebDAV (distributed authoring and versioning - http extensions managed by w3c) is a protocol intended for this use (which can run over ssl).

The DeltaV proposal (the versioning bits of webdav, which they chopped from the original webdav working group in order to get a document out the door) became a proposed standard in October 2001 (http://www.webdav.org/deltav/). I have seen people semi-seriously suggest that webdav clients and servers could replace cvs. If you're at work right now and have office2k you have a (limited) webdav client right there.

Going back to arch, it scares the willies out of me that we might entrust all of our trees to ftp...but OTOH it is clear that arch can be extended to support other protocols. Like the one above. Anything that can be made to appear as a r/w posix filesystem can be used.

I wish this was usable on windows though...vss sucks soooooooooo badly...