Handling filesystem/inventory conflicts in TreeTransform

[John A Meinel]

Aaron Bentley wrote:
> Tree Transform makes a pretty big distinction between
> filesystem/inventory conflicts and merge conflicts.
> 
> A filesystem/inventory conflict is a request to perform an operation
> that is illegal according to POSIX or the Inventory contract.
> 
> Here are some examples:
> - Adding a file to a deleted directory
> - Deleting a directory without deleting its files, first
> - Versioning a file in an unversioned directory
> - Making a directory into its own parent directory
> - Creating a file on top of another file
> 
> 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".

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

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 would also like the newly added file to still be added in the
  working inventory, so that it doesn't get lost accidentally.


- Deleting a directory without deleting its files, first

  Are you talking about versioned or unversioned files? 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.

  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.

- Making a directory into its own parent directory

  Or this.

- Creating a file on top of another file

  Right now you rename the other file to "file.moved", right?


> 
> So often, there's not necessarily anything for the user to do.
> 
> So
> 1. Should we require the user to resolve these? (there's often nothing
> to do)
> 2. Should we consider these to be conflicts at all?
> 3. If they're conflicts, should bzr conflicts list them?
> 4. If they're not conflicts, should we produce a nonzero exit code?
> 5. If they're not conflicts, how should we notify the user that we've
> resolved them?
> 
> Aaron

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

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/ce9a24b2/attachment.pgp