Merging folders

[Stefan Monnier]

> $ bzr help bzr.transform.orphan_policy

Hey, cool (tho it doesn't work here with Debian's 2.5.0dev7).

> The case of interest here is when a directory is about to be removed,
> its children, if they are not versioned are moved out of the way: they
> don't have a parent anymore and become orphans (their parent directory
> have ceased to exist).

Ah, I see.  There's also the opposite scenario, when an operation
creates a new (versioned) file/dir somewhere where there is already some
unversioned object, so your description helps clarify what is affected.

> It hasn't been turned on by default when introduced because we want to
> also introduce a distinction between junk and precious files which would
> allow deleting the junk files (*.o, *.pyc for example). This should
> reduce the problematic cases by always deleting junk files and always
> conflicting for precious files. 'move' could still be useful but will
> become more of an edge case.

BTW, note that when removing a directory, a valid option may also be to
leave the non-empty directory unversioned rather than move its content
to bzr-orphans.
Of course, that presumes that when this dir becomes versioned again, it
should simply be re-used rather than considered to be in conflict.

I think a generally good test case to push the limit is to have
a lightweight checkout which you "bzr switch; make" back and forth
between two very different branches (e.g. with one versioning its
"Makefile" while the other generates it from an automake template).
Do we really want this to work reliably in all cases?  I don't know.
But I think we should try to provide some way for Bzr to be as
accommodating as possible in such a scenario.


        Stefan