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

Re: Bad performance with large binary files

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-04-07 18:09:16 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> On Wed, 2004-04-07 at 10:24, Folker Schamel wrote:
>> I think I've read that after a revert or after undoing changes
>> the comparison is always necessary for this file.
>> Is this correct?
> Where did you read that?
> My understanding is that whenever libsvn_wc discovers that a file is
> unchanged (by brute-force means), it changes the timestamp within the
> .svn/entries file to match the current working-file's timestamp. Thus
> "reinstating" the optimization. Didn't Philip add this feature?

I did, but it's not quite as you describe: only libsvn_wc operations
that take a write lock are able to fix out-of-date timestamps. Thus,
in practice "svn commit" and "svn revert" are the only commands that
both detect the out-of-date timestamp and take a write lock. There
was a brief discussion about adding an explict "svn fix" or perhaps
"svn st --fix".

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 18:09:43 2004

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.