pull and merge use case

[Jan Hudec]

On Tue, Nov 22, 2005 at 19:59:55 -0500, James Blackwell wrote:
> On Tue, Nov 22, 2005 at 08:21:47PM +0100, Jan Hudec wrote:
> > > 	 yes         yes       pull
> > > 
> > > bzr switch:
> > > 
> > >    * Takes potentially out of order tree and reorders for target
> > > 
> > >    * Puts local commits at the end of the invenotry.
> > 
> > That would certainly not match expectations from other version control
> > systems. Those expectations are (at least I would expect that):
> 
> I think this is necessary for switch to be switch. To me, switch means
> "turn this branch into that branch". Yet, a branch's identity (what makes
> it unique) is two thing: The changes that have been collected, and the
> order they were collected in.

IMHO it's only one thing -- it's head (which determines the changes that
have been collected). I think the order (revnos) are better if they
never change in particular location -- ie. after switch the revisions
that already existed should retain their revnos IMHO.

> I suppose the purist would want switch to take the local changes and throw
> them away -- really and truely turn B back into A. I don't personally
> think this is a great idea for the bzr model though, as the branch I just
> switched from could easily have been the only place those changes existed.
> 
> Thusly, I think I'd rather see a "bzr switch" and "bzr switch --pure".
> --pure would really and truly wipe local changes out. The standard
> switch would do things like reorder so that the tree was as similiar to
> the one switched to as possible without throwing away local changes.
> Things like reordering and filling in missing merges.
> 
> > foo$ bzr switch /another/branch
> > 
> > being equivalent to:
> > 
> > foo$ bzr diff > ../foo.diff
> > foo$ cd ..
> > $ rm -rf foo
> > $ bzr branch /another/branch foo
> > $ cd foo
> > foo$ patch -p1 < ../foo.diff
> > 
> > ... yes, it IS a DESTRUCTIVE operation for standalone branches. It is not
> > a destructive operation in case of bound branches and archive branch
> > checkouts.
> 
> Yes. This destructiveness doesn't exist when there's an archive preserving
> those changes somewhere/somehow. But with standalone branches, you've just
> given the user a tool in which its very easy to throw away all of those
> commits.*
> 
> * I suppose I'm considering work that was good enough to commit deserves
>   a level of protection from the tool that doesn't throw work away unless
>   it was intentional.

Ok. Of course the changes don't need to be -- and shouldn't be -- really
deleted. But since they are no longer in the ancestry of current head,
the only way to get back to them is to switch revid:<something>.

--
						 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/20051123/2827ae03/attachment.pgp