Hi Mike and everyone!
C. Michael Pilato wrote:
> 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, [...]
>> '--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.
>>
>> [...]
>>
>> 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
>
> [...] 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'.
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?)
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?
(FWIW I've been working with Perforce where this "changelist" idea - and its
name - comes from, AFAIK, so have seen both for myself and for other users how
it tends to get used in practice, and the things users get confused about.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-26 18:47:10 CET