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

Re: Bug: IP address bogusly interpreted as peg revision

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 29 May 2008 08:15:24 +0100

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

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.