You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/07/29 14:33:36 UTC
"svn ls" too complex?
Is there a way to use "svn ls" to simply display a list of the
directory entries at a given Subversion URL? This is what scripts
need, after all.
Is there a reason that this isn't the default behavior, for
consistency with the Unix command?
I feel like, having overridden Greg Stein's objection that this isn't
core Subversion functionality, we have gone off into the land of
fluffy features which look cool but aren't really necessary or even
all that useful. I do think "svn ls" is core functionality, but that
core function is to get a list of the directory entries, not to
display them in a pretty table along with other information about
them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by cm...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Mon, Jul 29, 2002 at 10:33:36AM -0400, Greg Hudson wrote:
> > Is there a way to use "svn ls" to simply display a list of the
> > directory entries at a given Subversion URL? This is what scripts
> > need, after all.
> >
> > Is there a reason that this isn't the default behavior, for
> > consistency with the Unix command?
>
> i'd be in favor of having the current behaviour be the 'svn ls -l'
> variant, and having the default just list the filenames.
-v ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Jul 29, 2002 at 01:53:45PM -0400, Garrett Rooney wrote:
> On Mon, Jul 29, 2002 at 10:33:18AM -0500, Karl Fogel wrote:
> > Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > i'd be in favor of having the current behaviour be the 'svn ls -l'
> > > variant, and having the default just list the filenames.
> > >
> > > would anyone have a problem with that? if not i'll change it tonight.
> >
> > We don't support subcommand-specific options.
> >
> > CMike's suggestion to use -v seems good to me, though.
>
> sounds like a plan. i'll make the change tonight.
i just committed this change in revision 2786. let me know what you
guys think.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Jul 29, 2002 at 10:33:18AM -0500, Karl Fogel wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > i'd be in favor of having the current behaviour be the 'svn ls -l'
> > variant, and having the default just list the filenames.
> >
> > would anyone have a problem with that? if not i'll change it tonight.
>
> We don't support subcommand-specific options.
>
> CMike's suggestion to use -v seems good to me, though.
sounds like a plan. i'll make the change tonight.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jul 29, 2002 at 11:41:08AM -0500, Ben Collins-Sussman wrote:
> Because we absolutely loathe, hate, abhor the insane confusion the
> surrounds the cvs commandline client. "Does that -d come before or
> after the subcommand? Ohhhhh, oops".
>
> We have global switches in the svn client on purpose, and it's
> absolute heaven IMO. I can't ever go back. It's a great, liberating
> feeling not having to wonder or worry where you put your switch. :-)
The ordering shouldn't need to matter if your parser is smart
enough. =)
I'm specifically aware of this due to the libtool clone I'm
writing. I have to make the argument parser smart enough to parse
options even when we don't know the 'subcommand' yet (mode in libtool
parlance). -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Ben Collins-Sussman <su...@collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> On Mon, Jul 29, 2002 at 10:33:18AM -0500, Karl Fogel wrote:
> > We don't support subcommand-specific options.
>
> Why not? -- justin
Because we absolutely loathe, hate, abhor the insane confusion the
surrounds the cvs commandline client. "Does that -d come before or
after the subcommand? Ohhhhh, oops".
We have global switches in the svn client on purpose, and it's
absolute heaven IMO. I can't ever go back. It's a great, liberating
feeling not having to wonder or worry where you put your switch. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> I'm not proposing anything. Nick Bastin said we should have
> subcommand-specific options, and I was arguing against him.
Oh, sorry, I didn't realize that paragraph was a continuation of the
argument against. Thanks -- I agree with you completely.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-08-01 at 12:36, Karl Fogel wrote:
> I'm not exactly sure what problem you're proposing solving here...
I'm not proposing anything. Nick Bastin said we should have
subcommand-specific options, and I was arguing against him.
Just to recap, the choices are:
* Options have different meanings before and after the subcommand.
(This is what CVS does.)
* Options have the same meaning for all subcommands, except for
disallowed combinations. (This is what we do.)
* Options have different meanings for different subcommands, but have
the same meaning whether they appear before or after the subcommand.
Can create parsing ambiguities, so this is a non-starter.
* Options have different meanings for different subcommands, and can
only appear after the subcommand name. This is a viable scheme, but
it has its disadvantages, and there's no compelling reason to switch
to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> We do have one sane alternative, which is to totally disallow options
> between "svn" and the subcommand name--"svn ls" becomes one rigid unit,
> almost as if we wanted to install separate "svnco", "svnupdate", and
> "svnls" commands but didn't want to pollute the filesystem. That scheme
> isn't terribly palatable, though; sometimes an option like -q "feels"
> global and people want to put it right after the "svn". We don't want
> to disallow that... but at the same time, we don't want -q to have a
> different meaning if people list it after the subcommand.
Why would it have a different meaning? It should have the same
meaning whether it appears before or after the subcommand.
I'm not exactly sure what problem you're proposing solving here...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Peter Davis <pe...@pdavis.cx>.
On Thursday 01 August 2002 07:57, Nick Bastin wrote:
> any flags that come
> immediately after svn apply to the global svn command, and any that come
> after a subcommand apply to that subcommand
That's the CVS way of doing things, and you immediately end up with extremely
confused users (me). You also end up with identical options that mean
different things based on whether they come before or after the subcommand.
The whole point is that Subversion is not willing to do that. Subversion is
building a better CVS, and context-sensitive arguments are a major
shortfalling which it wants to remedy.
Having to remember to put the "-l" after the "ls" is a major problem, no
matter how insignificant or "I-have-no-problem-with-it" it might seem.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Nick Bastin <nb...@opnet.com>.
On Thursday, August 1, 2002, at 08:33 AM, Greg Hudson wrote:
> On Thu, 2002-08-01 at 02:03, Nick Bastin wrote:
>> Except:
>>
>> man svn
>>
>> and
>>
>> svn man ls
>>
>> should tell you that. :-)
>
> Should tell you what? You quoted my entire message; I can't tell which
> part you're referring to. In case I was unclear, in my hypothetical
> example, "-l" took an argument in "svn co" but not in "svn ls", so "svn
> -l ls co" could be interpreted as either "svn co" with a "-l ls" switch,
> or "svn ls co" with a "-l" switch. The command parser has to
> arbitrarily decide which to pick, which is a bad situation.
Sorry. Should tell you the difference between passing the -l to svn,
and passing the -l to the subcommand 'ls'. My point is the command
parser is not required to make arbitrary decisions - any flags that come
immediately after svn apply to the global svn command, and any that come
after a subcommand apply to that subcommand. There should be no
ambiguous decisions for the command parser (or the user).
--
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-08-01 at 02:03, Nick Bastin wrote:
> Except:
>
> man svn
>
> and
>
> svn man ls
>
> should tell you that. :-)
Should tell you what? You quoted my entire message; I can't tell which
part you're referring to. In case I was unclear, in my hypothetical
example, "-l" took an argument in "svn co" but not in "svn ls", so "svn
-l ls co" could be interpreted as either "svn co" with a "-l ls" switch,
or "svn ls co" with a "-l" switch. The command parser has to
arbitrarily decide which to pick, which is a bad situation.
> This is how ClearCase works, and it makes a certain amount of sense.
Once again, I have no idea what "This" means. (My masters thesis
advisor once told me that my writing would be clearer if I never used
"this" or "that" as nouns, but only as adjectives. I try to follow that
advice.)
> I agree that the cvs situation is out of control, but I think it's
> because it didn't have a consistent vision from the start. I'm not
> saying you should mimic ClearCase, but I do think that at some point
> you're going to regret not having subcommand-specific options, as the
> list of subcommands grows, and the complexities of managing options gets
> insane.
Not really. Since we are sparing with short option letters, we don't
often find ourselves wanting to use them differently in different
commands. The only case where we've kind of wished for
subcommand-specific options is "svn diff", because it's trying to mimic
a command which already has its own option syntax. For that we use the
-x flag.
We do have one sane alternative, which is to totally disallow options
between "svn" and the subcommand name--"svn ls" becomes one rigid unit,
almost as if we wanted to install separate "svnco", "svnupdate", and
"svnls" commands but didn't want to pollute the filesystem. That scheme
isn't terribly palatable, though; sometimes an option like -q "feels"
global and people want to put it right after the "svn". We don't want
to disallow that... but at the same time, we don't want -q to have a
different meaning if people list it after the subcommand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Nick Bastin <nb...@opnet.com>.
On Monday, July 29, 2002, at 12:36 PM, Greg Hudson wrote:
> Well, one of the things we don't like about CVS is that "cvs -l update"
> and "cvs update -l" do two different things, for example. We want
> options to have the same meaning no matter where they appear in the
> command.
>
> But if, say, the -l option takes an argument in the "svn co" command and
> doesn't take an argument in the "svn ls" command, then you can't be sure
> what
>
> svn -l ls co
>
> means.
>
Except:
man svn
and
svn man ls
should tell you that. :-)
This is how ClearCase works, and it makes a certain amount of sense. I
agree that the cvs situation is out of control, but I think it's
because it didn't have a consistent vision from the start. I'm not
saying you should mimic ClearCase, but I do think that at some point
you're going to regret not having subcommand-specific options, as the
list of subcommands grows, and the complexities of managing options gets
insane.
--
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2002-07-29 at 12:32, Justin Erenkrantz wrote:
> On Mon, Jul 29, 2002 at 10:33:18AM -0500, Karl Fogel wrote:
> > We don't support subcommand-specific options.
>
> Why not? -- justin
Well, one of the things we don't like about CVS is that "cvs -l update"
and "cvs update -l" do two different things, for example. We want
options to have the same meaning no matter where they appear in the
command.
But if, say, the -l option takes an argument in the "svn co" command and
doesn't take an argument in the "svn ls" command, then you can't be sure
what
svn -l ls co
means.
So, we have one set of options. Anything terribly complicated is
usually a long option anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jul 29, 2002 at 10:33:18AM -0500, Karl Fogel wrote:
> We don't support subcommand-specific options.
Why not? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> i'd be in favor of having the current behaviour be the 'svn ls -l'
> variant, and having the default just list the filenames.
>
> would anyone have a problem with that? if not i'll change it tonight.
We don't support subcommand-specific options.
CMike's suggestion to use -v seems good to me, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Jul 29, 2002 at 10:33:36AM -0400, Greg Hudson wrote:
> Is there a way to use "svn ls" to simply display a list of the
> directory entries at a given Subversion URL? This is what scripts
> need, after all.
>
> Is there a reason that this isn't the default behavior, for
> consistency with the Unix command?
i'd be in favor of having the current behaviour be the 'svn ls -l'
variant, and having the default just list the filenames.
would anyone have a problem with that? if not i'll change it tonight.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Eric Gillespie <ep...@progeny.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> Sorry to sound defensive. :-) I'm actually kind of -0 on 'svn ls'
> existing at all once ViewSVN comes around. The only reason I created
I completely disagree with this. svn ls is like cvs co -c, only better.
Having the only way to see what's in a repository be by loading up your
web browser seems like a step backward to me.
--
Eric Gillespie <*> epg@progeny.com
Software Developer
Progeny Linux Systems - http://progeny.com/
"When everyone has to reinvent the wheel, many people invent
square wheels."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> I dunno, maybe it's just a matter of our printing function. Maybe the
> default behavior should be to print dirent names, and nothing more.
> Maybe 'svn ls -v' should show the long-form listing. Then 'svn ls'
> would be more consistent with 'svn status', at least in regard to
> verbosity.
+1 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> Is there a way to use "svn ls" to simply display a list of the
> directory entries at a given Subversion URL? This is what scripts
> need, after all.
And scripts can't parse the current, regularized output? :-)
> I feel like, having overridden Greg Stein's objection that this isn't
> core Subversion functionality, we have gone off into the land of
> fluffy features which look cool but aren't really necessary or even
> all that useful.
How is it any less useful than 'svn st -v'? People aren't interested
in the last changed revision/date/author? Or rather, they *are*
interested in seeing the information locally with 'st -v', but you're
saying that they *aren't* interested in seeing it remotely? I'm not
following your line of thought.
> I do think "svn ls" is core functionality, but that core function is
> to get a list of the directory entries, not to display them in a
> pretty table along with other information about them.
'svn ls' does a PROPFIND of depth 1 on a directory, and that's how it
gets back the list of children. Certainly, it could request only the
node-kind property (instead of <allprops/>, as it does now), but that
wouldn't save any extra network turnarounds. There's essentially no
difference. We're not doing any extra labor to retrieve extra
"fluffy" information.
Sorry to sound defensive. :-) I'm actually kind of -0 on 'svn ls'
existing at all once ViewSVN comes around. The only reason I created
it at all is because other dav clients (nautilus, webfolders, cadaver)
are unable to examine earlier revisions. (And the URL for viewing
older revs in your web-browser is non-public.)
But as long as 'svn ls' exists, why hold back information when we
essentially get it for free?
I dunno, maybe it's just a matter of our printing function. Maybe the
default behavior should be to print dirent names, and nothing more.
Maybe 'svn ls -v' should show the long-form listing. Then 'svn ls'
would be more consistent with 'svn status', at least in regard to
verbosity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn ls" too complex?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> Is there a way to use "svn ls" to simply display a list of the
> directory entries at a given Subversion URL? This is what scripts
> need, after all.
>
> Is there a reason that this isn't the default behavior, for
> consistency with the Unix command?
>
> I feel like, having overridden Greg Stein's objection that this isn't
> core Subversion functionality, we have gone off into the land of
> fluffy features which look cool but aren't really necessary or even
> all that useful. I do think "svn ls" is core functionality, but that
> core function is to get a list of the directory entries, not to
> display them in a pretty table along with other information about
> them.
I think it's hard to make claims about what scripts (or people) need
from "svn ls", when we don't have any concrete examples yet. Maybe
this is why it's so easy to disagree on how the feature should look.
But, in the case of a script, since the entry starts in a consistent
column, isn't that enough?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org