[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

revert behaviour in the light of layered working copy changes

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Tue, 12 Oct 2010 17:29:26 +0200

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.
Received on 2010-10-12 17:30:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.