[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-03-19 17:20:08 CET

"Erik Huelsmann" <ehuels@gmail.com> writes:
>> ------- Additional comments from janhendrik@tigris.org Mon Mar 19
>> 02:40:25 -0700 2007 -------
>> If for any reason the last modification timestamp (mtime) is not
>> changed for a file edited in a local working copy or deliberately
>> reset to the time it had on the last checkout/commit/update, any
>> local change is destructively lost if the file is updated through
>> svn update, even if the filesize has changed, without warning,
>> merging, conflicting. Subversion should never overwrite anything
>> without actually checking, not just guessing from a parameter
>> otherwise always considered as unreliable, useless, worthless, even
>> if this comes at a performance penalty on svn update.
> With the size-caching I committed to trunk, this issue should be less severe.
> OTOH, we could force a byte-by-byte compare when replacing files on
> update. It would mean a major performance penalty on larger updates or
> updates of very large files. It would also mean elimination of a
> data-loss issue.
> My preference would be to switch changed-ness checking of the working
> file to a byte-by-byte compare (which is probably a one-liner).
> Comments?

I agree, given that the byte-by-byte check would only happen if the
sizes are the same. Data is sacred.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 19 17:20:25 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.