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

Re: API review - svn_ra_get_mergeinfo2()

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 1 Jul 2011 12:31:45 -0400

On Wed, Jun 29, 2011 at 11:16 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Wed, Jun 29, 2011 at 4:48 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
>> On Tue, 2011-06-28, C. Michael Pilato wrote:
>>> On 06/28/2011 01:37 PM, Paul Burba wrote:
>>> > Hi Julian,
>>> >
>>> > I hadn't realized using in-out parameters was considered such bad
>>> > form.
>>>
>>> At a minimum, they force an API divergence in our bindings layers.  +1 to
>>> separate and explicit in and out parameters.
>>
>> Hi Paul.  As you noticed, we do use in-outs sometimes, at least
>> privately, so it's not always considered such bad form, but in this case
>> it looks like using separate params would be better for at least a
>> couple of reasons.  I wasn't even aware of the bindings issue.
>>
>>> > If we need to change this, then your second alternative, splitting
>>> > the parameter into two, seems the more straightforward option.
>>> > I'm happy to make the change if that is what we want.
>>
>> Thanks.
>>
>> I will just ask once more: as a matter of principle, are we comfortable
>> it's OK to provide only an indication that "the server did in fact do
>> this for you this time", but not to have a way of finding out in general
>> whether the server is capable of doing this?
>
> On further reflection, I think using a server capabilities check is
> the better approach:
>
> First, it is consistent with our current approach in similar circumstances.
>
> Second, it eliminates pointless round-trips when a 1.7+ client asks a
> 1.5-1.6 server to validate inherited mergeinfo.  The server obviously
> can't do it, but returns the inherited mergeinfo, along with the
> output parameter which effectively says, "Here's your answer, it's not
> what you wanted so you probably can't use it, so, uh, why are you
> asking me this?".  With a capabilities check, the capability is cached
> by the RA layer and we can avoid asking the question in the first
> place.
>
> I'll add the new capability if there are no objections.

Done http://svn.apache.org/viewvc?view=revision&revision=1141981

> Paul
>
>> - Julian
>>
>>
>>
>
Received on 2011-07-01 18:32:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.