You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/12/21 17:23:33 UTC
UI interpretation quetsions: --changelist + --depth
I'm trying to decide how Subversion should interpret a command-line like the
following:
svn plist -v --depth files --changelist FOO /path/to/wc
Does this mean, "For all objects in and under (to depth infinity)
/path/to/wc that are in the FOO changelist, do a files-depth verbose
property listing"?
Or does it mean, "For all objects within files-depth of /path/to/wc and
which are in the FOO changelist, do a verbose property listing?"
My instinct is that the latter is more likely the intended use. But that
causes interesting side-effects:
$ svn info /path/to/wc --changelist FOO
## show nothing if wc isn't in FOO; shows wc only (empty-depth) if it is
$ svn info /path/to/wc --changelist FOO --depth infinity
## ah, that's what i meant! info for all my FOO items!
Of course, the former interpretation could be weird, too:
$ svn update /path/to/wc --changelist FOO --depth files
## Grow/shrink only the FOO items to depth files? But they *are* files!
Heaven forbid the interpration be something like, "For all objects within
DEPTH of the specified explicit targets and in CHANGELIST, perform the
operation to the shallower of DEPTH or DEPTH-from-TARGET." Yikes.
Thoughts?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: UI interpretation quetsions: --changelist + --depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: UI interpretation quetsions: --changelist + --depth
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 26, 2008 3:51 PM, David Glasser <gl...@davidglasser.net> wrote:
>
> On Jan 26, 2008 12:38 PM, Mark Phippard <ma...@gmail.com> wrote:
> >
> > On Jan 26, 2008 12:46 PM, Julian Foad <ju...@btopenworld.com> wrote:
> > > 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.
> >
> > FWIW, it sounds like you both are saying it should work the same way.
> > The part that I suspect Julian was missing was that before you made
> > this change many of the subcommands were essentially adding what was
> > in the changelist to what was in CWD which really does not make any
> > sense. And clearly I think a user expects:
> >
> > svn info --changelist foo /path
> >
> > To show the info for the items in /path that belong to changelist foo.
> > That is what Julian says it should do and that is what Mike just made
> > it do with these changes.
>
> No, it doesn't now, because Mike's changes made this mean "show info
> about everything that 'svn info /path' would show which is on
> changelist foo"; since info is by default depth=empty, that would be
> nothing.
Oh, right. But maybe that command is just a bad example because when
I think about it that is probably what I would expect to happen. I
only used svn info as an example because everyone else was.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
>>> No, it doesn't now, because Mike's changes made this mean "show info
>>> about everything that 'svn info /path' would show which is on
>>> changelist foo"; since info is by default depth=empty, that would be
>>> nothing.
>
> I'm happy with it doing that: showing nothing. I don't see that as a
> problem or particularly surprising.
[...]
> Therefore it looks to me like it would be a bad idea to change the
> default depth of these commands. It would be unnecessarily surprising.
Just for clarity's sake, Julian, let's step back to the moment just before
you wrote your original longish mail on this thread, but grant you the
ability to foresee our various responses to it. What mail would you now
write? (I got a little lost in your reply ... just trying to figure out
where you stand at the moment.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: UI interpretation quetsions: --changelist + --depth
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> I do think Julian has at least one valid point: people familiar with
> perforce are going to find svn's definition of changelist a bit odd.
> In perforce, '--changelist foo' is a specific list of paths. It
> doesn't matter where you're sitting in the working copy; it's always
> the same complete list of paths. It really does mean "act on this
> specific list of targets", rather than "do some recursion on some
> target and filter whatever you find".
Ah, yes, whereas a Subversion Changelist is not a distinct entity but just a
name that is a property of one or more files.
Sorry, I'd forgotton that and thereby wrote a long mail heading in the wrong
direction.
It doesn't matter in itself that we have a different concept than Perforce
does: this is a different version control system.
However, be aware that the differences are considerable. A Perforce Changelist
also has a log message and other metadata attached to it. And it can be pending
or committed, like a Subversion Transaction. When Perforce users talk about a
"changelist" they are often referring to what we would call the revision number
of a committed change. And some of us would like to implement a client-side
"pending commit" in Subversion in the medium term. That would be much more like
a Perforce Pending Changelist.
> [paraphrasing: As that doesn't fit into Subversion's WC architecture,]
> Mike's implementation of 'make it a filter' is the only reasonable
> consistent behavior, I think.
Right. And that's OK. (Thanks for the reminder of why it's not like I thought
it would be.)
Most of my previous post was about how a changelist specification should
combine with other target specifications and other changelist specifications on
the same command. Thinking it was a self-contained target specification, I
suggested it should not combine with any other target specifications.
But now, the basic rule is that a command with '--changelist' specification(s)
shall act on the intersection of the targets that the command would have acted
on without any changelist specifications, and the targets in the union of all
specified changelists. (We may want to disallow multiple changelist
specifications in one command, for now.)
Except... There is the suggestion that a '--changelist' option should cause the
default depth of any command to become infinity.
C. Michael Pilato wrote:
> David Glasser wrote:
>>> FWIW, it sounds like you both are saying it should work the same way.
>>> The part that I suspect Julian was missing was that before you made
>>> this change many of the subcommands were essentially adding what was
>>> in the changelist to what was in CWD which really does not make any
>>> sense. And clearly I think a user expects:
>>>
>>> svn info --changelist foo /path
>>>
>>> To show the info for the items in /path that belong to changelist foo.
>>> That is what Julian says it should do and that is what Mike just made
>>> it do with these changes.
No, I didn't say it should do that.
>> No, it doesn't now, because Mike's changes made this mean "show info
>> about everything that 'svn info /path' would show which is on
>> changelist foo"; since info is by default depth=empty, that would be
>> nothing.
I'm happy with it doing that: showing nothing. I don't see that as a problem or
particularly surprising.
> Hence, my suggestion that the presence of --changelist implies '--depth
> infinity' (unless --depth is also explicitly provided). I *think* that
> will please the majority of folks, and I'm sorry I didn't think of it
> before.
>
> Are there objections to my making exactly this change? It should be an
> easy tweak to svn/main.c.
Until now we have restricted the default depth of approximately the following
commands (looking at ones that accept "--recursive"):
info
list
propXXX
resolved
revert
Changing the depth obviously only makes a difference to commands where a
directory target is given. Commands "info", "list", and some of "propXXX" are
harmless if unexpectedly acting on many members of a changelist. But "propdel
dir1", "propset .", "resolved ." or "revert dir2" would be far from harmless.
Therefore it looks to me like it would be a bad idea to change the default
depth of these commands. It would be unnecessarily surprising.
Regards,
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I do think Julian has at least one valid point: people familiar with
perforce are going to find svn's definition of changelist a bit odd.
In perforce, '--changelist foo' is a specific list of paths. It
doesn't matter where you're sitting in the working copy; it's always
the same complete list of paths. It really does mean "act on this
specific list of targets", rather than "do some recursion on some
target and filter whatever you find".
Of course, the reason the perforce implementation is even possible is
because the server is tracking every working copy and every file
'opened' for editing. The list of changed paths is produced instantly
(i.e. no wc tree-walking) by consulting a server database.
So while I *like* this interpretation, there's no way svn can ever get
there unless we teach libsvn_wc to manage a central database of
changelists in ~/.subversion/. Given our current libsvn_wc design,
Mike's implementation of 'make it a filter' is the only reasonable
consistent behavior, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
>> FWIW, it sounds like you both are saying it should work the same way.
>> The part that I suspect Julian was missing was that before you made
>> this change many of the subcommands were essentially adding what was
>> in the changelist to what was in CWD which really does not make any
>> sense. And clearly I think a user expects:
>>
>> svn info --changelist foo /path
>>
>> To show the info for the items in /path that belong to changelist foo.
>> That is what Julian says it should do and that is what Mike just made
>> it do with these changes.
>
> No, it doesn't now, because Mike's changes made this mean "show info
> about everything that 'svn info /path' would show which is on
> changelist foo"; since info is by default depth=empty, that would be
> nothing.
Hence, my suggestion that the presence of --changelist implies '--depth
infinity' (unless --depth is also explicitly provided). I *think* that will
please the majority of folks, and I'm sorry I didn't think of it before.
Are there objections to my making exactly this change? It should be an easy
tweak to svn/main.c.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: UI interpretation quetsions: --changelist + --depth
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 26, 2008 12:38 PM, Mark Phippard <ma...@gmail.com> wrote:
>
> On Jan 26, 2008 12:46 PM, Julian Foad <ju...@btopenworld.com> wrote:
> > 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.
>
> FWIW, it sounds like you both are saying it should work the same way.
> The part that I suspect Julian was missing was that before you made
> this change many of the subcommands were essentially adding what was
> in the changelist to what was in CWD which really does not make any
> sense. And clearly I think a user expects:
>
> svn info --changelist foo /path
>
> To show the info for the items in /path that belong to changelist foo.
> That is what Julian says it should do and that is what Mike just made
> it do with these changes.
No, it doesn't now, because Mike's changes made this mean "show info
about everything that 'svn info /path' would show which is on
changelist foo"; since info is by default depth=empty, that would be
nothing.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 26, 2008 12:46 PM, Julian Foad <ju...@btopenworld.com> wrote:
> 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.
FWIW, it sounds like you both are saying it should work the same way.
The part that I suspect Julian was missing was that before you made
this change many of the subcommands were essentially adding what was
in the changelist to what was in CWD which really does not make any
sense. And clearly I think a user expects:
svn info --changelist foo /path
To show the info for the items in /path that belong to changelist foo.
That is what Julian says it should do and that is what Mike just made
it do with these changes.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by Julian Foad <ju...@btopenworld.com>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by Julian Foad <ju...@btopenworld.com>.
(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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UI interpretation quetsions: --changelist + --depth
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: UI interpretation quetsions: --changelist + --depth
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> I'm trying to decide how Subversion should interpret a command-line like the
> following:
>
> svn plist -v --depth files --changelist FOO /path/to/wc
>
> Does this mean, "For all objects in and under (to depth infinity)
> /path/to/wc that are in the FOO changelist, do a files-depth verbose
> property listing"?
>
> Or does it mean, "For all objects within files-depth of /path/to/wc and
> which are in the FOO changelist, do a verbose property listing?"
>
> My instinct is that the latter is more likely the intended use. But that
> causes interesting side-effects:
>
> $ svn info /path/to/wc --changelist FOO
> ## show nothing if wc isn't in FOO; shows wc only (empty-depth) if it is
> $ svn info /path/to/wc --changelist FOO --depth infinity
> ## ah, that's what i meant! info for all my FOO items!
>
> Of course, the former interpretation could be weird, too:
>
> $ svn update /path/to/wc --changelist FOO --depth files
> ## Grow/shrink only the FOO items to depth files? But they *are* files!
>
> Heaven forbid the interpration be something like, "For all objects within
> DEPTH of the specified explicit targets and in CHANGELIST, perform the
> operation to the shallower of DEPTH or DEPTH-from-TARGET." Yikes.
>
> Thoughts?
Ugh.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org