Julian Foad <julianfoad@btopenworld.com> writes:
> 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?
Do we record the unmodified working file size for translated files in
.svn/entries? If so, then we could detect modified-ness this way.
> 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.
Do you mean "store the translated size"? Or are you using
"translated" to mean "translated back from working file to text base"?
(I think of "translated" as being the base->working direction.)
> 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?
The timings you show seem pretty significant. I think it's worth
doing something about, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 17 01:11:21 2006