What we did at UBZ

Martin Pool mbp at sourcefrog.net
Wed Nov 16 03:12:37 GMT 2005


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.) 

-- 
Martin
-------------- 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/20051116/ba43c6cb/attachment.pgp 


More information about the bazaar mailing list