Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
User Journal

Journal Fourier's Journal: Version Control Developments 4

I've been using various iterations of GNU Arch for a couple of years now. tla was among the first free distributed version control systems, and Tom Lord's design had a lot of things going for it: history-sensitive merging, cheap branching, proper handling of renames, append-only repositories, full operation over dumb transports like http and sftp, etc. There's no question, it's a powerful system.

Then again, the user interface is pretty rotten. Win32 support is weak. While tla can be configured to be pretty fast, the default configuration is rather slow. It's been plagued by on-again, off-again development. Did I mention the UI sucks?

About a year ago, tla development had stalled somewhat. Bugfixes were floating out in various people's archives, but not getting merged into mainline. When Tom did pop up on the list, he was talking about odd things like Pika Scheme and a specification for this weird Forth-like language called "xl" that would be integrated into Arch 2.0. A couple of other people stepped up to fill the tla 1.x maintainer role, but Tom was unhappy with the resulting code quality.

It was around this time that Canonical announced bazaar, a UI-focused fork of tla. Robert Collins began merging patches into bazaar at a rapid pace, and it quickly became both easier to use and faster than tla. Tom seems a bit torn on this topic--at times he has labeled bazaar an "unfriendly fork," but he has also looked on it as a sort of development line for tla. In recent months, all the serious Arch development has been in the bazaar line. Some have said that Canonical saved Arch from obsolescence, and I would have to agree with that assessment.

A few months back, Tom started talking about this fancy thing called "git" that Linus Torvalds designed to version control Linux. Everyone's been buzzing about this, of course, since Bitkeeper dropped their free support and all the kernel hackers had to find a new tool to use. git is designed to be crazy fast, and little more. Frankly, I'm not terribly impressed with it. But Tom seemed to think that Arch 2.0 needed to support "git technology" or be doomed to obscurity. So he started work on revc, aka Arch 2.0, which is based on git. (Guess what: it's plain old C code. No sign of either pika or xl.) There hasn't been much discussion of revc on the ML; my guess is that I am not alone in thinking this development direction was a mistake.

Then again, revc development never got very far. It's been an interesting week on the Arch mailing list--Tom Lord has resigned from maintaining Arch. After a couple of days of (stunned?) silence, people started discussing the future. Canonical will continue maintaining bazaar, but most of their development is going into bazaar-ng. bazaar-ng uses a lot of design principles from Arch, but it looks much easier to use. It's written in Python, so Win32 support is straightforward and development is going much more rapidly than it would in C. It appears to be quite fast (most operations are IO bound, so the penalty for using Python is negligible). At the moment the storage format is full-copies, but the developers are in the process of transitioning to a weave format that will be efficient for storage as well as annotation, and will assist in implementation of the recent Codeville merge algorithm. I expect that most of the Arch community will transition to bazaar-ng as it stabilizes.

Mercurial looks interesting as well. It was developed with Kernel hacking in mind, and seems to be somewhat better conceived than git. Also written in Python. If I understand correctly, it lacks proper rename support and cannot handle cherry-picking, so there are a couple of strikes against it.

Of course, Darcs has come a long way over the past year. The performance has reportedly improved somewhat, although I believe it's still better suited to smallish projects. Certainly an interesting experiment in version control, but ultimately I'm not convinced that Darcs places its emphasis on the most important aspects of the problem.

The point of all this is that the free VCS landscape is far better than it was when I first jumped onto tla. There are now a number of free distributed version control systems that look very capable. I expect that Arch refugees like myself will not have difficulty finding a good replacement in the near future.

And really, I'm rather happy that revc hasn't gotten off the ground. Stupid name, questionable design decision. Nonetheless, I wish Tom all the best in his future endeavors, and hope that he is able to find suitable employment soon.

In other news, last.fm just rolled out a major site update. Go check it out!

This discussion has been archived. No new comments can be posted.

Version Control Developments

Comments Filter:
  • It's interesting watching the amount of energy being thrown into source control systems. I'm currently using monotone and subversion for little projects at work, while considering what to do with our aging CVS repository. I'm not pushing either hard enough to sit anywhere near an edge case though.

    I have to admit I did enjoy using Perforce at the previous job - it did stuff very well. I suspect Subversion or Bazaar-NG will be where we'll end up going. One group is already almost entirely converted to Sub
    • I have to admit I did enjoy using Perforce at the previous job - it did stuff very well. I suspect Subversion or Bazaar-NG will be where we'll end up going. One group is already almost entirely converted to Subversion now because they're doing Windows .NET programming, and the windows support for Subversion is excellent.

      My personal opinion is that the svn team set their sights too low. svn certainly meets the design goal of being a "better CVS," but the centralized development model just seems unnecessaril
      • My personal opinion is that the svn team set their sights too low. svn certainly meets the design goal of being a "better CVS," but the centralized development model just seems unnecessarily limiting when compared to the modern distributed systems. (Well, unless you layer on svk, I guess.)

        99% of what I need is a better CVS. For a small team working on not necessarily open source stuff (we open source a lot of what we do, but not everything) and online all the time, it doesn't hurt to be centralised.

        Good re
        • Yeah, [last.fm] seems cool - I just haven't found time to explore it. I did sign up about a year ago, but never came back.

          Some neat stuff in the recent site update. The new tagging support has opened up a lot of new options for playing music by mood. See, for example, the chillout tag [www.last.fm].

Never test for an error condition you don't know how to handle. -- Steinbach

Working...