store HG SHA1s instead of integer revisions in the marks file

[dusty-phillips]

This was mentioned on buchuki/gitifyhg#4 Basically, the marks mapping in gitifyhg is using integer revisions. This may be more efficient than using sha1s (test and confirm), but using the canonical sha1s as references instead will likely be more robust.

Gitifyhg works fine without this change, but for future interreferencing, I suspect we would be better off changing it now than later.

[fingolfin]

We had some concerns about how to implement this as efficient as the current code. In particular, in the current code, we can just compare the integer revision id of the remote (Mercurial) tip commit, with the highest revision integer we know about locally, and from this can deduce which commits to import.

Of course one would expect that mercurial can do such a thing without using the integer revs, using the hash ids instead, and indeed, this is possible. I don't know yet what the "best" way to do this from the Mercurial Python non-API, but revlog.findmissing() sounds like it does what we need: Given two sets of node (ids) "heads" (= all remote heads we intend to import ) and "common" (= all heads we already have imported), this function "Return[s] the ancestors of heads that are not ancestors of common"

[jedbrown]

We had a discussion starting here about using a single hg clone to hold all known commits. It's a shame that hg does not have private namespaces for each remote, but I think that ability to pull without a full re-clone is pretty important. I get pull requests from various people on bitbucket and I don't have a fast way to fetch them because gitifyhg insists on cloning the full history.