Switching between branches with uncommited changes.

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Gliwinski wrote:
> Hello all,
> 
> Wanted to ask before I go logging tickets for it.
> 
> Currently `bzr switch` in lightweight checkout allows you to switch to 
> different branch even if there are uncommited changes.  Is this by design?
> 
> The reason I'm asking is one of my fellow devs was just bitten by it (they're 
> only starting to use Bazaar, or any VCS for the matter and forgetting to 
> commit still happens quite a bit).
> 
> Still it seems to me that shouldn't be allowed by default.  What do others 
> think?

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


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.

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

It certainly isn't perfect, but it would allow better recovery...

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7KPUACgkQJdeBCYSNAAPZmwCgtklrbER3ItBbuIIMpRiblRC0
CIkAn1wbhDst47WimrIBldRpKZATmOkG
=jo2J
-----END PGP SIGNATURE-----