On Mercurial and tags

[torkell]

Today's discovery is that Mercurial is incapable of tagging a repository unless you've created a working directory for it. This is because Mercurial stores its tags in a ".hgtags" file in your working directory, so that it can version the tags file.

Of course, should you attempt to tag a repository without having a fully-updated working directory, Mercurial will fail with some nonsense about .hgtags having already been modified.

Ancillary discovery: should you typo when tagging a repository, the best way to recover appears to be to blow away your local repository and working directory and start again with a freshly-cloned one. Attempting to revert .hgtags doesn't appear to do anything.

Extra special discovery: it is impossible to tag a subset of a repository. Consequently, it is impossible to apply the same tag to different revisions of subsets of a repository. This is because you don't tag a file, or even a set of files - you tag a specific changeset.

Comments

[olego.livejournal.com]

You know, you haven't said much good about Mercurial... Is it really worth all the hassle and the awkwardness?

[torkell]

I actually had a chat with one of the guys at work today about Mercurial, and whether or not it's really the way forward (given my recent rants). I think that most of our problems stemmed from how we've set it up combined with how our software release system works. If we'd split products up into different repositories better... well, we'd then get a different problem of what to do about shared files, but I wouldn't have hit any of my recent issues with wanting to handle subsets of repositories. And shared files can be dealt with (via a dedicated repository for them, or splitting the shared files into libraries that can be released separately).

The big advantage of distributed source control systems in general is the ability to have a private dev branch that won't conflict with anyone else. Such systems also tend to make it easy to create repositories - the guy I was chatting to mentioned that he'd often create local repositories whenever he was writing a bit of test code on his system. In fact, the ideal situation he came up with was to be able to apply a dev branch to the main repository as a single "I did a bunch of stuff" commit - that way it doesn't pollute the main repository with a ton of "tinkered with this", "changed foo from 1 to 2", "changed foo back to 1" types of commits. Mercurial can probably be made to do that.

I think what I really want is a distributed source control system that for a given source archive has a notion of a One True Master Repository, which is where you get code updates from, commit to when you merge a private dev branch back in to tip, and release software from. Mercurial doesn't have this, and the biggest problem this causes is that clones of a repository tend to disagree about which direction merges went in despite the clones containing exactly the same set of changes. A One True Master Repository system would always show merges as being applied in the same direction (either towards or away from tip depending on whether you pushed or pulled changes). The One True Master would also let you grab the history or apply tags without requiring a local repository.

You almost get this with some combinations of IDEs and source control systems. For example, Eclipse maintains a local-to-your-workspace history of all the changes you make, and you can view this history and rollback changes independently of whatever source control system you're using. The trouble is that that behaviour is entirely due to the IDE - if you edit a file by hand with notepad or something it won't log the change.

Anyway, to answer your question: give it a try. You may find that Mercurial fits nicely with your workflow (though for it to be usable on Windows the devs will have to fix that bug with large files). I fully imagine that if we were using a different distributed system at work I'd have ranted in equal volume about it instead :)