Bert Huijben wrote on Fri, Mar 20, 2015 at 01:14:20 +0100: > > > > -----Original Message----- > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Sent: vrijdag 20 maart 2015 01:00 > > To: Timour Khanipov > > Cc: users@subversion.apache.org > > Subject: Re: Status of files with whitespace and EOL changes only > > > > On Fri, Mar 13, 2015 at 04:40:14PM +0400, Timour Khanipov wrote: > > > It would be nice however for the 'svn status' command to have a flag > > > which would not show or mark in a special way the files which have only > > > whitespace and/or end of line style changes. This flag exists for the > > > 'svn diff' command ('-x --ignore-space-change --ignore-eol-style ' etc). > > > What do you think of adding similar flags for the 'svn status' command? > > > > Sounds like a good idea. > > > > If your working copy is single-revision (`svnversion` doesn't print > > colons or letters), you could simulate that functionality with: > > > > % svn diff --summarize -r BASE -x-w > > I'm not sure how well it fits the status implementation. > > Status is completely optimized for performance and usually it does the most > efficient file comparisons possible (preferably just timestamps). Doing more > things in this generic code that drives many subsystems of Subversion would > slow many normal operations, and moves away from the model where status just > reports what is modified/ready for commit.
Well, two things. First, "status -x --ignore-all-whitespace" does seem like a logical operation: "What has changed, other than whitespace". That is, "what are the functional changes ready for commit". Second, I assumed it could be implemented without slowing down other uses of status. The meaning of "-x --ignore-all-whitespace" would be "consider as unmodified some files that would otherwise be reported asĀ 'M'". Therefore, the extra cost for regular status runs (those that don't ignore whitespace changes) should be a single boolean flag check ("was -x passed?") for each file about to be reported as 'M'. Sure, 'status -x-w' itself would have to do a diff for each file that has changed, but users who won't use that feature won't notice an extra cost... Right? > Daniel: diff --summarize ignores all file contents, so it just ignores the > -x -w arguments, just like it ignores --git. > (It drives the complete diff code, except for looking at actual file > contents). And -r BASE would +- the default behavior, so doesn't require a > flag. I stand corrected. Daniel