On Sun, 16 May 2010, Tony Mechelynck wrote: > On 16/05/10 21:26, James Vega wrote: > > On Sun, May 16, 2010 at 06:09:15PM +0200, Tony Mechelynck wrote: > > > I don't know if Mercurial hashes are carried over (the short hash > > > for Bram's vim73 parent to my latest merge is listed as > > > c6f1aa1e9f32 with the description "Add 'relativenumber' patch from > > > Markus Heidelberg") and anyway they aren't taken over in the > > > resulting executable. > > > > The hashes are global to all clones of a given repository. That is, > > any commit which is shared among clones will have the same hash. > > That's how Mercurial knows which changesets have been applied. The > > changeset index is local to each clone simply as a convenience so > > you don't have to type out full hashes. > > > > Ah, I see. I wonder how Mercurial makes sure that a changeset I import > will never have a hash (not even a 12-nybble "short hash") already > used by an earlier "local commit".
It doesn't (and can't) mathematically guarantee no collisions in the full hash. The input space is far larger [text of any length] than the output space [non-negative integers from 0 to 2^160-1]. > Saying that "it will never happen" because the apriori probability is > thought to be low strikes me as the wrong way to set up server > software (see Murphy's law). Oh, well, I'll worry about it when I see > it happen. It's not just that "the apriori probability is thought to be low", it's that it's thought to be astronomically low. There's a Mercurial FAQ[1] that sums it up well: """ 7.11. What about hash collisions? What about weaknesses in SHA1? The SHA1 hashes are large enough that the odds of accidental hash collision are negligible for projects that could be handled by the human race. The known weaknesses in SHA1 are currently still not practical to attack, and Mercurial will switch to SHA256 hashing before that becomes a realistic concern. Collisions with the "short hashes" are not a concern as they're always checked for ambiguity and are still long enough that they're not likely to happen for reasonably-sized projects (< 1M changes). """ The "short hash" isn't used in "mission-critical" contexts. (As with the local 'revision numbers', it's merely for convenience.) As with the crypto-law conversation, probably getting a bit offtopic for vim-dev, but if you're interested, some more reading in the links below[2][3]. -- Best, Ben [1] http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.What_about_hash_collisions.3F_What_about_weaknesses_in_SHA1.3F [2] Why SHA-1 shouldn't be of concern (in the context of Perl's git repo) http://use.perl.org/~schwern/journal/37600 [3] Re: SHA1 hash safety (again git, but the same applies to hg) http://www.gelato.unsw.edu.au/archives/git/0504/0724.html -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
