I created issue http://subversion.tigris.org/issues/show_bug.cgi?id=4572.
Thank you.
пятница, 20 марта 2015 г. пользователь Daniel Shahaf написал:
> 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 <javascript:;>]
> > > Sent: vrijdag 20 maart 2015 01:30
> > > To: Bert Huijben
> > > Cc: 'Timour Khanipov'; users_at_subversion.apache.org <javascript:;>
> > > 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 <javascript:;>]
> > > > > Sent: vrijdag 20 maart 2015 01:00
> > > > > To: Timour Khanipov
> > > > > Cc: users_at_subversion.apache.org <javascript:;>
> > > > > 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 06:39:10 CET