Re: RFC: Changing conditions for 'M'odified status

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?

> * 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), 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.

My 2 cents...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org