Handling filesystem/inventory conflicts in TreeTransform

[John A Meinel]

Aaron Bentley wrote:
> 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 guess I'm okay with that. As long as it is clear why we can't merge
the other tree.

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

This is not very obvious. Especially when there are lots of other
legitimate renames.

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

After discussing all of this, I really do think these should be marked
as conflicts that need to be resolved. And probably 'bzr conflicts'
should print out *why* the files are conflicted. So that the user knows
these are text conflicts, this file was added into a deleted directory, etc.
Sure it says all this when you do the merge, but when I'm resolving
conflicts, I frequently do "bzr conflicts" take the first one, resolve
it, go to the next one, resolve it, etc.
Because resolving involves spawning an editor, and thinking about the
contents, and can be rather involved, and take up a lot of lines, it is
easy to lose memory about what still needs to be resolved and why.

If we don't mark them as conflicts it is very easy to commit these
changes, which don't end up having any meaning. So you have an extra
test_foo.py.moved file, which isn't getting run, but you aren't aware
that it is sitting there. Or you have a file in a directory that needs
to be elsewhere, but never got moved.

I realize people could just be really careful about reviewing the
changes (bzr status/bzr diff), and just check every single line to make
sure it makes sense. But some changes are more likely to be wrong than
others, and I think that is what 'conflicts' is for.

If something merges cleanly, it means that the result is 90% likely to
JustWork. A file.moved is not in that 90%, and means it should be marked
as conflicted.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060214/2f13664b/attachment.pgp