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...@daniel.shahaf.name <javascript:;>] > > > Sent: vrijdag 20 maart 2015 01:30 > > > To: Bert Huijben > > > Cc: 'Timour Khanipov'; users@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...@daniel.shahaf.name <javascript:;>] > > > > > Sent: vrijdag 20 maart 2015 01:00 > > > > > To: Timour Khanipov > > > > > Cc: users@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 > > >
