Erik Huelsmann <ehu...@gmail.com> writes: > This is why I'm now proposing that we stop to leave behind the > -unchanged- files which are part of a copy or move operation.
That sounds reasonable to me. I'd be surprised if making a versioned copy and then using revert to make it unversioned is something that users do deliberately > One could argue that the same reasoning could be applied to added > trees. However, in that case, you might also apply the reasoning that > the subtree should stay behind unversioned: it's afterall only the > 'add' operation which we're reverting and deleting the added subtree > might actually destroy users' efforts. I think revert should undo the add and leave the unversioned item. > The tricky bit to the reasoning in the paragraph above is that we > don't check if files have been fully changed (effectively replaced) or > not, meaning that simply reverting a versioned file could in effect > have the same consequences as deleting an added file. I don't understand that paragraph. > With respect to "keeping around unversioned reverted-adds", I'm not > sure what to propose. What do others think? I'm inclined to argue > along the lines of "they're all delete operations", however, given our > current behaviour, I also see why users wouldn't expect this > behaviour. The user may want to undo the add and keep the unversioned item (revert) or undo the add and remove the unversioned item (delete). I think we ought to continue to support both of those. -- Philip
