When manually resolving directory conflicts isn't a feature

Talden talden at gmail.com
Thu Apr 9 11:54:14 BST 2009


>> There is a genuine conflict.  Some users will want the directory and its
>> contents to be deleted.  Others may want the directory to be deleted and
>> its contents moved elsewhere.  Others may want the directory to be
>> unversioned and its contents retained.  Others may want the directory
>> and its contents to be untouched.
>>
>> A conflict means that we don't know what to do.
>>
>> Conflict resolution policies are already loosely coupled to
>> TreeTransforms-- we have one for checkout, and one that's used for
>> everything else.  It's easy to imagine letting users configure a policy
>> that's more suited for their particular project, such as deleting
>> unversioned children of directories being deleted.
>>
>> We can also pursue classifying files as "junk", which would be a more
>> general solution, but would make the user model more complex.
>
> I've seen a similar problem when bzr or other python projects have
> removed or renamed directories containing ignored *.pyc files.  In
> fact a pretty large section of users will have ignored files (*~, *.o,
> *.class) in source directories and therefore will eventually be bitten
> by this if they move or delete those directories.
>
> From memory, you can even get a conflict when merging the rename of a
> directory that contains ignored files.  That seems like a simpler case
> where we should just do the rename and move the ignored files with it.
>
> I think the overwhelmingly common case is that ignored files are junk
> and should be deleted when the directory is deleted.  Against this,
> deleting a file when it was wanted is worse than making the user
> explicitly delete it -- but not infinitely worse, and I feel like
> we're generating many conflicts for every case where it saves you.
>
> Maybe we should say ignored files are safe to delete and then create a
> new category 'precious' for things that are not to be added but also
> not to be deleted.  (iirc that's what the term meant in tla but it was
> not fully implemented.)

I think that, if the only paths blocking removal of folder X are
unversioned, X should become unversioned after removing all versioned
content.

And I agree that the unversioned path X/Z can follow the rename and
become Y/Z if folder X becomes Y.

Conflicts should only occur here when an incoming versioned path is
blocked by the unversioned path.

It would be worth summarising any occurrence of these events in the
command output though.

--
Talden



More information about the bazaar mailing list