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

Re: Is there really no way to keep the file modification time intact?

From: Jan Hendrik <jan.hendrik_at_myrealbox.com>
Date: 2007-03-08 12:15:40 CET

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.

> Duncan, after thinking about it a bit more, I agree with you. Not a
> bug.

Sure, revert implies losing (or trashing) data. But as far as
Subversion is concerned it should raise eyebrows if finding a file
where to the best of its knowledge there shouldn't be any file
anymore for it has deleted it itself and personally.

No decent OS or undelete or backup tool will go ahead and
overwrite a file that has taken over the original place, not without
requesting confirmation, either if the case arises or in advance by a
special switch. Or Subversion should prevent the creation of a new
file in the old place, e.g. hiding the deleted file or replace it with a
placeholder until the delete was committed. But it cleanly deletes
the file from the WC. Between deletion and creating a new file
there may be no logical bond for the user, there even may some
time pass, so the user is not aware of this at all.

Think of it from a slightly different angle:

Sally creates foo.txt. She has a bright mind and finishes and
commits it quick. Harry also creates foo.txt, but he needs more
time and before committing he updates (as he should do always).
Now Subversion thinks OK, here is Sally's foo.txt, it was added &
committed, so it's legitimate. Harry has a foo.txt, too, but he
hasn't added it, so it likely is not legitimate and can be overwritten
without harm for anybody (Sally is the brighter mind anyway! <G>).
 But no, Subversion would break the update and ask the user what
to do about this conflict.

Subversion raises eyebrows if the user has deleted a file in the OS,
circumventing Subversion, and restores it. This might not be what
the user intended, but at least no data will be lost, on the contrary.
Subversion could also guess Well, the file has gone, so the user
actually wants me to delete it. Alright, done. Say thank you to me
next time.

JH
---------------------------------------
Freedom quote:

     The future belongs to those who believe in the beauty of their dreams.
               -- Eleanor Roosevelt

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 9 12:51:10 2007

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

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