pull and merge use case

[Jan Hudec]

On Sun, Nov 20, 2005 at 11:56:16 -0600, John A Meinel wrote:
> 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.

You could not have diverged, unless someone *replaced* the pull source.
Because any commit on the source must be descendant of the last one you have.

> 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?

Say A's working copy is not up-to-date. So A does update (pull) which
switches his branch to upstream too and commit continues to work.

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

If the pull from upstream switched, the pull to A's branch will switch just
the same. DivergedBranches must result if and only if pull does not work,
whichever way that is.

I still think pull -- and push -- should switch:

A$ bzr pull S
S$ <more revisions get here>
B$ bzr pull S
A$ <hack hack>
A$ bzr commit
A$ <hack hack>
A$ bzr commit
A$ bzr merge S
A$ bzr push S
B$ <hack hack>
B$ bzr pull

It the push does not switch, user A needs to create another copy of
S (suppose shell can't be used on the server) and merge there -- which will
certainly not make him happy. It will have some side-efects, like the
mainline actually not being first parent -- which I think should not matter.

If push does switch, pull must to, otherwise it would fail for user B.

-- 
						 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/20051120/36e9bc4e/attachment.pgp