You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Žiga Osolin <zi...@gimb.org> on 2006/12/18 15:51:42 UTC
Possible bug delete and revert
I deleted some files, then I placed new files (the same name upon them)
and then I said revert, and SVN has overwritten the files. I think SVN
should check if files exist before rewriting with the files last commited.
Regards,
Žiga
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug delete and revert
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 11:26 AM 12/18/2006 -0500, C. Michael Pilato wrote:
>Now, the obvious follow-up question is: "What *should* Subversion have
>done in this situation?" Should the revert have errored out saying that
>the operation was obstructed? Should only the delete scheduling have
>been reverted, leaving your new files to appear merely as modifications
>to the existing versioned files? Should a full reversion have happened,
>but with your new files renamed to something else instead of being
>overwritten?
>
>(I'm kinda partial to the second one there -- revert only the delete
>scheduling.)
For what it's worth, as a user, I think I would find it most logical to
treat the new file with the same name as the delete-scheduled file as
non-versioned content, and to display an error that the revert was
obstructed. I also think that --force should be added to this option with
the semantics of replacing the unversioned file with the original
unversioned one (since that seems like a "force"-ful thing to do), and that
possibly an option should be added to simplify making the new file be
treated as a modified version of the original file.
Other things to think about: What does 'svn rm' do if the local file has
modifications? Should it be possible to toggle the delete scheduling in
both directions without actually touching the WC file or its contents?
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug delete and revert
Posted by "C. Michael Pilato" <cm...@collab.net>.
Oops -- hold off on that issue filing for a bit, and please see other
forks of this thread for more discussion.
C. Michael Pilato wrote:
> FWIW, I agree. Žiga, could you please file an issue in our tracker for
> this? If you've got time to whip up a little shell script that
> reproduces the problem, that'd be great, too.
>
> Now, the obvious follow-up question is: "What *should* Subversion have
> done in this situation?" Should the revert have errored out saying that
> the operation was obstructed? Should only the delete scheduling have
> been reverted, leaving your new files to appear merely as modifications
> to the existing versioned files? Should a full reversion have happened,
> but with your new files renamed to something else instead of being
> overwritten?
>
> (I'm kinda partial to the second one there -- revert only the delete
> scheduling.)
>
>
> Žiga Osolin wrote:
>> I deleted some files, then I placed new files (the same name upon them)
>> and then I said revert, and SVN has overwritten the files. I think SVN
>> should check if files exist before rewriting with the files last commited.
>>
>> Regards,
>> Žiga
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Possible bug delete and revert
Posted by "C. Michael Pilato" <cm...@collab.net>.
FWIW, I agree. Žiga, could you please file an issue in our tracker for
this? If you've got time to whip up a little shell script that
reproduces the problem, that'd be great, too.
Now, the obvious follow-up question is: "What *should* Subversion have
done in this situation?" Should the revert have errored out saying that
the operation was obstructed? Should only the delete scheduling have
been reverted, leaving your new files to appear merely as modifications
to the existing versioned files? Should a full reversion have happened,
but with your new files renamed to something else instead of being
overwritten?
(I'm kinda partial to the second one there -- revert only the delete
scheduling.)
Žiga Osolin wrote:
> I deleted some files, then I placed new files (the same name upon them)
> and then I said revert, and SVN has overwritten the files. I think SVN
> should check if files exist before rewriting with the files last commited.
>
> Regards,
> Žiga
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Possible bug delete and revert
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Dec 18, 2006 at 11:53:51AM -0500, John Peacock wrote:
> On the other hand, in case #2, if the file to be recreated already
> exists, Subversion should error out, since the file is expected to be
> missing from the WC, but it is found anyways.
>
That would seem to make sense to me as well: revert should treat a
revert of a delete over unversioned file the same way as merging an add
over an unversioned file (which I believe is to either succeed without
complaint if the file's the same, or to conflict otherwise).
Regards,
Malcolm
Re: Possible bug delete and revert
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> This is a weird case, Ben. Revert is (mostly) about undoing local
> modifications to versioned files. The local modifications to versioned
> files in this case were the deletion of those files. That there's now
> another file in the spot of the deleted things is not itself a change to
> the versioned file set.
To [possibly] make this clearer, revert is doing two independent things:
1) undoing uncommitted modifications to versioned files;
2) undoing uncommitted modifications to versioned directories.
I think that the principle of least surprise should mandate that in case
#1, Subversion should blow away the local file and replace it with the
repository version without warning, since the file still exists in
modified form in the WC.
On the other hand, in case #2, if the file to be recreated already
exists, Subversion should error out, since the file is expected to be
missing from the WC, but it is found anyways.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug delete and revert
Posted by "C. Michael Pilato" <cm...@collab.net>.
This is a weird case, Ben. Revert is (mostly) about undoing local
modifications to versioned files. The local modifications to versioned
files in this case were the deletion of those files. That there's now
another file in the spot of the deleted things is not itself a change to
the versioned file set. I'm not sure this particular case is as simple
as "you got what you asked for", and the situation isn't helped by the
fact that 'svn status' on a working copy like this gives no warning that
there's something there where nothing should be.
$ ls -1
cvsdbadmin
loginfo-handler
make-database
make-release
svndbadmin
$ svn rm make*
D make-database
D make-release
$ echo `date` >> make-database
$ echo `date` >> make-release
$ ls -1
cvsdbadmin
loginfo-handler
make-database
make-release
svndbadmin
$ svn st
D make-database
D make-release
$
That said, I think my initial response to this thread was a little
premature. We should (as a list) probably hash out what 'svn revert'
means in this scenario, keeping in mind the best experience for users.
Ben Collins-Sussman wrote:
> I don't understand. The definition of 'svn revert' is 'please make
> this file exactly the way it does in the repository'. It not only
> reverts file contents, but reverts delete scheduling. That's what you
> asked for, and that's what you got. It's one of the only commands
> that actually destroys information, so you need to be careful with it.
>
> On 12/18/06, Žiga Osolin <zi...@gimb.org> wrote:
>> I deleted some files, then I placed new files (the same name upon them)
>> and then I said revert, and SVN has overwritten the files. I think SVN
>> should check if files exist before rewriting with the files last
>> commited.
>>
>> Regards,
>> Žiga
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Possible bug delete and revert
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I don't understand. The definition of 'svn revert' is 'please make
this file exactly the way it does in the repository'. It not only
reverts file contents, but reverts delete scheduling. That's what you
asked for, and that's what you got. It's one of the only commands
that actually destroys information, so you need to be careful with it.
On 12/18/06, Žiga Osolin <zi...@gimb.org> wrote:
> I deleted some files, then I placed new files (the same name upon them)
> and then I said revert, and SVN has overwritten the files. I think SVN
> should check if files exist before rewriting with the files last commited.
>
> Regards,
> Žiga
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org