Re: Bug: IP address bogusly interpreted as peg revision

[Troy Curtis Jr <tr...@gmail.com>]

On Thu, May 29, 2008 at 2:15 AM, Julian Foad <ju...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Bug: IP address bogusly interpreted as peg revision

[Troy Curtis Jr <tr...@gmail.com>]

On Mon, Jun 16, 2008 at 4:02 PM, Troy Curtis Jr <tr...@gmail.com> wrote:
> On Thu, May 29, 2008 at 2:15 AM, Julian Foad <ju...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org