Handling filesystem/inventory conflicts in TreeTransform

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Aaron Bentley wrote:
>>By contrast, merge conflicts indicate that two trees did
>>textually-incompatible things.  E.g. One tree modified a file, and the
>>other tree deleted it.
> 
> 
> I assume merge conflicts also include "one tree modified the same
> location another tree modified".

If we can't perform a text merge, or the text merge has conflicts, yes.

>>Tree Transform will resolve filesystem/inventory conflicts, or die
>>trying.  (If it does die trying, the directory will be unaltered.)
> 
> 
> So are you saying that if it cannot resolve filesystem conflicts, it
> will not be able to merge from the other tree?

Correct.  An example would be if you had

foo
foo.moved
foo.moved.moved
foo.moved.moved.moved
foo.moved.moved.moved.moved
foo.moved.moved.moved.moved.moved
foo.moved.moved.moved.moved.moved.moved
foo.moved.moved.moved.moved.moved.moved.moved
foo.moved.moved.moved.moved.moved.moved.moved.moved
foo.moved.moved.moved.moved.moved.moved.moved.moved.moved

and you were trying to create a file named foo.  It handles average
cases just fine.

> I think we need to handle some things as a case-by-case basis. Specifically:
> - Adding a file to a deleted directory
> 
>   I'm not sure what to do here. To we re-add the directory, or do we put
>   the file in some sort of limbo. I think we need the file to show up
>   somewhere so that someone can look at its contents, and either say
>   "that file needs to be over here", or "that file should be deleted
>   too".

I think we need to restore the directory, put the file in it, and notify
the user.

>   I would also like the newly added file to still be added in the
>   working inventory, so that it doesn't get lost accidentally.

This doesn't only happen with versioned files, but yes.

> - Deleting a directory without deleting its files, first
> 
>   Are you talking about versioned or unversioned files?

Both.

> If it is
>   just unversioned files (say the .pyc files are lying around), then
>   we would remove the directory from the working inventory, but leave
>   the directory on the filesystem.

There are actually two separate resolutions.  One resolves 'remove a
directory that has children', and the other is 'unversion a directory
that has versioned children'.

>   If there are versioned files, we need to leave the directory as
>   versioned.
> 
> - Versioning a file in an unversioned directory
> 
>   I'm not sure how this could actually occur in the wild.

The API permits it.  I don't think merge can produce this except in
cases where the directory is deleted as well as unversioned.

> - Making a directory into its own parent directory
> 
>   Or this.

In THIS, foo is moved into bar
In OTHER, bar is moved into foo

> - Creating a file on top of another file
> 
>   Right now you rename the other file to "file.moved", right?

Right.

> looking at the specific use cases, I think we do need to mark them as
> conflicts, and expect the user to resolve them. I doubt the user wants
> to accidentally commit a "foo.moved" file.

Well, status will indicate that renaming, but okay.

> And if there is a file in a
> directory which is supposed to be added, but can't because the directory
> is not versioned, the user should be aware that they aren't adding a
> file they thought they were adding.

That case won't happen.  The creative side is always taken.  That is, if
there's a conflict between versioning and unversioning, the resolution
will favour versioning.  If there's a conflict between deletion and
creation, the resolution will favour creation.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD8jQk0F+nu1YWqI0RArZfAJ9ZR1UUfBHEQqpuOXE1cxtpUHYwGwCeKDqF
UFtDbhIi/AmZd7XM5U2kxwc=
=J1m5
-----END PGP SIGNATURE-----