revert behaviour in the light of layered working copy changes

[Erik Huelsmann <eh...@gmail.com>]

As Julian pointed out, I'm working on making 'revert' work with our
NODES table in the layered design situation. As part of that work, I
was studying the current behaviour of revert: supposedly, that's what
the behaviour of the new revert should look like in simple cases.

However, one of the things I found is that revert leaves unversioned
artifacts behind. While I'm aware that in some situations this is part
of the policy (don't delete uncommitted changes), in case of revert,
it's rather unpractical for a number of reasons:

1. The artifacts left behind can cause botched merges later on - even
with our current client
2. The artifacts can lead to obstructions in the new working copy
model when we're going with the model of "incremental reverts" that
Julian proposed

Even if we want to prevent the deletion of uncommitted changes -which
I'm going to challenge next- I think we leave behind way too many
artifacts: all files and directories which were part of a copy or move
tree-restructuring operation are left behind on revert. Now, The
problem here is that the files are even left behind if they were
unmodified - and hence reproducible - by which reasoning no
destruction of local modifications could have happened in the first
place.


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.


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.

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.


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.


Comments?


Bye,


Erik.

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

[Julian Foad <ju...@wandisco.com>]

On Tue, 2010-10-12 at 17:04 +0100, Philip Martin wrote:
> Erik Huelsmann <eh...@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

I agree.

> > 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 issue here is about an add that's inside some other tree operation
that the user wants to revert.  Let's say the user locally deleted the
file "A" and then replaced it with a copy of the directory tree "B", and
then locally added a file "A/foo".  Now we ask Subversion to revert "A"
recursively.  We want Subversion to return "A" to its original base
form, which was a file.  We can't do that while also saying that "A/foo"
should remain on disk.

- Julian


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

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

[Philip Martin <ph...@wandisco.com>]

Erik Huelsmann <eh...@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