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

Julian Foad wrote:
> Er, you what?! If the user issues a command with '--changelist foo' as
> the only file selection criterion, then he/she wants to act on the files
> in that changelist. I can't see any other possible interpretation for
> 'svn info --changelist foo'. The same goes for all subcommands - I've
> just run through them all in my head.
>
> From a user's point of view, I interpret '--changelist foo' as "act on
> the targets specified in changelist 'foo'", just the same as '--targets
> foo' means "act on the targets specified in file 'foo'". Any default
> recursion or non-recursion that a particular command assumes would come
> after that step, in my head.
>
> Is this an unreasonable interpretation? Is there another interpretation?
> Does the current implementation behave differently? (Your comments about
> having to pass changelist specifications down through the APIs make me
> suspect the expansion is currently being handled at a lower level than
> I'd expect. If so, is there a particular reason?)

There's a key problem with that interpretation (which is what the feature
used to do) -- it forces you to actually be sitting in the working copy you
care about. The problems with the feature as it was implemented were
exactly the side-effects of interpreting "--changelist FOO" to be some way
of adding targets rather than a way of filtering them. We got silly
behavior like this:

    $ cd /path/that's/not/a/working/copy
    $ svn info /path/to/wc /path/to/another-wc --changelist foo
    svn: error: Path '.' is not under version control
    $

Did this user want to see 'info' on all the items in the 'foo' changelist in
and under /path/to/wc? What about under /path/to/another-wc? Or did they
want to see info on /path/to/wc *and* /path/to/another-wc *and* changelist
members under ... something. What if they squeeze the --changelist option
in between the two specified paths -- did they think it only applied to one
of the targets? Or did they mean ...

Looking at the above, *I* interpret it to mean the user probably wanted info
on items in those two working copies that matched the 'foo' changelist
filter. Never in a million years would I assume that $CWD was of interest
here, and yet clearly it was. The problem, in general, of treating
--changelist as additive is that it needs additional information -- a
working copy to crawl. And that presents problems in the UI, largely
because our command-line is pretty consistent about a) allowing '.' to be
the default target, and b) allowing multiple iterative targets.

Also, different subcommands having different default depths presented a
problem. Does 'svn update --depth files --changelist foo' mean "do a
files-depth update of all items in changelist 'foo'" or "do a files-depth
update of all items in changelist 'foo' that are within files-depth of the
current working directory" or ...?

The situation was a total mess, and nearly every time I tried to use the
feature, I found myself frustrated with its annoying assumptions,
special-case treatment of $CWD, double-crawling of the working copy, and so
on. The current implementation is has a single, easy-to-understand
description and almost[1] no surprises. And better still, if the default
behavior is not what a particular user wants, they can generally *get* that
behavior today using additional commandline arguments.

> Now for the combining semantics. Some said "I'd expect '--changelist
> foo' to be a filter" and others said "I'd expect '--changelist foo' to
> be additive". Both could be useful. We are having enough difficulty at
> the moment just getting the uncombined semantics straight. Wouldn't it
> be best to leave combining as a future extension, and say that, for now,
> '--changelist' is only valid as an alternative to specifying targets in
> other ways?

There was *nothing* "best" about leaving the feature as it was, period.
Seriously, I would rather have removed it entirely (and heard from at least
a couple of other devs with similar opinions) than ship what was there.

I wonder, though -- would your concerns be alleviated if we made one more
change, a blanket policy that when --changelist is specified, the default
depth of the operation immediately becomes "infinity"? That way you could
continue doing the likes of:

    svn info --changelist foo [.]

and yet:

    svn info --changelist foo /path/to/wc

(so you didn't have to cd into the working copy) would also continue to work.

I'd be fine with that change (actually ... I kinda like it), which brings us
closer to the likely expected UI without a slew of per-subcommand special
cases to try to maintain and explain.

-- C-Mike

[1] Still surprising is that when using --changelist with 'svn update', you
     see N different update processes rather than one that only touches the
     changelist items. But this was how it was before I completely rewrote
     the feature, too -- another side-effect of the general problem with
     doing changelist expansion first and then handing the results off to
     N invocations of some higher-level operation.

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