Comment 11 for bug 323111

On 18 September 2010 19:17, Vincent Ladeuil <email address hidden> wrote:
> @Martin: This is the current behaviour...

The difference, I think, is that they were suggesting the directory
would be left behind but not conflicted. Just present and presumably
unknown (or maybe ignored.)

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

I know, I do hit this too. :)

What I typically do then is delete that directory, which in the
absence of a junk file category is a reasonable thing to do: ok,
really delete them. The annoying part is that you then need to
manually mark all the involved directories as resolved, when it ought
to be obvious that they are resolved.

I'm not convinced that generating a bzr-orphans directory that I then
need to remove is really all that much better.

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

istm that's another bug, perhaps: if we want to transform to add a
directory, and the directory already exists but is unversioned,
perhaps we should just use it and then recurse down in to it

Having been through this, at the moment I think we should add the
mechanism, but perhaps leave the default on leaving them where they
are, and then make it easier to resolve the conflict by removing the
directory?

--
Martin