Take the 2-minute tour ×

Assume that there is a file under hg version control. I have a particular version of that file, and I would like to find out in which revision this file was in this version.

I suspect that there are two possible ways to do this.

  1. Do hg update in a loop and diff the file against subsequent versions (sloooow, but should work).

  2. Make Mercurial put the rev number in a, say, comment in the second line of the file right before committing. From what I have read, a precommit hook might be of use. Then I don't have to compare anything, just look at the file itself (I'm assuming no-one will change this, of course, but this is rather safe assumption in my case).

My use case is a joint paper, written in LaTeX, with two coauthors who have no idea about version control at all, but I prefer to use it (for obvious reasons). We communicate by email, and there's effectively a human-based lock system ("I will not work on this file until you send me the next version, ok?"). The only problem that arises is that I'm sending version X to author B to proofread, then author C sends me a corrected version Y and I commit it into my repo, then author B sends his corrections Z (to version X) and I'm starting to get lost-but I can check the attachment in the email sent to B, and I only need to find out which revision it is.

So, my question is: which of the two ideas above would be better, or maybe there's yet another one to help me deal with this mess?

share|improve this question
add comment

2 Answers

hg archive is good method for future work, but I can suggest at least 3 alternative work-styles and 1 fix for find-correct-version with updates

Future work

  • You can use separate named branches for co-authors and default for merged results, send co-author always head from his branch, update his branch after getting corrections (you'll always know, that you sent) and merge branches to default

  • One branch, revision-of-coworker marked with bookmark, which you later move to next point

  • Mercurial keywords considered somehow as a "feature of last resort", but in your case it's obvious and usable solution: just add keyword with hash-id in file (defaul extension instead of hook - easier and more reliable)

Current state

For finding changeset with source of file, you can try to use bisect (example) and test in test-script, f.e, CRC of file (you have needed CRC of unversioned file, check versioned file across history)

share|improve this answer
I like the idea of bookmarks or branches for each collaborator, better than archive. The problem with bisect is that you need to start off by bracketing the search with one "good" and one "bad" changeset for the binary search. In this case, every changeset except the one sought is "bad". –  shambulator Sep 19 '12 at 9:44
The CRC is no help since the returned file contains revisions-- it will not be an exact match. OTOH, I don't see how hg archive helps here, could you explain please? –  alexis Oct 29 '12 at 12:47
@alexis - type .hg_archival.txt inside archived data –  Lazy Badger Oct 29 '12 at 13:40
So this would only work when directories/zip archives are being exchanged, right? If the document is a single latex file, it'll come back on its own even if I (or @mbork) send it wropped in a zip archive. (I think named branches are the perfect solution, by the way). –  alexis Oct 29 '12 at 14:00
@alexis - " If the document is a single latex file..." you'll send e-mail with packed archive in it and note "please return back with updated file inside this archive" –  Lazy Badger Oct 29 '12 at 14:35
show 1 more comment

If you're happy to rely on finding the emails you send the reviewers, why not just include the revision hashes in them along with the files?

You can get this for almost zero extra effort by generating your attachment using hg archive, which will create a file containing 1) your files for review, and 2) .hg_archival.txt, complete with revision hash.

Though I'd be surprised if there isn't a more elegant way, even if your collaborators are dead-set against using version control.

share|improve this answer
Well, one problem is that the work already started, so solution 2 is rather a "future idea". But thanks for pointing me to hg archive anyway, I'll check it out. (And they are not dead-set against VC, they are just unaware that anything like that exists, and based of my previous experiences they will probably be opposed against it.) –  mbork Sep 18 '12 at 21:01
Sorry, assumption based on misreading and the fact that I know too many people who both write code for a living and want nothing to do with SCM :) This is effectively solution 2, without having to modify your LaTeX files to accommodate versioning or spend time getting hooks working. –  shambulator Sep 18 '12 at 21:31
add comment

Your Answer


