Comment 10 for bug 323111

@Martin: This is the current behaviour...

There are distinct issues than can be addressed separately:
- handling junk files so we can safely delete them and *avoid* having these files block the directory deletion,
- handling precious files and generate a conflict because they can't be deleted and block the directory deletion
  (that's the actual behaviour because we consider all unversioned files as precious)

The fix I'm proposing work around the lack of precious/junk files by *not* deleting any of them but putting them aside.
If you feel that the behaviour change is too risky we can keep the actual one activated by default.

Yet, AFAIC (and I'm not alone here), the actual behaviour is a pain because I don't have "precious" files that are not versioned !

Keep in mind that the proposed fix triggers during the conflict resolution of TreeTransform, i.e. we don't know at this point
what the original request from the user was, we are handling the consequences of this request which has generated a conflict.
(Also note that we're talking about the automatic conflict resolution that is run unconditionally for every tree transform, which
is different from the automatic conflict resolution run by 'bzr resolve'. It's unfortunate that the distinction is somehow
confusing and may reveal a design problem, but that's a totally different subject :-/).

Having a proper handling of junk/precious files will *also* address the problem since we should then have enough
information to decide what to do (Only junk files? Delete the directory. Some precious. file ? Tell the user we can't
fulfill his request, generating a conflict or move it aside in a safe place to avoid the conflict and fulfill the user request).

But I've yet to hear reports about the later that can't be addressed by either:
- versioning the precious files,
- moving them to their intended place (or canceling the directory deletion, which is a variant).

So even if/when we implement such handling, the fix will be useful since it will:
- remove the junk files,
- move the precious files in a safe place (which should be an available option anyway).

 Last, but not least, why is it painful today ? Here is a scenario:

- trunk have the bzrlib/benchmark/tree_creator directory (and its associated junk .pyc files)
- branchA remove the directory
- branchA is merged into trunk, generating conflicts: Can't delete bzrlib/benchmark and bzrlib/brnchmark/tree_creator

If we leave the directory in place and for some reason have to revert trunk to a revision older than the one merging branchA,
we generate another kind of conflict leading to bzrlib/benchmark being renamed to bzrlib/benchmark.MOVED.

Rinse, repeat a few times and you end up crying.

This is even more painful if you're working in a loom and you navigate between threads... which is what people are complaining
in the first place and how we end up with the idea of this fix with Robert.

I think Andrew raised an interesting point when he asked for revert being able to re-parent an orphan, the answer to that is:
we can't. 'revert' contract is to restore the working tree into a known state, junk/precious files are not versioned, so there is no
known state we can target. An hypothetical 'undo' may try to address that though, but again it's way out-of-scope for this focused
bug fix.