pull and merge use case

[James Blackwell]

On Sun, Nov 20, 2005 at 11:56:16AM -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.

/me whistles innocently. :)

> 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

Sure, we could argue that the user pulled, hacked, waited three weeks and
wants to pull again before he commits... that's unusual behavior, but
wouldn't qualify as Bad Behaviour.


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

The best I can come up with is managing things like /etc, but that use
case is excluded by current operation anyways (permissions)
  
> 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.

This whole thing seems to strike me as inventory reordering. Its the same
stuff, just recorded in a different order in the inventory. Though I can
imagine log output changing and unusual merges (for non-head revisions)
potentially failing, why would a user otherwise care?

23,25,24 versus 23,24,25 just don't seem important to me if I'm at 30. 

I personally want to see pull & merge replaced with pull & switch. 

bzr pull:

	converged  same order  action
	----------------------------------
	 no          n/a       merge
	 yes         no        merge
	 yes         yes       pull

bzr switch:

   * Takes potentially out of order tree and reorders for target

   * Puts local commits at the end of the invenotry.

-------------- 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/20051121/aea32bbd/attachment.pgp