[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: Steve Bakke <steven.bakke_at_amd.com>
Date: 2007-03-06 19:17:20 CET

On 3/6/07 10:53 AM, "Jan Hendrik" <jan.hendrik@myrealbox.com> wrote:

<snip>

> I don't follow the list as closely as I did between versions .27 & 1.0
> (it was just the dev list of course, users came in only later) and
> therefore appologize if I am mistaken, but from some recent
> postings I got the impression that the philosophy behind
> Subversion has turned by 180 degrees since. Back then it was
> always that Subversion would go to the moon to prevent any loss of
> user data, these days to me it rather looks like the user has to go
> to the moon himself to accomodate Subversion. (And it seems
> fitting that TortoiseSVN has selection/confirmation dialogs for about

>
> Even more so as I just happened to come accross another issue of
> user data loss, involving no fiddling with mtime or other stuff except
> Subversion. I have not yet checked if it is documented or by
> design:
>
> # Create a new repo and check out a working copy
> $ svnadmin create repo
> $ svn co file:///path/to/repo wc
> Checked out revision 0.
> $ cd wc
>
> # Create a file
> $ echo hello > foo.txt
> $ dir
> 06.03.07 12:40 7 foo.txt
> # Note: file is present and 7 bytes long
>
> # Add and commit it
> $ svn add foo.txt
> A foo.txt
> $ svn ci -m ""
> Adding foo.txt
> Transmitting file data .
> Committed revision 1.
>
> # now we delete foo.txt and create another foo.txt
> # (move would do the dame)
> $ svn rm foo.txt
> D foo.txt
> $ dir
> # Note: there is no foo.txt anymore
> $ echo goodbye > foo.txt
> $ dir
> 06.03.07 12:42 9 foo.txt
> # Note: foo.txt is present and 9 bytes long.
>
> # now we revert our change to foo.txt
> $ svn revert foo.txt
> Reverted "foo.txt"
> $ cat foo.txt
> hello
>
> # The second foo.txt, created after deleting/moving the first one,
> # is lost -- without any warning, conflict, whatsoever.
>

You never committed the file deletion in the first place, so this is not
data loss. If you wanted the second file to be retained, then you need to
commit the deletion first.

At that point, if you created a new foo.txt, a revert command would have no
effect, since it is not under revision control. This is just a case of
mis-using the tool.

>
> So far this other thing with user data lost without notice.
>
> I was just ready to file the mtime-related issue on local changes
> lost on svn update (see http://svn.haxx.se/users/archive-2007-
> 02/1071.shtml), only finding that registering with collab.net isn't
> enough for filing issues, and I have to go through the hoop of
> another application first. I wonder if it really is worth the while, not
> least with a mail account that will die in three weeks anyway, for
> this doesn't seem to be on the user's road to the moon.
>
> I don't mean to become personal, just a little sarcastic.
>
> JH
> ---------------------------------------
> Freedom quote:
>
> Je mehr Freiheit, desto weniger Gleichheit;
> je mehr Gleichheit, desto weniger Freiheit.
> -- Max Horkheimer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 6 19:17:44 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.