bzr switch has moved one of my files to .THIS and wants to add it to the branch

The relevant parts of ~/.bzr.log do not appear informative, but here they are.

1 & 2. I suspect that when the conflict happened during the merge, bzr did the equivalent of "bzr mv proposal.tex proposal.tex.THIS". I don't think bzr should do that, it's just confusing.

3. I think this is intentional, so that conflict files are extra visible in "bzr status" output. Usually when you do "bzr resolve foo" any foo.BASE/THIS/OTHER files will be automatically deleted. Again, I'm not sure that describing conflict dropping as "unknown" is a good idea, but it doesn't seem unreasonable to me either. In combination with 1 & 2 it makes the situation look even worse though, because a single conflict has caused several different types of changes.

Since it's probably relevant, I apparently didn't commit proposal.tex to /branch/author-writeup before the fateful bzr switch to /branch/gamon-sentiment-results

diff "Reports/Experimental Proposals/Author sentiment characteristics/proposal.tex.THIS" "Reports/Experimental Proposals/Author sentiment characteristics/proposal.tex.BASE"
5d4
< \author{Mary Gardiner}

"... a single conflict has caused several different types of changes."

And each of these must be resolved separately. I would have wasted far less time here if Bazaar had eaten my working directory alive rather than move pieces of it around unpredictably.

Oh, apparently the goal here was to simply switch a lightweight checkout (which didn't have any uncommitted changes)? The original tree/branch had proposal.tex (in a directory), and the target branch doesn't have that file or the directory, AIUI. If so, it's pretty that bad that bzr has given a bunch of conflicts and other noise rather than just deleting the directory and file as desired.

Bazaar will never delete the directory as desired, because LaTeX leaves .aux and .log files behind it and Bazaar won't delete non-versioned files.

However, I think the directory did in fact have uncommited changes (although I didn't intend this, I just forgot to run "bzr st" before "bzr switch"). I'd have preferred switch refuse to run than have this happen though.

> However, I think the directory did in fact have uncommited changes
> (although I didn't intend this, I just forgot to run "bzr st" before
> "bzr switch"). I'd have preferred switch refuse to run than have this
> happen though.

It is a feature that switch will work when there are uncommitted changes.
The uncommitted changes will be preserved in the resulting working tree.
I've personally found this useful, not merely thought it sounded like a neat
idea :)

What sucks is if there are conflicts then you end up with a mess that is
hard to undo. i.e. the sequence of "bzr switch foo" / oops I didn't want to
switch yet / "bzr switch old" is intuitive and fine when there are no
conflicts. So perhaps a good feature would be if "bzr switch" first checked
there will be no conflicts before actually changing the tree, with a --force
to override?

Or I guess a reliable way to undo bad switch/merge/update would do, i.e. get
back the original tree with the same uncommitted changes as before the
merge, with no conflict markers or other noise. In theory all the necessary
information should be there.