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

Re: [Issue 2746] New - update overwrites w/o warning local modification if local timestamp did not change

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2007-03-27 03:48:37 CEST

On 2007-03-26 21:35:21 -0400, Mark Phippard wrote:
> I saw references on this list that implied backups can cause it, but
> maybe it was just restores?

The average user doesn't have backups that modify the ctime (BTW,
special backup associated with Subversion make generic backup less
useful -- e.g. I don't feel the need to use one).

> >No, this is wrong if the method is chosen via an option, e.g. most
> >users could choose the mtime-only solution, while Linux users (in
> >particular those who use recode and mv in some ways and don't do
> >operations that change the ctime) could choose the max(mtime,ctime)
> >solution. So, everyone would be happy.
> Adding an option seems like overkill. If someone is burned by this
> problem the are just going to be pissed to find out there was an
> obscure option available.

If the user doesn't read the manual, this is his problem. Other users
shouldn't be punished because of that.

> If someone knows about the problem and the commands that cause it,
> they can also use touch or work around the problem in other ways.

Can you provide a way to use touch *automatically*?

The advantage of a Subversion option is that it can be used
automatically, so that the user won't have to think about it
any time he uses Subversion.

> There still have not been any great examples of why this is a huge
> problem, especially when the trunk code with the additional file
> size check is added.

You shouldn't need a great example. Having lost data is sufficient.

> >A solution that does a full file compare could still be useful. For
> >instance, such a svn status could be run every night and mail warning
> >messages to the user if something suspicious occurred (including
> >a hardware-related problem that corrupted a file without changing
> >the inode data).
> You always have the option of running touch, and then you will get
> your full compare. I do not see adding options as a solution, but I
> do not see us ever agreeing on this either.

Running touch isn't a solution because it modifies the mtime. I don't
want to modify the mtime of every file[*] just to do a full compare.

[*] In addition to losing the mtime, this has very bad side effects,
e.g. for the "make" command.

Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 27 03:48:54 2007

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

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