On 11/9/06, John Peacock <jpeacock@rowman.com> wrote:
> Erik Huelsmann wrote:
> > 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.
>
> But the user has to have done something in order to change the keywords
> or the EOL characteristics, right? Don't we already know that
> svn:keywords or svn:eol has been changed and force the file itself to be
> considered "changed" for purposes of status?
Ah, yes, but I was talking about changing the actual keyword or eol
expansion in the file itself, ie
$Revision: 21230 $ edited to $Revision$ (but the rest of the file
stays the same), or
CRLF replaced with LF (but the rest of the file stays the same)
> > * 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?
>
> False positives are merely a waste of a little CPU (since we'll go
> through the motions and then do nothing),
Well, the 'do nothing' would mean - in my optimization - to output 'M'
for this file.
> whereas false negatives may
> cause loss of information (i.e. I run `svn st` and seeing none, blow
> away my WC, not realizing that there _are_ changed files). I vote for a
> chance of false positives if that [significantly] reduces the chance of
> false negatives.
But the other option would be to force a full detranslation+compare
when the size is changed instead of only looking at the mtime. That
will reduce the number of false negatives, but keep the number of
false positives at 0 (at the cost of extra 'svn status' time).
IOW, there wouldn't be an optimization anymore...
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 23:12:37 2006