Re: Mercurial "r####" numbers are not stable, use commit ids

On Mon, Jan 05, 2009 at 12:27:01PM +0100, Michael Sperber wrote: Semantically, an unambigious label referring to a point in the version DAG. Figure a cryptographic hash computed recusively from all the files creations (including content), changes, changelogs, etc that led to a specific version of your data. That makes it unique, unchanging even through distribution and with such a low probability of collision it's not worth bothering about. That allows you to point to a revision in your tree and be sure that if someone else has a tree with the same sha1, he's talking about the exact same thing. It wasn't invented by Linus btw, it comes from Monotone. SHA1s can be a tad unweidly, even if you get used to it, but the nice dispersion properties of hashes make it so that you can shorten these names to the first few digits when using commands. How many digits depends on the size of your history, the kernel tends to use 8. It's just a shorthand of the user interface though, the repository stores full 40-digits IDs always. In contrast Hg's revision id can't be stable on a global level since being low increasing integers they can't use probabilities to compensate for the lack of information. In practice it seems that people tends to use them as references (obviously, since they're visible and handy) not always realizing that there is no guarantee who they're talking with has these numbers referring to thesame thing. I suspect the best effort algorithms of Hg making them work at least part of the time have a side effect of increasing the confusion. OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta