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

Erik Huelsmann wrote:
> 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)

...both of which would change the file size and should change the mtime,
so would fall under the 'M' for the current code, no? I'd also think
that this would fall under the "It hurts when I do that => then don't do
that" class of _harmless_ errors. If I edit a file, even it is to
manually unexpand a keyword, I would personally expect that file to show
up as Modified. The fact that it isn't _actually_ modified should only
be a minor surprise when committing (see below).

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

By do nothing I meant that *status* would show the files as modified,
but when *commit*ting, the real nature of the change would be obvious,
nothing would be sent to the server, and the admin directory files set
to keep this file from showing up as modified again (which in the case
of the mucked up keywords sh^H^Hwould also mean restoring the expanded
keyword).

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