pull and merge use case

John A Meinel john at arbash-meinel.com
Sun Nov 20 17:56:16 GMT 2005


It has been mentioned several times that we could have "bzr pull"
fallback to merge, rather than just prompting the user to do so. I
wanted to present a use case, and see what people think should happen.

Basically, think of the case of shared development, where you want to
stay synchronized, but you aren't using bound branches yet.

So the user does some hacking, and then wants to make sure they are
up-to-date before they commit. So they typically do:

$ bzr pull
<hack hack>
$ bzr pull # Make sure we are up-to-date
$ bzr commit -m "new stuff"
$ bzr push

This is the current work flow if you want to stay synchronized even with
yourself. If the second pull has changes, it would actually apply them
to the local tree.

If the trees are diverged, you would have to do a manual merge, after
the pull.

Is there a use case where if the branches have diverged, you would
rather not merge.

I guess I can see the case of "oops, I guess I've diverged, let me
commit my work on another branch before I continue."
Because if pull fell back to merge, then your changes would be mixed
with the remote changes, and you can't just do "bzr revert" to undo the
merge since it would take your stuff with it.

That is the only case I can think of where you may not want a pull to
switch to merge when the branches are diverged. If people feel it is
significant, then we shouldn't implement the fallback.

I personally don't know that it is a strong use case. Eventually we
would be switching to bound branches, which also help prevent divergence.

Oh, but I have to bring up another issue. If we are getting rid of "pull
convergence" so we have branches switching instead of just converging,
then a bound branch might behave weird. Here is an example:

  Users A & B are sharing a bound branch to enable centralized devo.
  They both have a bound branch pointing to the same location.
  They are happily committing periodically, updating as needed.
  User B is maintaining patches against an upstream, while User A
  is doing active development on something.
  User B notices that upstream has merged their current changes, so
  they do a 'pull' which ends up doing a switch making the bound
  branch turn into the upstream. In the meantime User A had added one
  more feature.
  User A goes to commit, what should happen?

I suppose User A's 'pull to update to latest' should switch the local
branch, and allow them to commit normally. I was just concerned that
when they go to commit, they would actually get DivergedBranches, rather
than OutOfDate. Because the revision-history has changed because of the
switch.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051120/1b2de358/attachment.pgp 


More information about the bazaar mailing list