You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2011/12/15 15:31:02 UTC
Re: svn commit: r1214677 - in /subversion/trunk/subversion: libsvn_client/client.h
libsvn_client/merge.c libsvn_client/ra.c libsvn_client/switch.c tests/libsvn_client/client-test.c
On 12/15/2011 04:53 AM, julianfoad@apache.org wrote:
> Author: julianfoad
> Date: Thu Dec 15 09:53:59 2011
> New Revision: 1214677
>
> URL: http://svn.apache.org/viewvc?rev=1214677&view=rev
> Log:
> Teach svn_client__get_youngest_common_ancestor() to output the ancestor as a
> URL as well as a relpath, because some existing callers want that and it
> will also simplify writing a higher level version of this API which I intend
> to do next.
May I suggest that if you plan to publicize this functionality, you let the
server do this YCA calculation with a new RA function, only falling back to
the client-side calculation when communicating with older servers?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1214677 - in /subversion/trunk/subversion: libsvn_client/client.h libsvn_client/merge.c libsvn_client/ra.c libsvn_client/switch.c tests/libsvn_client/client-test.c
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> On 12/15/2011 04:53 AM, julianfoad@apache.org wrote:
>> Teach svn_client__get_youngest_common_ancestor() to output the ancestor as
>> a URL as well as a relpath, because some existing callers want that and it
>> will also simplify writing a higher level version of this API which I
>> intend to do next.
>
> May I suggest that if you plan to publicize this functionality, you let the
> server do this YCA calculation with a new RA function, only falling back to
> the client-side calculation when communicating with older servers?
That sounds like a good optimization to make if and when we find this operation becoming frequently used and inefficient. I'm certainly not opposed to it but at the moment it doesn't appear to be either very frequent (assuming once or twice or so per merge is OK) or too inefficient.
While I'm first putting an extra call to it in the 'svn' client, the same code path goes on to call one of the libsvn_client merge functions and those also call get_youngest_common_ancestor in some cases, so by refactoring I may be able to eliminate the duplication.
- Julian