Changesets and multiple ancestors

[John A Meinel]

Robert Collins wrote:

>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).
>  
>
But what is considered mainline? I assume it would be BASE when you 
actually attempt a merge/diff.

>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
>  
>
I can see how this might be necessary. But can we also have summary 
human-readable changesets? It is actually nice to see a changeset and be 
able to read it. And I have the feeling that something that contains all 
deltas included reverts is going to be very hard to understand what is 
going on for a human reviewing the patch.

If you look at my current proposal, it is a standard diff, wrapped in 
some meta information so that you know what revisions are in the 
history, even if you don't know the specific contents for each point in 
history.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050628/70efaa4e/attachment.pgp