> -----Original Message-----
> From: 'Daniel Shahaf' [mailto:d.s_at_daniel.shahaf.name]
> Sent: vrijdag 20 maart 2015 01:30
> To: Bert Huijben
> Cc: 'Timour Khanipov'; users_at_subversion.apache.org
> Subject: Re: Status of files with whitespace and EOL changes only
> Bert Huijben wrote on Fri, Mar 20, 2015 at 01:14:20 +0100:
> > > -----Original Message-----
> > > From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> > > Sent: vrijdag 20 maart 2015 01:00
> > > To: Timour Khanipov
> > > Cc: users_at_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
> > > > whitespace and/or end of line style changes. This flag exists for
> > > > 'svn diff' command ('-x --ignore-space-change --ignore-eol-style '
> > > > What do you think of adding similar flags for the 'svn status'
> > >
> > > 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
> > efficient file comparisons possible (preferably just timestamps). Doing
> > things in this generic code that drives many subsystems of Subversion
> > slow many normal operations, and moves away from the model where status
> > 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
That doesn't make it belong in status directly... How does it work in
combination with --show-updates (or -u)?
I agree that it is a useful question to answer in some way, but that doesn't
make it directly belong in status... In my eyes diff is a better fit.
Perhaps it can be added in 'svn' itself, if we determine that it is a
logical operation from 'svn'... But in both libsvn_client, and libsvn_wc I
don't see a relation with any of the other feature of status.
(Note that this is the same way as --diff is implemented for log in 'svn'
Received on 2015-03-20 01:50:54 CET