Bert Huijben wrote on Fri, Mar 20, 2015 at 01:48:49 +0100:
>
>
> > -----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
> 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...
>
> That doesn't make it belong in status directly... How does it work in
> combination with --show-updates (or -u)?
>
To be fair, "svn status -u" doesn't answer the question "What is ready
to be committed?" either. And it uses libsvn_ra, which no other feature
of status does. I think if we had 'status -x-w' and didn't have 'status
-u', we might have made 'status -u' its own subcommand (much like
'switch --relocate' has become a subcommand).
> > Right?
>
> 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.
Let's not bikeshed over where this belongs in the UI. We're in
agreement this may be a useful feature, so let's file an issue for it in
the issue tracker (Timour: could you do this, please?) and debate the
rest only when someone starts a design discussion in preparation for
implementing the feature. I'm not that someone — not today.
Cheers,
Daniel
> (Note that this is the same way as --diff is implemented for log in 'svn'
> itself)
>
> Bert
>
Received on 2015-03-20 03:07:18 CET