[MERGE] documentation from the london sprint

[Aaron Bentley]

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

Robert Collins wrote:
> Thanks for the review. I've fixed the rest errors somewhat, it doesn't
> complain, but it doesn't number them for me either; or should I not
> expect that?

Well, as we discussed, some of it's being numbered properly now.  Just
not all of it.

> I'm not quite sure what to take from these comments

I was just kibbitzing on your notes.  They are fine as is, but can
inspire further discussion.

I was just saying that using multiparent deltas could have some nice
properties for annotate-based merging.

>>> + 1. get 'new enough' hash data for the siblins of the scope: it can
>> be out of date as long as its not older than the last move or rename
>> out of that siblings scope.
>>
>> I don't really understand this bit about "new enough" sibling data.
> 
> If you have a selected-path operation, say commit. Lets say that we're
> committing just 'subtree2' and subtree1 has been altered - by a patch to
> subtree1/foo.c.
> 
> If subtree2 has a new file, (subtree2/new.c) can we be sure the fileid
> is unique without scanning the entire tree structure. 
> 
> The new enough bit is that the hash for the subtree1 (assuming the
> hashes are directory aligned) can be stale (still be the one from the
> time of checkout, for instance), as long as now
> moves-into-or-out-of/adds/deletes have taken place within it. 

So how do we know that the fileid for new.c is unique?

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

iD8DBQFGY40n0F+nu1YWqI0RAnLbAJ47wRe8zUY8GcdQ4l1zOxDGWKFTtgCePSMX
nQCRkC0T/ncelssxYYIKGOs=
=MgXT
-----END PGP SIGNATURE-----