Storage internals: UUID

[Daniel Carrera]

On Tuesday, June 05, 2012 at 6:34 PM, Max Bowsher <_ at maxb.eu> wrote:
> What you are doing, is arguing a case based on accepting as an 
> axiomatic truth that it is necessary and valuable to incorporate a 
> cryptographic hash of a revision's contents in a revision's primary identifier.
>
> Bazaar does not accept this as an axiom. You'll need to justify 
> your thoughts on why this should be the case, instead of treating 
> identity and cryptographic integrity as two separate pieces of data.

Please don't say that about me. You are basically calling me dogmatic. I thought my posts had been clear as to the merits of hashes. Maybe I failed to communicate clearly, but that is different from blindingly taking the value of a has as undisputed truth beyond the need for justification.

The value of a hash as an identifier is that if I tell you to download revision $X you have a cryptographic guarantee that the revision you got is the one I meant for you to have... without corruption or tampering... To be clear: I do not mean to say that it is necessary for the VCS to use a hash internally as the primary ID. What I mean is the ability to identify a revision via the hash. For example, I could imagine a world where I release revision 6fcf645ee9cb53146bc88743de81af1fa8b247fc. You ask bzr to download that revision. Bzr does a table look-up to find the internal ID that corresponds to that revision, obtains the revision, and performs a check to ensure that the hash matches. This example is within the realm of what I would call an identifier. Ultimately what I want is a cryptographic level guarantee that what I put into the VCS is exactly what I get back later. I don't have my heart set on any specific mechanism to accomplish this guarantee, as long as the guarante
 e exists. In fact, I am always interested to learn about alternative ways to provide cryptographic guarantees in software.

Daniel.