Re: svn_client_args_to_target_array and peg revisions -> no good

Stefan Sperling wrote:
> On Tue, Jun 02, 2009 at 05:06:39PM +0100, Julian Foad wrote:
>> On Tue, 2009-06-02 at 15:35 +0100, Stefan Sperling wrote:
>>> On Tue, Jun 02, 2009 at 01:38:22PM +0100, Julian Foad wrote:
>>>> Stefan Sperling wrote:
>>>>> On Sat, May 30, 2009 at 11:51:09AM +0100, Stefan Sperling wrote:
>>>>>> I'll need more time diving into the matter to pin-point the exact
>>>>>> cause of the problem.
>>>>> Still talking to myself here, but just following up with latest
>>>>> thoughts in case anyone is listening.
>>>> Hi Stefan. I'm listening!
>>> Great! :)
>>>
>>> Thanks for your comments. I agree that a quick short-term
>>> fix could be made. I'd say we could add peg-rev parsing to all
>>> subcommands (not just 'add') and port those changes back to 1.6.x.
>>> On trunk, we can do the "proper" fix, transforming the target
>>> array from an array of strings to an array of (name, reg-rev) pairs.
>>>
>>> While I got you here, can you explain to me why we moved
>>> client_args_to_target_array functionality from libsvn_subr
>>> into libsvn_client?
>>> I can't find the rational for the move in the log message of r30753.
>>>
>>> See also r33317 which partly restored the functionality in libsvn_subr
>>> as svn_opt__args_to_target_array(), so that e.g. svnadmin doesn't
>>> need to link to libsvn_client.
>>>
>>> Why can't we just put things in one place?
>> Ah... That looks like a mistake. The email in which I advocated it is
>> <http://svn.haxx.se/dev/archive-2008-03/0188.shtml>. I think my flawed
>> reasoning was that "clients" meant "programs that use the Subversion
>> libraries", forgetting that it really meant "programs that communicate
>> remotely to a Subversion server".
>
> It still makes sense to have it libsvn_client because
> svn_client_args_to_target_array() may attempt to contact the repository.
>
>
> I have now taken the simple approach to this problem, and made
> every subcommand parse peg revisions. I added a new helper
> function that subcommands not using peg revisions can use to
> do this comfortably.
>
> The "proper" fix using a new struct separating paths and peg
> revisions is much harder to do and might be overkill.
>
> The patch is below, comments welcome. It passes make check,
> so I will commit it soonish if there are no negative comments.
>
> Thanks,
> Stefan

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.

-- 
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=2361301