On Mon, Jun 16, 2008 at 4:02 PM, Troy Curtis Jr <troycurtisjr_at_gmail.com> wrote:
> 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/)
>
Needless to say the above was an accident. I clicked 'send' trying to
resize my terminal. And it shouldn't have been sent as I figured it
out....
--
"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:06:07 CEST