Merging folders

[Vincent Ladeuil]

>>>>> Stefan Monnier <monnier at iro.umontreal.ca> writes:

    >> $ bzr help bzr.transform.orphan_policy
    > Hey, cool (tho it doesn't work here with Debian's 2.5.0dev7).

The option have been implemented long ago (circa bzr-2.3), the help
command gained the ability to display options only recently (2.5b1 ?).

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

Right, I think the unversioned object in this case is still renamed to
.moved.

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

Well, when the branch you merge remove the directory, 'bzr merge' should
remove it, there is no such thing as an unversioned directory in the
*branch* you're merging from. So what is needed is really to remove the
directory, knowing that all versioned children have been removed. If
something is left, it comes from the tree itself. And as mentioned
before, the remaining files may be precious/junk/ignored/unknown. To be
on the safe side, they are all moved 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.

This could happen in the tree itself (dir unversioned but kept and added
again) with or without intervening commits, but not from a merge.

So if the tree has the unversioned directory it means it removed it and
if the merged revision also removed it, there is no conflict.

I may have missed an edge case that is not supported but that would be a
bug (or just a different kind of conflict that could also requires
orphan support).

The orphaning itself is a pretty rare case.

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

With an orphan_policy set to true, it should. The fallout is that the
bzr-orphans directory fills up and we don't provide tracking there (new
orphans get a .~n~ suffix). The basic idea is that bzr-orphans suddenly
pops up as unknown in 'bzr st' output and the user is supposed to
purge/remove it as soon as he see fit but no later ;)

I think the Makefile example is a good one (thanks ! I'll try to reuse
it in tests to make them clearer, python devs triggers the same kind of
issue when adding/removing packages where .pyc (compiled version) are
generated automatically).

Using looms is also a known trigger-happy setup ;)

I'd love to have feedback, if you have a setup/workflow where it makes
sense, about whether it scales in a day-to-day usage. As mentioned
above, this is a rare case. Since I enabled the option, it served me
well and I don't think I had to rm-fr'ing bzr-orphans more than once a
month on average, so the lack of chrome around the bzr-orphans directory
handling has not been a big deal.

I didn't put much effort into a better tracking (a la
!dir!subdir!file.~n~ to preserve the dir name for example). But it can
be done.

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

File a bug if it doesn't, I've never encountered issues while using this
option but I don't use lightweight checkouts myself (I don't think it
matters much tough, how the branch and the tree are related is not
really relevant for this).

        Vincent