please check out weave-format branch

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
>>The difficulty comes not just when you upgrade your own branch, but
>>also if I've upgraded and then you pull from me -- all of those
>>revisions you pull in will have the wrong hashes.
> 
> 
> Well, I would say we need to come up with a canonical form for
> revisions. Because we are going to be doing GPG signing at some point,
> and after that, we can't really be changing the sha hashes.

Sure we can.  Just store multiple GPG signatures.

The idea of a canonical form is nice, but problematic if data is not
always stored in it.  I would like signatures to prove that not only is
the data authentic, and undamaged, but it is safe to parse.

This requires signing the raw text, because if the data is parsed, you
run the risk of parser exploits being used against you.  So transforming
to a canonical form would not be good.

Canonical forms are also problematic because they are intended to lose
data, but if you lose the wrong data, you cannot verify the authenticity
or safety of the data.

> If you are checking the sha256, then all other hashes are
> also sha256. So sha256 doesn't see the sha1 hashes.

So if you can't calculate the sha256 hash for an ancestor, you can't
calculate the sha256 hash for this revision.

>>If we want to support references to revisions whose value is not known
>>(which some people call "ghost" revisions) then this gets even more
>>difficult.


> I don't really agree with this. Because at some point, the "ghost"
> revision was not a ghost. 

That's very limiting.  It means that you can't preserve merge history
when importing from another RCS.  In Arch, you know the names of all
new-patches, but don't necessarily have them accessible.

> But, there is another alternative. Store the sha hash, but don't include
> it as part of a new hash.

I think that could lead to confusion.

> You lose the nice property of encapsulating all of the
> history in a single hash, but it means that upgrading doesn't break as
> much stuff.

Right, and what do you have left?

> Sure, but signatures are hashes too :)

Yeah, but they're the kind it makes sense to store, because they
actually prove the data is authentic or safe.

>>It is an elegant property.
> 
> 
> I think if the design were settled, then it would be a good idea to use
> it. But since we are still in flux, it is probably too strong of a bond.
> 
> So there are a few changes I would like to see. First, the
> "get_revision_sha1" should not be a property of Branch, it should be a
> member of Revision. So a Revision can know what its canonical form is,
> and return the correct sha. So you could have:

I'd rather see Branch.get_hash(hasher=sha.sha)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDND0n0F+nu1YWqI0RAkxjAJ9CjIqea7kseWwDHX4WP1mm62EPKwCfSu13
svoV1dVAd3enQxZB1AcR3aQ=
=REGK
-----END PGP SIGNATURE-----