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
> 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.
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.)
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-15 18:06:58 CET