[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-19 18:32:28 CET

On 3/19/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Mon, Mar 19, 2007 at 09:20:08AM -0700, Karl Fogel wrote:
> > > 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.
> >
>
> Er, but wouldn't that be the common case - when updating an unmodified
> file, for example?

Yes, it would.

> Currently (I'm guessing) we read the text-base and apply the delta to
> produce a new text-base, then copy it over the existing wc file and
> rename it over the text-base. Can we instead read the (believed
> unmodified) wc file and apply the delta to that? We can already check
> the MD5 of a file while we're reading it, so that wouldn't increase the
> amount of data we need to read.

> (And in the case where we believe the file is modified, we'd continue to
> use the pristine text-base).

> Oh, wait, that won't work for translated files... and I'm not sure
> whether we even hold an MD5 of the translated version of the file, so I
> don't know how we'd solve this problem for those files anyway.

No, we don't. (Hold an MD5 on the translated file.) There are of
course ways to use the wc file for updating, but we need to be really
sure any errors we get because of using the wrong base file will be
ignored and we'll carry on to the actual base file. Given how editors
work, this won't be easy to implement. The current update-wc-file code
is triggered after the delta is applied to the base file. All that's
left is to decide to do a merge or a replacement....

bye,

Erik.

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