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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-27 22:17:52 CET