Re: revert behaviour in the light of layered working copy changes

Erik Huelsmann <ehuels_at_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