(A new response to this with the benefit of hindsight, on C-Mike's request...)
I understand that, in the current state of Subversion Changelist support,
membership of up to one changelist is effectively an attribute of each file and
directory, and '--changelist foo' filters the set of targets that the command
would otherwise have operated on.
I'm happy enough with that. We now consider a proposal that '--changelist foo'
should alter the default recursion depth of some commands.
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, 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 don't like this proposal for making '--changelist' change the default depth,
whether applied to some or all subcommands.
For a simple command on a single directory target like
svn info --changelist foo .
it sounds handy to have it interpreted as "all the files in changelist foo in
that directory". But with
svn info --changelist foo file1 file2 dir3 file4
I don't see such a good reason why I'd want this to recurse on "dir3" by
default, given that the non-changelist form of that command wouldn't.
We designed "svn info" to have non-recursive (depth=files) behaviour by
default, because we expect that to be useful, and I don't think we should
change it just because a filter is also specified.
I'm not sure, but I can't help wondering if subconsciously underlying this
proposal is an attempt to make a "changelist" behave in a slightly different
way from a plain filter, perhaps more like an object, because we think that's
how the user would like it to behave? But I can't articulate this thought
clearly and there might be no basis to it.
And then there are some commands where unexpected recursion could be worse than
a harmless surprise - especially "svn revert".
The other main objection is just that it's a non-orthogonal behaviour, and
non-orthogonal behaviours are really bad for users to learn, for design
maintainability, and for scripting.
The key decider is whether the user interface benefits strongly enough to
override these concerns. In this case I don't think it does.
>> 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'.
I agree.
> 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.)
I think emitting a warning like this is ugly behaviour, but it's a secondary
concern and doesn't really affect the main proposal.
- 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-28 21:23:36 CET