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

Re: A possible svn_wc_text_modified_p optimisation

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-01-14 23:30:46 CET

Philip Martin <philip@codematters.co.uk> writes:
> Propmted by some recent mail about timestamps...
>
> In svn_wc_text_modified_p() the timestamps of the wc and text-base are
> checked to determine if the file is unchanged. Only if this fails is
> the potentially expensive svn_wc__versioned_file_modcheck()
> called. Thus my idea for an optimisation: if after calling
> svn_wc__versioned_file_modcheck() we see that the file is in fact
> unchanged we adjust the timestamp on the text-base so that on
> subsequent calls the timestamp check will be sufficient.
>
> We would need an (apr?) function to set timestamps, of course. It's a
> simple utime call on Unix, don't know about other plaforms.

+1 -- this has been on the "when we have a spare moment" list for ages
now. If you'd like to do it, that would be awesome.

But: no need to adjust the on-disk timestamp of text-base, I think.
Instead, adjust the recorded timestamp in the entries file to the
working file's current mod time. This raises no portability issues.

Note that the entries file timestamp records the most recent time the
working file and text-base were known to be in sync. So this
statemept

> In svn_wc_text_modified_p() the timestamps of the wc and text-base are
> checked to determine if the file is unchanged.

isn't quite true. Rather, svn_wc_text_modified_p() is checking
whether the working file has been modified since the last time it was
known to be unmodified. The optimization is to adjust the recorded
timestamp whenever we have the opportunity.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:56 2006

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.