Evan Martin (evan) wrote in evan_tech,
Evan Martin
evan
evan_tech

mercurial dvcs

Yes, I know I've posted over the years about cvs, svn, arch, montone, and most recently darcs. But my ICFP partner used mercurial so I picked it up.

After playing with so many of these they all begin to blur together. They're all trying to solve the same problems, and there's only so many ways to do it. So it turns out that what distinguishes one from another ends up being the details typically disregarded by developers, who are focused on the more grungy issues of the proper way to compute diffs or efficiently sync patches. (This is, as far as I can tell, one of the reasons for svn's success: from all accounts, the implementation is dodgy but it doesn't matter because it's pleasant to use.)

Details like, for example: how's the manual? darcs and montone both have fantastic manuals, far beyond what you normally get from any free software. tla has a pretty decent tutorial. mercurial... well, I looked around and basically couldn't find any real docs. (For example, my friend told me I needed to change the name associated with my patches. Apparently you stick some stuff in your ~/.hgrc, but I never would've found it without his help.)

Or another "detail": how's the workflow? Cairo switched to using git a while back, and every few months or so there will be a message to the mailing list where Carl explains "oh, to properly merge this tree I had to use git-frotz-bar with the --oldbinlogs option, it's very interesting, you see, ...". I'm reminded of back when I inflicted tla on poor gaal for LogJam.

As another example, "tla help" has one hundred and eighty four output lines of possible commands, with stuff like "join-branch : add a version as an ancestor of a project tree
sync-tree : unify a project tree's patch-log with a given revision".
I'm sure these are very important issues when you're designing such a thing but the whole point of making software is to hide complexity.

So, mercurial. I found it worked pretty much like monotone, or at least that's how I mentally modeled it and I seemed fine (see the above about lack of docs). You clone repositories around to make branches, simultaneous commits cause branches that need a subsequent merge commit to bring them back together, file versions seem to be based on hashes.

In fact, it feels a lot like a stripped-down (in both positive and negative senses: simplified and weaker) monotone that's a bit more wieldy. I never think about which database or branch name a given bit of code is, I just push and pull between different directories. I also like that their netsync can work via a CGI script, while still allowing pulls over plain HTTP, and I get the impression from their web page that they've invested a lot in performance.

The main reason I've switched all of my stuff to darcs is that it's really simple: I can commit anywhere and everything happily exchanges patches, and the repo trees are just trees of plain files. Sure, it's simple and slow, but my needs are pretty simple and it's not that slow. If I were working on a larger project, I would seriously consider using mercurial.

(Funny thing, I actually had begun this post with a more negative impression of it, but as I wrote it out I realized that mercurial seems to have gotten most things right! Maybe if I used it more I'd see more of its flaws...)
Tags: vcs
Subscribe

  • blog moved

    As described elsewhere, I've quit LiveJournal. If you're interested in my continuing posts, you should look at one of these (each contains feed…

  • dremel

    They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…

  • treemaps

    I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.

  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 10 comments

  • blog moved

    As described elsewhere, I've quit LiveJournal. If you're interested in my continuing posts, you should look at one of these (each contains feed…

  • dremel

    They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…

  • treemaps

    I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.