On 11/9/06, John Peacock <jpeacock@rowman.com> wrote:
> 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?
Uh, no, because after detranslation, the file looks exactly like the
file's text base: on changed mtime, we always detranslate. So, for the
current code it wouldn't be 'M'. But the detranslation is the step I'd
like to skip for files which are changed in size.
> 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).
Ah! Yes, ofcourse. Resetting the file to 'unmodified' would be a
client side thing, yes.
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:52:27 2006