Blog - /Tech

Posted by Luke Hoersten at Sun Jun 3 11:29:14 2007

What about git? If you're linking to monotone it seems fair git should be on your radar as well?

Posted by Michael Olson at Sun Jun 3 12:59:31 2007

git seems to have come a long way since I've last visited it, so I've added a link to it.  I'm not sure what I think of it yet -- it seems to have all of the features one would need, but it seems that a lot of commandline options must be specified to make its commands Do The Right Thing.  That's not so good.

Posted by Dustin at Sun Jun 3 13:54:47 2007

I've recently moved most of my projects from gnu-arch to mercurial.  It's been a great experience.

I'm terribly annoyed every time I encounter a project I want to work on over the internet that uses subversion because for all practical purposes, it's only slightly better than publishing their changelog.  I can track changes to a tree, but I can't track them along with my own changes, or have a reasonable way to give my changes back.

Mercurial queues has helped out here a bit, but subversion is just inappropriate for open source programming (and IMO, centralized revision control limitations make it generally inappropriate for all projects).

I've not used git yet as I've not managed to get a build of any version that works successfully on any of my machine.  I've got hg working on all of my macs, OpenBSD, FreeBSD and Linux boxes.  I'm sure git would work on at least one of those, but my development occurs on OS X.  Only recently has cogito even installed out of ports, and it still doesn't work.

The google tech talk on mercurial sold me on it and got me migrating my repositories.  It seems well-designed and has all the tools I need in one simple command.

Posted by Julian Morrison at Sun Jun 3 17:04:04 2007

Not sure what you mean by "It is easy to accidentally get the wrong directory from a project you're just starting on". Can you elaborate?

Posted by Luke Hoersten at Sun Jun 3 17:20:48 2007

@Julian: I think he's talking about cherry picking.

@Mike: So why have you chosen Mercurial over Monotone and Git?

Posted by Michael Olson at Sun Jun 3 18:10:03 2007

Dustin: Thanks for the vote of confidence in Mercurial.  I am glad to hear that it runs on nearly everything, because I have lost at least one potential contributor to a project because Arch is very difficult to build on Windows.

Julian: What I mean is that it is easy to check out, say, a top-level directory that contains all of the branches and tags, as well as trunk (if you're not familiar with how most subversion repositories are laid out) when all the user wants is trunk.  That's merely annoying.  Additionally, if the subdirectory of a directory is named similarly to its parent, it is hard to determine whether I should check out the parent or the subdirectory.  With something like bzr, it would tell me "hey, this isn't a repository", and I would know to try the other one.

Luke: Monotone's database-oriented approach rubs me the wrong way, though I need to do a bit more research to see whether it makes sense in any contexts.  Also, I mentioned in my earlier that I have a gripe with needing to specify arcane commandline options in order to make git do common tasks.  Yeah, I could probably create some sort of command alias, but then I have to be sure that every single contributor has that alias when I write up some directions, and that's another point of failure.  It's hard enough to attract active contributors as it is.  Maybe I'll evaluate git again once the documentation has been overhauled and the current improvements in user ability have been extrapolated still further.

Posted by Sverre Johansen at Sun Jun 3 18:35:01 2007

How does bzr compare to git and Mercurial?

Posted by Michael Olson at Sun Jun 3 18:45:07 2007

Sverre: I like bzr's user interface very much.  It's also good that it is made in python -- I've successfully installed it on the Solaris machines at Purdue.  I tried backup up /home and /etc on one machine with bzr, and used Mercurial to do that same thing on another machine.  Mercurial was noticably faster.  On one hand, bzr has incremental patch numbers, which I like, being used to Arch.  On the other hand, it doesn't seem to be as "cutting edge" as Mercurial and git, with their use of SHA1 to name patches.  I will probably wait until it hits a 1.0 release before trying it out again, because I got bogged down trying to keep up with their mailing list.

Posted by gamehack at Sun Jun 3 18:49:18 2007

Michael,

Git works perfectly on OS X 10.4 - http://www.dekorte.com/blog/blog.cgi?do=item&id=2539

I've been using it for quite a while and I'm very happy with it.

Posted by devdanke at Mon Jun 4 12:52:04 2007

Thanks for sharing your ideas.  The Subversion developers seem like a reasonable group, who listen to community input.  I'm interested to hear their response to your list. 

  * Metadata is stored in every subdirectory, rather than in one top-level directory. This makes subversion unsuitable for backing up /etc, because it causes conflicts with various programs that have expectations about the contents of their directories.

[It would be nice if .svn wasn't in each sub dir.]

  * I can't make an offline copy to work on, unless I use some other revision control system to layer on top of it like Mercurial or bzr. If I'm using Mercurial and bzr to do this, I might as well have used them for the main repository as well.

[Good point]

  * Subversion does not keep track of merges.
[I believe this is coming in SVN 1.5, which is the next planned release.]


  * Subversion does not handle renames in a sane way.
[I remember reading that the SVN devs also didn't like how it handled renames.  I wonder if this might have been fixed though.]

  * If the people who host your repository go away, you lose the entire revision history. Not so with decentralized version control systems.
[If your data is important, you will not 100% trust anyone else to protect it.  Instead, you'll make your own backups.  SVN allows dumps that included version history.]

  * Its name does not make sense. A centralized revision control system can hardly be labeled "subversive"! Decentralized version control systems fit that description much better.

[Lots of names don't make sense.  Who says names must make sense?  I think  the name is cool and funny.  I like it.]

  * It's not what the cool kids are using.
[I'm cool and I use SVN;-) ]

[For me, the main reason to use Subversion is because it's sooooooo much better than CVS.  As long as it forces CVS into retirement, SVN is a great success.]

Posted by Michael Olson at Mon Jun 4 13:02:29 2007

devdanke: If subversion does not significantly depart from the poor ideas (specifically centralization) and poor interface of CVS, then it is a miserable failure, not a success.  And if you use SVN to manage projects, you do not fit my definition of "cool" w.r.t. revision control system use.  Sorry.

Posted by Willy Lee at Mon Jun 4 15:12:03 2007

Re: The failure to update issue: we had that at work, not once, but numerous times.  What sucks about that is that if it fails, it basically makes your entire tree unusable, from a SVN standpoint, because SVN will refuse to do anything useful at this point.  We had a large tree, and we had three bad options at that point: run 'svn cleanup', which would take an enormous amount of time and usually did not help; try to find the temp file in the .svn directory that was causing the problem, and delete it, try again, iteratively; or simply delete the tree and do a fresh checkout. 

After the third time this happens to a person, nobody is any mood to like Subversion.  After the third person has this happen three times, Subversion doesn't get used on the next project.

This is in addition to other (serious) annoyances, such as 'svn switch' silently failing to switch some subtrees, or failing in such a way that the tree was again unusable, and 'svn cleanup' couldn't fix.

Posted by Karl Fogel at Tue Jun 5 02:29:47 2007

Sure, I'll take devdanke's invitation.  Note that I don't speak for the Subversion development community, only for myself.

Metadata is stored in every subdirectory, rather than in one top-level directory. This makes subversion unsuitable for backing up /etc, because it causes conflicts with various programs that have expectations about the contents of their directories.

The idea behind this was to support "detachable" working copy subdirectories, a nice feature that CVS also has.  While I still use this feature occasionally, I think there's general agreement now that we're willing to toss it in order to get some of the benefits of having one unified metadata storage location.  (However, that work isn't actually done yet, so you still get to count it as a point.)

I can't make an offline copy to work on, unless I use some other revision control system to layer on top of it like Mercurial or bzr. If I'm using Mercurial and bzr to do this, I might as well have used them for the main repository as well.

Agreed, and it would be nice to have this.  Personally I expect Subversion to grow this feature relatively soon (like, in the next year or two?); SVK will give us some guidance.

Subversion does not keep track of merges.

Will be fixed in 1.5.

Subversion does not handle renames in a sane way.

Agreed, known bug (done that way for historical reasons, not worth going into them here).  This is Issue #898 in our bug tracker, and while a lot of progress has been made toward solving it, it's not fully fixed yet.

It is easy to accidentally get the wrong directory from a project you're just starting on, thanks to Subversion's "every directory is a repository" model.

Huh.  That's not a complaint I've heard a lot, although I understand what you mean.  Maybe when people do this, they usually interrupt the operation immediately, remove the bad checkout, and try again?  However, I think this "every directory is a repository" idea (as you call it) is more of a feature than a bug.  I really like being able to check out arbitrary subdirectories.  This must be a matter of taste; it had never occurred to me that anyone would dislike it.

If the people who host your repository go away, you lose the entire revision history. Not so with decentralized version control systems.

No, see search://svnsync/ :-).

Its name does not make sense. A centralized revision control system can hardly be labeled "subversive"! Decentralized version control systems fit that description much better.

We subverted the CVS user base.  Also, it's a cool name, and we got it first.  So there :-)

Subversion once failed to completely update a checkout, and a co-worker had to spin some magic to get it "completely" updated. This is not sane. CVS suffers from the same kind of problem.

Any system can have a bug.  This isn't one I hear reported very often; I'm sorry it happened to you.  I know of no evidence that Subversion is more or less fragile in this respect than the other systems you mention.

It's not what the cool kids are using.

No comment there.

Hope this helps,

-Karl Fogel

Posted by Michael Olson at Tue Jun 5 08:24:09 2007

Karl:

Yep, I strongly dislike the idea of detachable working directories.  If for some reason I wanted my code to be checked out in parts, I would turn each part into its own repo manually.  It's annoying that subversion does that for me automatically.

svnsync requires some forethought and effort to use.  Decentralized revision control systems get that feature for free.

Posted by Steve Schnepp at Thu Jun 7 06:34:20 2007

Michael Olson:

svnsync requires some forethought and effort to use.

So do all decentralized revision control systems...

Posted by Michael Olson at Thu Jun 7 06:57:22 2007

Steve: The point is that svnsync is not part of the normal subversion experience (to the best of my knowledge) and hence people need to think ahead or they won't ever use it.  With decentralized systems, you don't have to think ahead -- you get that feature for free.

Posted by Steve Schnepp at Thu Jun 7 19:55:36 2007

Michael: I see and understand what you mean. IMHO that fact that svnsync isn't part of the normal subversion experience is not a bug, it's a feature : It just enable to do simple things in a simple way.

By going decentralised, you have to always pay the price of that feature (usually a lower one, since it is mandatory and therefore better integrated), hence you seem to have it for free.

And, no I'm not saying that this or that is better : it's just not the same thing. It's like multi-threading programming can be better than mono-threading programming or not, it all depends on the task to do.

Posted by Luke Hoersten at Fri Jun 8 11:00:05 2007

I've started using Mercurial and LOVE IT! Definitely easier than git. So easy that it kind of makes me gitty (intentional misspelling) just using it!

Great suggestion Mike!

I'm emailing the CS department to try and get it installed on CS accounts.

Posted by anon at Sat Jun 9 16:45:43 2007

What, no mention of darcs?

Posted by Michael Olson at Sat Jun 9 17:05:29 2007

I like using darcs, and being able to selectively record patches is handy.

However, I don't like its nonstandard patch format, and I don't like its worst case performance on large source trees.