On Thu, May 29, 2008 at 2:15 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Troy Curtis Jr wrote:
>>
>> On Wed, May 28, 2008 at 12:56 PM, Julian Foad wrote:
>>>
>>> I took a look. This is completely localised within subversion/svn/; no
>>> public library functions are affected. That makes it rather easy, I
>>> think.
>>>
>>> Basically I'm talking about changing svn_client__args_to_target_array()
>>> to
>>> return an array of (const char *path, svn_opt_revision_t peg) pairs.
>
> [...]
>>
>> My first thought was "no thank you, I've already looked into that and
>> its too much for me". But your comment about it being limited to
>> subversion/svn caught my interest, so I looked at it again. Sure
>> enough, you were right, who would've thought :)
>>
>> I'm not sure what I was thinking before, I seemed to think that the
>> peg revs were processed quite deep, and I have comments in this thread
>> that imply as much. But it really isn't like that. Perhaps it was
>> because a couple of other people were asking for additional things in
>> that returned structure that actually WERE processed deep in the API?
>> I don't remember exactly.
>>
>> So on further consideration I've decided that yes, I'd like to give it a
>> shot.
>
> I'm glad!
>
> BTW, I said it's only used in "svn" but it's used a bit in one or more of
> the accompanying programs "svnadmin", "svnserve", etc. as well.
>
>
>> There are several APIs that expect arrays of targets, but they
>> invariably deal with working paths only or are modification commands
>> that can affect HEAD only (i.e. svn_client_mkdir(),
>> svn_client_delete(), etc) (thus not needing pegs, right?). I guess I
>> will also need to make sure that no peg revisions were specified for
>> those types of commands, and give an appropriate error message if one
>> is found.
>
> Yes, that sounds right.
>
>
>> This was brought up last time and so I'll bring it up again, should I
>> create a brand-new structure to return (like svn_client_target_t for
>> instance), or should I try to use the existing
>> svn_client_copy_source_t. The name on that current one would be
>> generally misleading of course. Should I create my new
>> svn_client_target_t structure and also rev svn_client_copy4() to use
>> it instead of it's special purpose svn_client_copy_source_t?
>
> Create a new one. As it's local to the command-line client program(s) and
> not a public thing exposed by libraries, ... oh, but it will be exposed by
> the public svn_client_args_to_target_arrayN(). In that case, yes, like you
> said, "svn_client_target_t" would be a good name.
>
> Your struct will only have two of the fields that svn_client_copy_source_t
> has, so doesn't replace it, so no point in changing the ...copy4() API. And
> I think your struct might as well have the revision struct embedded in like
> svn_wc_external_item2_t does, rather than another level of indirection like
> ..._copy_source_t uses, since it's small and constant-size.
>
> - Julian
>
Well I hit a bit of a snag and would like some input. I started down
the path of creating a new structure svn_client_target_t that is
returned by svn_client_opt_args_to_target_array(). Things were going
well as I was updating the svn cli commands until I got to
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-16 23:02:40 CEST