[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: rationale for 'svnversion' (vs 'svn version') ?

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-03-27 13:53:42 CEST

>> I don't think this should get an svn subcommand. We need to keep our
>> command set small in order to keep our learning curve shallow, and
>> having a lot of neat utilities stashed inside the svn command isn't
>> consistent with that goal.
>> Maybe we could shoehorn this function into "svn info", but I don't know
>> if that can be done cleanly.
>> (I realize that shipping a lot of separate commands in order to get the
>> neat utilities isn't great either. Probably we shouldn't have shipped
>> svnversion farther than the contrib directory.)
> Oh no, it's definitely more useful than that.
> If we were designing it now, I think we would unquestionably make it a svn
> subcommand, but I don't see any point in changing it now.

Obviously not, as you are a hard-knock Subversion developer ;-).

Having commands that are logically acquainted in one place makes sense
for the newbies who gets the learning-curve benefits of coherent
tools, not for the guy who's developed it and knows how it works.

Another example: I've never used svnversion. Not because I haven't
seen it's there or heard it mentioned, just because it's segregated
apart from the other tools into a separate binary. That sort of gives
me the feeling that it's a tool that's deprecated and should not be
used, therefore I haven't. (Ok, granted, if I had *really* needed the
functionality, I would probably have used it..)

Now we're here, is there a good reason why users need download a
separate tool to get the SubWCRev functionality? At first glance,
also *seems* like a hack that would be better off as a 'svn'
subcommand (perhaps an option to a 'svn rev' command?)..

'svnversion' could be included in 1.1.4 with a "Warning: this tools is
deprecated. Use 'svn rev' instead" warning printed to stderr, and
completely removed for 1.2.0..

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 27 13:54:51 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.