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

Re: WC modification detection is reading whole files

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2006-02-17 11:46:29 CET

On Thursday 16 February 2006 23:03, Julian Foad wrote:
> For a locally-modified file with keyword translation enabled, I noticed
> that "svn status" processes the locally-modified file every time I run "svn
> status".
...
> Here's a practical example. In my Subversion trunk tree, with 11 files
> locally modified:
>
> $ svn st -q > /dev/null
> $ time svn st -q > /dev/null
> real 0m0.702s
> user 0m0.464s
> sys 0m0.228s
>
> $ touch subversion/libsvn_*/*.[ch]
>
> $ svn st -q > /dev/null
> $ time svn st -q > /dev/null
> real 0m1.764s
> user 0m1.204s
> sys 0m0.536s
>
> These are in both cases repeatable times, when all the files are in the
> OS's disk cache so the disk activity light doesn't even flicker.
How about storing an MD5 of, say, every 64kB of the translated file?
Then a comparision wouldn't need to compare N bytes to N bytes (with approx.
2*N/2 read on average), but could quit after N/2 bytes read ...
Seems an easy change to me.

Of course, an arbitrary number of MD5-sums would have to be stored in the wc -
but having 16Byte for every 64kB is a factor of 1:4096, and that could be
changed to 1:N ... perhaps depending on the filesize (non-translated)?
That would speed-up smaller files too, if a file was cut in eg. 16 pieces and
each MD5'ed separately.

Or is there a reason why that wouldn't work?

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 17 11:48:31 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.