"orphan_policy=move" does not preserve directory structure of orphaned files

[Paul Pelzl]

The behavior cited is from bzr 2.4.2.

The "bzr.transform.orphan_policy = move" setting is helpful for avoiding unnecessary conflicts which can be triggered very easily by commands which transform the working tree. Unfortunately, the implementation destroys the directory structure of the orphaned files and corrupts their filenames. This behavior is pretty poor if the user actually does care about the orphaned files; reconstructing the original tree state could require a lot of work if many files are orphaned.

Example: "foo/" is versioned, and contains unversioned file "foo/orphan.txt". If a tree transform needs to remove "foo" then the content of "foo/orphan.txt" is placed in "bzr-orphans/orphan.~1~".

I think that the full filename and directory structure for orphaned files should be preserved. Off the top of my head, I would suggest generating a per-transform UUID and using that as a subdirectory name under bzr-orphans. So for the preceding example, the tree transform would generate an orphan file in "bzr-orphans/SOME_LONG_UUID/foo/orphan.txt".

[Paul Pelzl (pelzlpj)]

(Note that this bug report should not be viewed as an endorsement of the "orphan_policy=move" approach. Even if the behavior is fixed, I don't think this policy actually does what developers want. It would be better to avoid generating any kind of conflict at all when a tree transform wants to remove a directory containing unversioned files... just unversion the directory and be done with it.)

[Vincent Ladeuil (vila)]

> just unversion the directory and be done with it.

If you leave the unversioned directory in place and do the opposite operation that led to the directory being unversioned, you'll get a conflict when trying to restore the versioned directory which will move that directory to <directory.moved> to be able to install the versioned one.

This leads to even more confusion.

So until a distinction is made between junk files (*.o *.pyc which can be deleted) and precious files (which should be preserved), there *is* a conflict that bzr cannot resolve automatically.

So this bug report *is* valid, we need a way to better preserve (and restore) the orphaned files but the fix introducing bzr.transform.orphan_policy was a first useful step addressing *one* use case: stop generating conflicts when junk files were in the way while giving some rough safety net for precious files.

Note that starting with bzr-2.5 you can control the config option from the command line with -Obzr.transform.policy=[conflict|orphan]

Or set the default value in either bazaar.conf, locations.conf or branch.conf

[Paul Pelzl (pelzlpj)]

On Thu, Sep 13, 2012 at 3:12 AM, Vincent Ladeuil <<email address hidden>
> wrote:

> > just unversion the directory and be done with it.
>
> If you leave the unversioned directory in place and do the opposite
> operation that led to the directory being unversioned, you'll get a
> conflict when trying to restore the versioned directory which will move
> that directory to <directory.moved> to be able to install the versioned
> one.
>

Yes, I think "doing the right thing" requires two distinct components:

    1) when a tree transform wants to remove a directory which contains
       versioned files, just unversion the directory with no conflicts
    2) when a tree transform wants to create a new directory in a
       location which already contains an unversioned directory,
       treat it as a no-op.

git demonstrates the desired observable behavior when switching
between branches. (Obviously it's a little different under the covers
since git doesn't track directories at all.) You don't get a conflict
unless versioned file contents differ.

Differentiating between junk and precious files is nice to have, but I
don't think it's as good as "doing the right thing" automatically.