Bert Huijben wrote on Fri, Mar 20, 2015 at 01:48:49 +0100: > > > > -----Original Message----- > > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > > Sent: vrijdag 20 maart 2015 01:30 > > To: Bert Huijben > > Cc: 'Timour Khanipov'; users@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...@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... > > 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 >
