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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-29 09:16:03 CEST