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

Re: svn_client_args_to_target_array and peg revisions -> no good

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 11 Jun 2009 11:15:10 -0400

Stefan Sperling wrote:
> On Thu, Jun 11, 2009 at 10:21:06AM -0400, C. Michael Pilato wrote:
>> Do we not having a single function that can take a array of const char *,
>> native encoding path-spec arguments and return an array of structures that
>> contain a UTF-8 const char * path field and peg revision? Seems like we
>> could stand to have such a thing if we don't already. We could then have
>> helper functions that accept one of those structures and do other
>> transformations on it, such as expanding shortcut URLs (^/) and IRIs
>> ("http://server/path with spaces") into canonical form, and so on.
>>
>> I dunno ... I guess I just figured that after 9 years, we'd know how to
>> consistently parse our command-line arguments.
>
> Yes, I agree that this is necessary.
> I have opened a new bite-sized issue:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3423
>
> I've just committed my patch in r37988 (which probably triggered your
> response), and I still think it is useful because it should be far easier
> to backport to 1.6 than what you are describing. There are two minor
> tree conflicts, that's all. I'll create a backport branch in a minute.

Actually, it was mere coincidence that you committed while I was catching up
on the thread and composing my response. :-)

What's your backport plan, though? Didn't you add a new public API?
Planning to make it a private/public one?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361322

Received on 2009-06-11 17:15:32 CEST

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.