WC modification detection is reading whole files

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".

Shouldn't it notice that the file size and date are not as expected and return
a "modified" status immediately?

svn_wc__versioned_file_modcheck() translates the file first (if KW or EOL
translation is necessary), and only after that checks its size.

That's called from svn_wc_text_modified_p2() which first checks the time stamps
and returns early if they are equal; afterwards it updates the time stamp if it
has a write lock.

The upshot is that every touched translatable file (e.g., on Windows, every
touched text file) is read and translated at every "svn status". If we were to
store the untranslated size, we could perhaps avoid this.

We even translate every touched file with eol-style=native on Linux. This is
because:

   if (! svn_subst_translation_required (..., force_eol_check = TRUE))

Do we really need that force-eol-check?

Do we care about this inefficiency enough to do anything about it? Should I
file a low-priority issue?

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.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 16 23:07:32 2006