On 2/17/06, Julian Foad <julianfoad@btopenworld.com> 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".
>
> 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.
In this we should store translated text base size in entries file.
Because translated text and text base sizes can be differrent, but
this doesn't mean that file modified.
>
> 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.
This wouldn't help, because same file size doesn't mean that file
content is equal.
>
> 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.
Yes, this very bad. Many users reports that Subversion slow and most
of such "slow" is WC.
What about use new Erik's translation API in particular function
svn_subst_stream_translated(). It returns stream for translated file,
so we can avoid creating temporary translated files and compare text
with text-base "on fly"?
Yes, this doesn't help in #791 problem, but anyway improve performance
in your case.
--
Ivan Zhakov
Received on Fri Feb 17 11:16:37 2006