What we did at UBZ

[Jan Hudec]

On Wed, Nov 16, 2005 at 14:12:37 +1100, Martin Pool wrote:
> On 13 Nov 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > Pull convergence
> > ================
> > We discussed the possibility of removing pull convergence from the
> > model, but we haven't made any final decisions.  The idea of pull
> > convergence was that after a branch had merged you, you could pull that
> > branch, and get their revision in your branch history.  This eliminates
> > ping-pong merges, where each branch merges the other and commits, ad
> > infinitum.
> > 
> > But having two points-of-view about branch history complicates things.
> > Removing this behavior would mean
> > - - the revno of a given revision would be clearly defined
> > - - tags could be implemented as pointers to revisions, with no need for
> > them to include revision history.
> 
> There are two use cases for pull-with-convergence: 
> 
> 1. I was developing on a feature branch; the feature has merged back in,
> and now I want to rejoin or switch back to the main branch.  I don't
> think this is a really compelling use case: you can just as well leave
> the feature branch around or archive it, or pull --overwrite.
> 
> 2. I have one logical branch that's developed in two different
> locations, canonically on a laptop and desktop.  When I switch between
> the two I don't want to see merges back and forth but rather just one
> line continuing on.  This is also relevant to bound branches or
> co-maintained branches.
> 
> We previously designed #2 such that each branch would continue to see
> it's own revision history up to the point where the merge was done, with
> other revisions built on from there.
> 
> The proposed new behaviour is this: pull can succeed where the
> pulled-from branch has completely merged the destination.  The
> destination's revision history becomes the same as that of the source
> (up to a revision limit, if one is given.)  This means that revisions
> which were previously on the destination branch's mainline may now be
> seen, from the perspective of the source, as actually being out on the
> side and merged-in.  I think this simplifies the internal model, it
> clarifies how tags should work, and it is probably reasonably easy on
> the user.
> 
> (This really needs an example I suppose.) 

I am not sure I understand how it should work. Anyway, I'd like to make some
points and it may be that I will talk about the same.

 - The key property of convergence is, that a revision keeps it's identity
   despite being pushed around. This is very important, as it allows one to
   have a complicated net of mirrors and not create a lot of mess.

 - I prefer to view the revision parents as equal. Neither of them is
   fundamentally more significant than the other.

 - Ok, the commands have to put one of them first when listing history,
   showing graph, etc. Than they should put first the one that was applied
   first. That is the one that was there before merge pulled in the other.

 - The revision should be pulled as much exactly as is as possible --
   including the order of parents.

 - The mainline is the history obtained by following first parent of each
   revision.

 - And of course, the definition of pull remains that it can only apply
   revisions, that are descenants of the current destination head.

Follows from that that after pull, the destination branch shows history
exactly the same as the source did. Actually it should be exactly equivalent
to source.

Now I _think_ what I described matches the above "new behaviour". What
confuses me is that "removing pull convergence" is announed in the begining,
but this really strenghtens the convergence.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051118/301edce0/attachment.pgp