Changesets and multiple ancestors

[Robert Collins]

On Tue, 2005-06-28 at 11:47 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John A Meinel wrote:
> > Aaron Bentley wrote:
> 
> >> I think treating merged revisions as ancestors makes changesets an
> >> inferior way to merge.
> >>
> >> Changesets represent a single revision.  When you merge them, there's no
> >> sure way to get their ancestry.  Which means that you wind up with
> >> incomplete ancestry in your branch.
> > 
> > 
> > Since bzr is tree snapshot focused, I think you are always going to lose
> > something from a changeset. But it isn't very hard to have multiple
> > parents listed.
> 
> I probably should have had some coffee before writing that.  I meant
> that you don't have access to complete revisions for the whole ancestry.

..

I think thats a limitation stemming from deriving the changeset code
from your arch python code... Aegis's changesets incorporate all the
data needed to construct any point in time of the branch the changeset
represents (but not back into history from where it split from the
mainline).

I think that the changesets used for 'merge' and for 'send' should have
that property. We already know that they need to preserve annotation
data if we want to try the cdv algorithm. Preserving all the file texts
shouldn't be too hard - one naïve approach is to have a minimal spanning
tree of deltas for the revisions of each file in the changeset. Note
that this should include 'dead' changes where the file was changed and
then reverted.

Even if the merge logic moves to tree comparisons, I think we will need
this for 'send' to be fully functional.

Rob





-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050629/10b05431/attachment.pgp