On Sun, Feb 1, 2009 at 10:50 AM, Robert P. J. Day <rpjday_at_crashcourse.ca> wrote:
> On Sun, 1 Feb 2009, Mark Phippard wrote:
>
>> On Sun, Feb 1, 2009 at 10:38 AM, Robert P. J. Day <rpjday_at_crashcourse.ca> wrote:
>> > at the moment, i'm looking at the (gack) 1.4.3 version of svn so
>> > it's quite possible that this exists in a later version, i just can't
>> > tell.
>> >
>> > is it reasonable to suggest that "svn info" be extended to accept
>> > options as to *precisely* which bit of info you want? as in, --url or
>> > --root or --uuid or ... well, you get the idea.
>> >
>> > i ask since we have a build structure which frequently invokes "svn
>> > info", then runs the output through grep and sed to extract some of
>> > those fields. it strikes me that it would just be easier to support
>> > those options, and i can't imagine i'm the first person who ever
>> > wished they existed.
>> >
>> > am i totally out to lunch here? i mean, on *this* issue.
>>
>> You are basically saying you would like command-line options to
>> indicate what data you want to get back from svn info. You are not
>> out to lunch, but the request does against the grain of the SVN
>> philosophy of keeping the output easy to parse and the command line
>> options simple. SVN already provides a lot of reasonable options
>> here:
>>
>> 1) The output of the command is easy to parse
>> 2) The command supports XML output for alternative easy to parse options
>> 3) Subversion provides libraries that are easy to use from a number of
>> different programming languages and which provides direct access to
>> whatever information you desire. Those libraries maintain a strict
>> compatibility contract so that your code does not have to be modified
>> every time there is a new Subversion release.
>
> fair enough, but just one observation -- i'm not sure what a "strict
> compatibility contract" has to do with this, since such an extension
> would clearly be backward-compatible, would it not? i wasn't
> suggesting changing anything, just adding.
What I meant by that is that if you decided to say write a
Python/Perl/Ruby/Java tool that used the libraries directly, such as
the libsvn_client API for the info command, then you do not have to
worry about Subversion 1.6/1.7/1.8 requiring you to rewrite it because
the API you used is no longer available. It might be deprecated in
favor of a new API, but it would still exist and work.
So I was not suggesting that this is a reason SVN does not add new
options. It adds new options all the time, just carefully. I was
suggesting this is a GOOD reason to take advantage of Subversion's API
and just write a script to do what you want that avoids the parsing.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1085829
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-01 17:04:57 CET