[MERGE] documentation from the london sprint
aaron.bentley at utoronto.ca
Mon Jun 4 04:55:20 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar