On 3/8/2007 6:15 AM, Jan Hendrik wrote:
> Concerning Re: Is there really no way to keep
> Ryan Schmidt wrote on 6 Mar 2007, 21:27, at least in part:
>> On Mar 6, 2007, at 20:49, Duncan Murdoch wrote:
>>>> Steve, if you follow Jan,s script above, you will see that the
>>>> file foo.txt that the user created with the contents "goodbye"
>>>> was deleted by Subversion without notification. That is, by
>>>> definition, data loss, and Subversion should not do that.
>>> Sure it should. He asked to revert the changes, and that's a
>>> request to lose them.
> But not a newly created file that just happens to take the place of
> an old file.
The user made two changes to the file:
1. He deleted the original.
2. He created new content in its place.
Subversion is designed not to try to keep track of changes to a file
unless the user commits them. Because the user didn't commit after step
1, those two changes are equivalent to:
1. Remove the file from version control and then modify its content.
In this case it would be possible for Subversion to notice that there
are actually two changes made, but there are other situations where that
happens, e.g. I "svn copy" a file, then modify it before committing. In
every case a revert means "restore to the state before any changes", and
I think Subversion should be consistent about doing a full revert.
It offers a way to determine what a revert will do: look at "svn
status" on the file before reverting.
Friendly front ends like TortoiseSVN protect you from the data loss that
"svn revert" implies. But I don't think the basic command line client
should start nagging with "are you sure?" messages.
I think you should get this user to use a more friendly front end, you
shouldn't change the standard command line client to suit him. If
you're committed to using the command line client, then train your users
to commit more frequently. There would have been no problem if the user
had committed between the two steps.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Mar 9 13:15:13 2007