Storage internals: UUID

[Daniel Carrera]

Here is another idea:

Bzr could have a chained hash system similar to Monotone, Hg, Git... but it would be a "secondary ID" used only for Bzr branches... In other words, branches maintained in Bzr itself could have whatever security benefits may be derived from chained hashes, but since it is not the way revisions are addressed internally, Bzr can still use foreign branches. It just means that Bzr branches have a type of integrity guarantee that doesn't apply to foreign branches.

An index file can map hashes to primary IDs. You can use the hash in lieu of an ID if you wish. For example:

bzr pull -h af1b7995c0  http://example.com/repo/trunk

That means, "give me the revision with this hash". Bzr looks up the index, gets the primary ID, and proceeds to grab everything.

Just an idea.

Cheers,
Daniel.


On Wednesday, June 06, 2012 at 5:16 PM, Daniel Carrera <dcarrera at hush.com> wrote:
>
>On Wednesday, June 06, 2012 at 11:05 AM, John Arbash Meinel 
><john at arbash-meinel.com> wrote:
>
>> There are interesting benefits to this, but Bazaar did 
>explicitly make
>> the choice that we validate the snapshot more than the full 
>ancestry.
>> (you can't have a revision which is mentioned but not converted 
>if you
>> have chained hashes.)
>
>I personally like the idea of the history being included in the 
>hash, but I can see myself being flexible on this point if the 
>hash still takes measures to ensure that the entire revision is 
>correct and not just the patch or the delta. For example, suppose 
>you made a hash that included:
>
>1. The entire contents of the source tree.
>2. Metadata like author, date, branch, etc.
>3. The non-hash ID of both the present revision and the parents.
>
>It seems to me that this might have assurances comparable to what 
>Monotone, Hg and Git do, while keeping the benefits of Bzr's 
>metthod: If you wanted to interoperate with SVN, you would only 
>need the ID of the immediate parents, and not their hashes. So 
>there is no chaining of hashes. The problem I see is that it might 
>be very slow to take a hash of an entire repository. At the same 
>time, I really don't think it's enough to take a hash of just the 
>deltas because it could be applied to a different tree without 
>your necessarily noticing (imagine a clever and malicious 
>attacker).
>
>Cheers,
>Daniel.