When manually resolving directory conflicts isn't a feature

[Stefan Monnier]

> Implementing 'precious' vs implementing 'junk' is a bit of a
> tomayto/tomawto situation, but I lean towards implementing 'junk',
> because ignored files are de-facto precious now, and this would minimize
> behavioural change.  We could make junk supersede ignored, so that users
> could put files on both lists for backwards compatibility.

I'd think it's better to try and push the current model as far as
possible before trying to introduce something like "junk" or "precious".
E.g. as people have suggested, it should be easy to say "if removal of
a directory fails because of the presence of ignored files, then just
leave the directory as unversioned".  This makes a lot of sense if you
think that "bzr rm" can mean "remove" as much as it can mean "stop
versioning".  This should be easy to implement and would take care of
one half of the problem.

The other half is when the user switches back to the branch that had
the directory.  For that case, we could use the same rule in reverse
thinking that "bzr add" doesn't only mean "add a new file/dir" but also
"start versioning this file/dir".  So when adding a new directory, if
such a directory already exists but unversioned, just reuse it
silently.

It's not perfect (since you end up with "left over" directories holding
"junk") and will annoy some tools (e.g. build tools which may traverse
all the dirs looking for things to do, running the spurious left over
Makefiles (unversioned junk generated from versioned Makefile.in)), but
at least the conflicts will disappear and the user will be able to "bzr
switch" back and forth just fine.

Of course, another approach altogether would be to consider that
removing a directory is nothing more than "moving it out of the way", so
rather than remove it, it could be renamed to .bzr/lost+found/<dir-id>
from where it can also be resurrected by "bzr switch" later on.


        Stefan


PS: Which just reminds me that I'd like a "bzr undo" command which would
undo the last bzr command.  So after a "bzr switch foo" or "bzr pull",
I could do "bzr undo" to go back to the previous state.  After "bzr
push", I'd expect "bar undo" to do some sort of uncommit in the
destination branch, etc...