Switching between branches with uncommited changes.

[Michael Gliwinski]

On Wednesday 11 November 2009 21:13:25 John Arbash Meinel wrote:
> It is by design. One of the very common use cases for 'switch' is
>
> bzr co --lightweight trunk work
> cd work
> # hack hack
> # Oops, I want to split this change into a different branch
> bzr branch --switch ../trunk ../feature
> # Yeah, I cheated here, but 'bzr branch ../trunk ../feature; bzr switch'
> # works too
> bzr commit -m "Fix bug in foo"
> bzr push; bzr lp-open
> bzr switch ../trunk
>

That makes sense.  Suppose there's no other way to do `merge --uncommited` 
with lightweight tree.

>
> The main problems that occur with 'switch' is when you do something like:
>
> bzr branch trunk feature
> cd work
> bzr switch ../feature
> echo bar > foo
> bzr add
> bzr commit -m "add foo"
> echo baz >> foo
> bzr switch ../trunk
>
> At this point, 'foo' is partially modified, wrt it being added to
> 'feature'. However, if you switch to 'trunk' then it tries to apply that
> delta to a non-existent file, and you get a conflict.
> And then you realize this fact, and do:
> # spit
> bzr switch ../feature
>
> And at this point, you know have a conflicted file that is trying to get
> merged into a ...
>
> anyway, it does blow up.

Yip, however in this case you have a conflict and would get a message about it 
which also indicated that changes were moved on top of new tree.  If 'foo' 
already existed in trunk (or was added by the change as in example I used) 
you wouldn't.

Perhaps it should at least print a warning/info/whatever message when 
switching with uncommited changes?  Or maybe this is another case for a 
global -i/--interactive option ;)  (ref thread re asking for confirmation 
when `commit -m foo` and foo is a file).

Don't know, on one hand if you know and expect that behaviour (which is 
generally useful) there's no problem at all.  On the other hand in case of a 
newbie who just sometimes forgets to commit, it can be surprising.  Oh well, 
you have to learn from mistakes after all.

>
> I believe there was a bug request saying that "switch should refuse to
> create conflicts without --force". Which might be a good balancing point.
>
> You don't want to have to supply "bzr switch --force" everytime you have
> an uncommitted change, as it is a really common operation when working
> on multiple fixes, etc, concurrently. (Or a feature that is built from
> multiple steps.)
>
> However, when it generates a conflict, it is quite confusing and hard to
> recover from.
>
> I suppose the main problem is that the layering means we probably don't
> know whether there is a conflict while switching until quite late in the
> process.
>
> If we were looking into redesigning it, 'bzr switch' with uncommitted
> changes could stage a 'commit' into the repository, and hold on to that
> state so you could have a 'bzr undo-switch'.

Yeah, see what you mean.

+1 for 'undo-switch' :)

>
> It certainly isn't perfect, but it would allow better recovery...
>
> John
> =:->



-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It is intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed  in the governing client engagement leter or contract.
If you have received this email in error please notify support at henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************