Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> This discussion for example is perhaps closing in on
> that :)

Yes.  I'll have one last go at it though.

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>>> I'll be like that once for every file.
>>
>> Yes, for decades.
>
> Are there so really so many files that are left
> untouched for so long?

Not files, no, I'm talking about *lines*.

Perhaps an example will clarify things....  Here is the (fictional)
output of "svn annotate" on a fictional file:

$ svn blame nasty.c
     103      sally /* important_parameter should be */
     103      sally /* set for modern memory sizes. */
     115      harry int important_parameter = 42;
     103      sally

For each line the revision is given when the file was changed, and the
person who changed it.  You can get this with C-x v g from Emacs.

Let's say that version 115 was a reasonably recent.  In that case it's
likely that Harry set tuned important_parameter for current memory sizes
at that time.

But, what if Harry just deleted some extraneous whitespace from the end
of the line?  In that case we can't be sure when important_parameter was
last set.  It may be very old.

Removing the whitespace change we may have the situation:

$ svn blame -x -b nasty.c
     103      sally /* important_parameter should be */
     103      sally /* set for modern memory sizes. */
      24      terry int important_parameter = 42;
     103      sally

This shows that the last actual change was in revision 24, which was
years ago.

In the Subversion manual it explicitly mentions this situation.
Subversion has a command to deal with it, "-x -b", which ignores
whitespace changes.  Not all version controls systems have that.  It's
also not very well known and tools that use the VC system (GUIs and
Editors) may not use it.  Stefan mentions that Git has a way of doing
this too.

When all the tools deal with this situation well then I'll be happy with
indiscriminate whitespace changes, but we're not at that point yet.

BR,
Robert Thorpe