I started working on a patch to record the size of the (unedited)
working copy file in the entries file. Using 1 stat() call and this
value, we can detect whether the working copy file has changed,
without the need to detranslate.
This change can get us 2 things:
- Gain some independence from mtimes: A file which changed in size
clearly has changes, even if the mtimes stay the same
- Gain in performance in case there are translation-influencing
properties in the game: currently, to establish 'changedness' of the
wc file, libsvn_wc needs to detranslate it to compare to the
text-base.
These numbers is what I got from a (rudimentary implemented) patch for
'svn status' (in 2 runs):
with keyword props
old new
run 1 1.8 0.1
run 2 1.2 0.1
without keyword props
old new
run 1 >0.1 ~0.1
run 2 >0.1 ~0.1
Given these numbers, I thought to implement the feature as follows:
A new field (text-size) will be added to the svn_wc_entry_t structure.
If this field contains a 0 (nul) value, the text-size cache is unused.
Any other value means the working copy file size was originally that
value.
The value of the 'text-size' field will be kept up to date as follows:
- all committed entries will have their text-size cached
- all locally unmodified updated entries will have their text-size cached
- all locally modified updated entries will have their text-size field
set to 0 (nul)
- moved and copied items have their entire entry copied (including the
text-size value)
- reverted items will have their text-size reset to the wc file size
after revert
This change will mean:
- That we will be marking files which have edited keyword values as
modified (we currently don't: we detranslate, making those changes
invisible)
- That we will be marking files with changed sizes as modified - even
if the mtime hasn't changed - which we currently don't (they show up
as unmodified)
- We will gain 'svn status' speed with many changed files and
svn:keywords (but no extra stat() calls for the case of where no files
changed)
- We gain some independence from mtimes
Comments?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 25 23:49:38 2006