In the presence of svn:keywords or svn:eol-style, there's currently no
way to detect changedness of a file but to do a detranslation and
compare contents of the text file with its text base.
'svn status' does a full detranslate+compare for files which it has
reason to believe they might have changed: it checks for changed
mtimes. When working copies age, more and more files might have an
mtime which doesn't correspond with the one in the svn admin area
anymore. Thus in order to find modified files all those files will be
fully detranslated+compared.
While a changed mtime can only indicate a file might have changed,
files which differ in size can't contain equal contents (on the
bit-level). So, we can sometimes shortcut the full detranslate+compare
cycle by just looking at the size of the file and comparing that to
the size when we created it. Files which have different sizes must
have changed.
Especially in working copies with very large files (or many changed
files), we could get much faster status results by employing this
algorithm.
But there's one catch: if a file has been modified by changing a
keyword expansion or CRLF->LF (or vice versa), the context *has*
changed since it was written, but when detranslated+compared it's
still equal to the text base.
Now, I think the catch above is an extreme edge case unlikely to
happen. Also, the gain we get from not resorting to full
detranslate+compare outweighs the (very slim) chance for false
positives on 'svn status'.
Peter Lundblad has his reservations. What do others think?
* Does my proposal violate the semantics of 'svn status'?
* Is having an algorithm with only false negatives (not detecting
modified files) better than having an algorithm which also has false
positives (marking files as modified without them actually being
modified w.r.t. the 'repository normal form') and fewer false
negatives?
BTW: Note that by running 'svn revert' the false positives can be
'repaired', but it's hard to find out you had a false negative (which
after you do find it can be repaired with 'touch').
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 9 22:39:32 2006