Ok, so I’ve posted my initial feelings about tinkering with Mercurial and Git, and that seems to have generated some interest. It’s time to get a bit more formal about how I’m going to evaluate them against each other, to decide which one I like to use most in real, practical scenarios. So, I decided to come up with a list of use cases for the things that I typically have to deal with when managing the repositories for a software project (open source and otherwise), so that I can methodically test them out and see how I feel about each system. I’ve tried to deliberately include use cases for things that you can’treally do on a centralised system, but that I’d want to make use of, as well as the usual nonsense that happens day-to-day on a typical project
I’ve presented my work-in-progress list below, feel free to suggest more use cases I can test. I really want to see what these things are like in practice in the kinds of situations I encounter in real projects, without actually risking a real project in the process! Like a backup / restore strategy, it’s no good doing it for the first time when the sh*t has already hit the fan.
Oh, and for fun, allegedly Git is MacGyver and Mercurial is James Bond .
This list will be periodically updated as I think of new things, and as other things are suggested by commenters.
Due to the nature of a DVCS, all these use cases must be tested both in isolation, and after pushing those changes to another potentially ’superset’ repository.
- General
- Commit a few changes to local repository ‘A’ but don’t push to central yet. Push a number of different changes to the central repository from a different repository ‘B’. Then, pull ‘B’s changes from the central repos to local repository ‘A’ to bring it up to date, again without pushing A’s outstanding changes yet. This is equivalent to doing an ’svn update’ while you have local uncommitted changes in Subversion, but while using the local commit features of the DVCS. How does this work in practice? [Suggested by Arseny Kapoulkine]
- Branching
- Create a new public, official branch (stable branch)
- Create a new long-term feature branch which is intended for public consumption / collaboration
- Create lots of short-term development branches (or equivalent structures) intended for local consumption only
- What are the size overheads? (Git claims superiority here)
- Does this excessively clutter the public repository when pushed?
- Is there a better way of handling multiple local changesets which you may or may not decide to push individually, such as testing many patches (Mercurial queues seem very interesting, Git equivalent?)
- . Rename a branch? (optional)
- Merging
- Merge changes unidirectionally from one branch to another, without having to manually pick revisions. Make more changes in the source branch and repeat.
- Bidirectional merge – a feature branch which is not yet ready to be merged into the trunk wants to resynchronise from the trunk and continue branched development. Merge of this branch into the trunk must be tested later after further changes
- Tagging
- Create a tag against a specific branch; probably at the HEAD but look for the option to specify a revision
- Correct / modify / move a tag following a mistake or last-minute revision (pre-release) without having to make duplicate commits or other such spurious activity
- Firefighting
- Screw-up: developer commits change to trunk instead of stable branch. Merge / move it to the stable instead – change can be left in the trunk or can be removed for re-merging, so long as the procedure is clear.
- Screw-up: developer commits change to stable branch that is interface-breaking, must be removed and moved to the trunk. Must be removed from the stable branch and moved.
- Screw-up: Revert a single change from the repository, that is not at the HEAD
- External patch submission tests:
- Patch file from same branch, no conflicts
- Patch file from same branch, with conflicts
- Patch file generated on a different branch to the one we want to apply it to (include conflicts)
- Pull from third-party repository, entire branch
- Pull from third-party respository, specific changes
- Patch file generated from non-repository source copy
- Backup multiple work-in-progress changes on a local machine that are not ready for public consumption; approaches:
- Store a patch per local branch (this is how it’s done with SVN, but too much hassle if you use lightweight local branching, DVCSs can do better)
- Push to a backup repository on another machine across existing protocols – ssh, https, Samba share (Git can’t do the latter?)
- Push to a backup respository on a USB stick (Git can’t do this?)
- Binary files
- Revise a binary file over a few versions, test storage efficiency
- Binary file conflict resolution
- Conversion from Subversion
- Import retaining history
- Import multiple branches
- Import tags
- Integration
- Mailing list / RSS notifications of commits on official repository
- Bugtrackers
- CIA.vc et al?
- Good free & open source GUI clients for all platforms
- Line ending conversions between platforms











This was pretty interesting;
Ah, nostalgia – sure it’s a crutch, but it’s fun to indulge it sometimes. In this case, when they release a completely re-mastered (in terms of graphics and sound) version of one of the most classic games of the 90’s, there was really no option but to get my wallet out (or rather, a portion of the MS points ). It’s a great recreation – all the witty dialog is present and correct, translated exactly, and the ability to switch back and forth between the old game and the new one in real-time with a fancy cross-fade is surprisingly entertaining, letting you see how they translated the classic (which is to say, incredibly accurately, while still bringing it up to date). It also made me realise how much more patience these games expected of the player – I expect that players ill-versed in this tradition might be reaching for the cheat websites fairly early. I’ve already been stuck a few times, even though I’ve played this game before, mostly because my memory is terrible. But at least that means I get my money’s worth I guess. And no, I haven’t resorted to hints yet
Not strictly a ‘proper’ game, but I’ve had a couple of 30-minute sessions on XBLA’s virtual gameshow now. It does a pretty good job of recreating the gameshow experience, which is to say that while the meat of the questions can occasionally be interesting, like a real gameshow the whole thing contains way too much dull & repetetive padding which just grates on your nerves after a while. Whether it’s panning across the crowd showing everyone clapping and whooping – that got old in about 5 seconds flat – or periodically jumping back to the ‘live host’ so he can either bore you, or even worse you can be stuck looking at a billboard in silence for 3 minutes because the game deems that your bandwidth isn’t high enough to hear the streaming voice (strange, I know 2Mb isn’t that high these days, but it manages just fine with 2-way voice chat, so why can’t it handle voice from a host?).
I’ve had this on my ‘back burner’ list for ages and a friend got it for me this birthday. All I can say so far is: wow. My first hour in this game was probably the most intense immersive experience I’ve had in a long time, this game channels elements of System Shock, Half Life, Resident Evil and Aliens, and the implementation is absolutely superb. None of it is remotely original of course – a deep-space mining ship with which contact has been lost, things going pear-shaped in an gnarly alien infection way, escape cut off, etc etc – but when the execution is this good, it really doesn’t matter.
When Harmonix responded to GHWT’s user-created content feature by saying they wanted to hold off until they could do it properly, they definitely weren’t kidding. Today they announced the