Re: UI interpretation quetsions: --changelist + --depth

Karl Fogel wrote:
> Ummm, how about:
>
> For most commands, '--changelist FOO' restricts the scope to items
> in the intersection of changelist FOO and the specified (or default)
> depth. But for *some* commands, certain special commands, commands
> with trust funds and their own ponies and idyllic summer vacations,
> '--changelist FOO' changes their non-infinity default depth to
> infinity, so that the changelist becomes the only restriction when
> no depth restriction is explicitly given.
>
> Then we just have to decide which commands are special in this way,
> 'info' being an obvious candidate. Are there any others; maybe
> status?
>
> I know people will cry "inconsistency", but I'm not sure consistency
> is a major factor in good UI anyway. Meeting intuitive expectations
> is more important.
>
> -Karl

I spent some time trying to find the right words to describe the behavior we
think we'd want, but ultimately failed. I am (as you *well* know) a big fan
of consistency and predictability, and I'm starting to think that it's bad
enough to have to make such a sweeping change to --changelist this late in
the 1.5 release cycle that perhaps we should just roll with the
easy-to-explain "changelist is always a filter, period" explanation. After
all, it really isn't so hard to change 'svn info --changelist foo' into 'svn
info -R --changelist foo'.

To assist in user adoption of this understanding, I'd be in favor also of
consistently making our subcommands, when invoked with --changelist at a
depth less than infinity and not finding any items of interest in said
changelist, return an error condition that the client can turn into a warning:

    if ((err->apr_err == SVN_ERR_NO_INTERESTING_CHANGELIST_MEMBERS)
        && (depth < svn_depth_infinity))
       printf("Warning: found no interesting members of the requested "
              "changelist(s) within the scope of this operation; consider "
              "re-running with --depth=infinity");

(Though, maybe a cleaner approach would be to add a
found-a-changelist-member notification and track whether or not that had
been called for a given operation. This lets the caller decide what is and
isn't an error, and saves our APIs from having to make such a call.)

Thoughts?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand