Re: svn status enhancement

I'm fairly sure that you and the people who raised issue #1935 ("svn status too
verbose with svn:externals definitions") want the same thing, really, though
maybe it was expressed with slightly different ideas of how it would behave in
detail. I think you should bear in mind what's said in that issue, maybe
compromise a bit, and aim for your solution to be also an acceptable solution
to that.

Note that your mail thread was brought to this "dev" list after you had started
discussing it, and we haven't actually heard your proposed behaviour stated
first-hand here yet. You were quoted as saying,

> It seems that issue 1935 proposes to suppress ALL info about
> externals unless the "-v" option is given.

No. It wanted to suppress the "Performing ..." lines, and the "X" lines if
"-q" given, but not the statuses of items within an external directory. (The
"--ignore-externals" switch prevents looking into the external directories, so
should remove the "Performing ..." lines and the statuses of items within an
external directory.)

> In which case the output
> would be the same as it is now with a bunch of "empty" status info.

I don't know what that sentence means exactly.

> I want to get status output for externals that actually have some
> status to report. But I don't want the "Performing status on
> external item at..." message when the status for that external item
> would be empty.

OK, but that's incomplete. Do you want that message when the status for that
item is non-empty? Do you really want it, or would you be happy either way?
For what combinations of "-q" and "-v" do you want it?

Issue #1935 also doesn't say explicitly whether the "Performing ..." message is
wanted when there are statuses to display, but it (the July 2004 comment from
Scott Lawrence) strongly implies that the presence or absence of the message
should be controlled only by the switches and independent of whether changes exist.

** Fixed-width font required for viewing this next bit **

Here are tables showing which of the three kinds of information are output in
various circumstances.

(1) As I believe it is implemented at present:

Options (none) --ignore-externals
            ------------------------------- -------------------------------
            -q (none) -v -q (none) -v
-------- --------- --------- --------- --------- --------- ---------

Changes X dir X dir X dir X dir
            Perfor... Perfor... Perfor...
            S dir/foo S dir/foo S dir/foo

-------- --------- --------- --------- --------- --------- ---------

No change X dir X dir X dir X dir
            Perfor... Perfor... Perfor...

-------- --------- --------- --------- --------- --------- ---------

(2) As I believe is proposed in issue #1935. The difference from (1) is that
"Performing..." is not printed unless "-v" is specified.

Options (none) --ignore-externals
            ------------------------------- -------------------------------
            -q (none) -v -q (none) -v
-------- --------- --------- --------- --------- --------- ---------

Changes X dir X dir X dir X dir
                                  Perfor...
            S dir/foo S dir/foo S dir/foo

-------- --------- --------- --------- --------- --------- ---------

No change X dir X dir X dir X dir
                                  Perfor...

-------- --------- --------- --------- --------- --------- ---------

(3) What do you want? Copy (2) and see if any field that you care strongly
about should differ from it. If not, then we're all happy.

I've still been incomplete, omitting the "-q -v" case which is apparently used
by the test suite, but tough, that'll just have to be changed to cope with
whatever "-q -v" does. I don't think we need to specify a publically defined
behaviour for "status -q -v" even though we do for "log".

More recently, Scott Palmer wrote:
> Am I correct then in thinking (what I originally thought, but didn't
> fully grok) that if I think I need to change anything outside of the
> subversion/clients/cmdline folder that I need to slap my self back to
> reality?

Although you ought to be able to solve this within subversion/clients/cmdline,
as C-Mike Pilato says, there's no guarantee that the client library interface
is beautifully designed. It's best not to try changing it in your first patch
but if, after working with it and getting familiar with how it fits into the
software, you have found it really cumbersome, do consider discussing it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 5 19:52:10 2005