[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-11-09 23:11:26 CET

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...



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

This is an archived mail posted to the Subversion Dev mailing list.