On Mon, 19 Mar 2007, Karl Fogel wrote:
> "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.
+1. The size-caching should help avoid the occurrences of the
byte-by-byte comparison.
- application/pgp-signature attachment: stored
Received on Mon Mar 19 18:16:38 2007