On Tue, 2010-10-12 at 17:04 +0100, Philip Martin wrote:
> 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
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.
>
Received on 2010-10-12 18:49:26 CEST