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 2004/07/27 22:55:03 UTC
svn version subcommand
In r10430, brane committed a change to implement "svn version" as a
subcommand.
As far as I know, this idea came up in some smoky back room and was
implemented without much discussion. I am close to -1 on it because:
* I think we need to keep our subcommand count small. If a user
wants to figure out how to do something, the list of subcommands
is one of the primary places to look. The longer this list, the
longer it will take users to find what they want.
* Subcommands are typically seen as verbs, not as nouns. So people
might get derailed thinking that there is an svn subcommand to
"version" a file or directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> In r10430, brane committed a change to implement "svn version" as a
> subcommand.
>
> As far as I know, this idea came up in some smoky back room and was
> implemented without much discussion. I am close to -1 on it because:
Its discussion was spread out over a long time, and was never very
involved. Not a smoky back room, but not exactly broadcast over a
megaphone either. It's related to issue #1959 (show server version
when given URl), an issue which kind-of-sort-of implies -- but doesn't
come right out and say -- there should be an 'svn version' command.
> * I think we need to keep our subcommand count small. If a user
> wants to figure out how to do something, the list of subcommands
> is one of the primary places to look. The longer this list, the
> longer it will take users to find what they want.
>
> * Subcommands are typically seen as verbs, not as nouns. So people
> might get derailed thinking that there is an svn subcommand to
> "version" a file or directory.
I'm +0 on it. I don't think it will confuse people very much; on the
other hand, if there were a way to add the show-server-version feature
without making this a subcommand, I'd be fine with that too.
-Karl, taking a cue from the current US Democratic National Convention
by straddling both sides.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by kf...@collab.net.
Bill Soudan <bi...@soudan.net> writes:
> As a user, my first thought after reading the email was 'why don't they
> just put that in the output of svn info?' After consulting the SVN book,
> it appears the intention is for the info command to be client side only.
> However, I think it makes sense to extend it to support the concept of
> displaying information about a server as well.
>
> So, how about:
>
> svn info --server: info regarding server for current wc
> svn info --server=URL: info regarding server at URL
The 'svn info' command is for getting information about the data under
Subversion's control, not information about Subversion itself. This
proposed extension of it is inconsistent with its basic purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by Bill Soudan <bi...@soudan.net>.
On Thu, 29 Jul 2004, Greg Hudson wrote:
> > I am +1 on this, if and only if, before 1.2.0, "svn version URL" also shows
> > the server version.
> >
> > CVS has this feature and it is sometimes helpful.
>
> We could do this with svn --version --foo=URL for some value of foo. I
> didn't see any consideration of that and other options, just an
> immediate leap from "we want this functionality" to "new subcommand".
>
> But I'm willing to clarify my vote to -0 based on the new (to me)
> arguments that CVS has the subcommand and that it's hard to find the
> --version functionality in the help output when it's not a subcommand.
As a user, my first thought after reading the email was 'why don't they
just put that in the output of svn info?' After consulting the SVN book,
it appears the intention is for the info command to be client side only.
However, I think it makes sense to extend it to support the concept of
displaying information about a server as well.
So, how about:
svn info --server: info regarding server for current wc
svn info --server=URL: info regarding server at URL
I don't like 'svn version' at all, either. Version of what?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by Mark Phippard <Ma...@softlanding.com>.
Greg Hudson <gh...@MIT.EDU> wrote on 07/29/2004 01:00:05 PM:
>
> If you follow the users list, people talk about "versioning" a file to
> mean "put it under version control and manage it". So people could
> confuse "svn version" with "svn add" or "svn import". As Ben pointed
> out, the result of such confusion would be harmless, but it would still
> be a stumbling point.
I agree that it could be confusing and that all of these requirements
could be added to the current system. I have definitely used the word
"version" in the way you described it for many years and with many
products.
Since no one has mentioned it, would it be impossible to show at least
some of the basic version information in the help output? Maybe it
doesn't need all of the information that --version spits out, but couldn't
it at least include the version number line?
Most people do not seem to have trouble finding the --help command.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-07-27 at 19:18, Max Bowsher wrote:
> > As far as I know, this idea came up in some smoky back room and was
> > implemented without much discussion. I am close to -1 on it because:
>
> I am +1 on this, if and only if, before 1.2.0, "svn version URL" also shows
> the server version.
>
> CVS has this feature and it is sometimes helpful.
We could do this with svn --version --foo=URL for some value of foo. I
didn't see any consideration of that and other options, just an
immediate leap from "we want this functionality" to "new subcommand".
But I'm willing to clarify my vote to -0 based on the new (to me)
arguments that CVS has the subcommand and that it's hard to find the
--version functionality in the help output when it's not a subcommand.
> > * Subcommands are typically seen as verbs, not as nouns. So people
> > might get derailed thinking that there is an svn subcommand to
> > "version" a file or directory.
>
> Typically, but not exclusively (e.g. "help" not "show-help", "resolved", not
> "i-have-resolved").
"help" can be seen as a verb. "resolved" was a sticky case, but there's
at least no confusion possible for it. (And we changed it from
"resolve" because the verb form of resolve was confusing.)
> To "version" (verb) an object doesn't have any meaning to me.
If you follow the users list, people talk about "versioning" a file to
mean "put it under version control and manage it". So people could
confuse "svn version" with "svn add" or "svn import". As Ben pointed
out, the result of such confusion would be harmless, but it would still
be a stumbling point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by Max Bowsher <ma...@ukf.net>.
Greg Hudson wrote:
> In r10430, brane committed a change to implement "svn version" as a
> subcommand.
>
> As far as I know, this idea came up in some smoky back room and was
> implemented without much discussion. I am close to -1 on it because:
I am +1 on this, if and only if, before 1.2.0, "svn version URL" also shows
the server version.
CVS has this feature and it is sometimes helpful.
> * I think we need to keep our subcommand count small. If a user
> wants to figure out how to do something, the list of subcommands
> is one of the primary places to look. The longer this list, the
> longer it will take users to find what they want.
Although I agree that our subcommand set size must remain managable, I think
this addition is worthwhile.
> * Subcommands are typically seen as verbs, not as nouns. So people
> might get derailed thinking that there is an svn subcommand to
> "version" a file or directory.
Typically, but not exclusively (e.g. "help" not "show-help", "resolved", not
"i-have-resolved").
To "version" (verb) an object doesn't have any meaning to me.
However "version" (noun) seems quite clear - the only real thing you can do
with a program's version number is to show it - just like that's the only
thing you can do with a program's help.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn version subcommand
Posted by Ben Reser <be...@reser.org>.
On Tue, Jul 27, 2004 at 06:55:03PM -0400, Greg Hudson wrote:
> In r10430, brane committed a change to implement "svn version" as a
> subcommand.
>
> As far as I know, this idea came up in some smoky back room and was
> implemented without much discussion.
Wow the dev mailing list is a smoky back room:
http://www.contactor.se/~dast/svn/archive-2003-11/0547.shtml
and
http://www.contactor.se/~dast/svn/archive-2004-05/1073.shtml
(which I replied to but doesn't seem to be in the archive,
msgid <20...@synapse.brain.org>).
In which I said:
"I think you've suggested the fix.
svn version : prints out the version of the svn command.
We just leave --version in there for compatability and people that
happen to try it.
What do you think?
"
> I am close to -1 on it because:
> * I think we need to keep our subcommand count small. If a user
> wants to figure out how to do something, the list of subcommands
> is one of the primary places to look. The longer this list, the
> longer it will take users to find what they want.
Yeah and the problem is they can't find out how to get the version of
the client.
> * Subcommands are typically seen as verbs, not as nouns. So people
> might get derailed thinking that there is an svn subcommand to
> "version" a file or directory.
Even if they do get confused the command won't do anything harmful and
they'll quickly realize what it's for.
Plus the intended purpose is to expand it to take an argument and
provide the server version as well as the client version. Which I
realize you're also against.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org