Re: [Patch] RE: Why was svn_client_mergeinfo_get_merged removed?

Bert Huijben wrote:
>> -----Original Message----- From: C. Michael Pilato
>> [mailto:cmpilato_at_collab.net] Sent: maandag 7 april 2008 16:38 To: Bert
>> Huijben Cc: dev_at_subversion.tigris.org Subject: Re: [Patch] RE: Why was
>> svn_client_mergeinfo_get_merged removed?
>>
>> Bert Huijben wrote:
>>> Here is a patch that reintroduces the
>> svn_client_mergeinfo_get_merged() and
>>> svn_client_mergeinfo_get_eligible() (former
>>> svn_client_mergeinfo_get_available()) API's.
>> I'm not interested in carrying forward a naive implementation of
>> get_eligible(). Most of the use-cases for that functionality that I'm
>> aware of are either a) pointless if not paired with additional info
>> (like 'svn log' output) or b) answerable using the get_merged() API.
>
> The log output is a very slow api when using over webdav. I know of at
> least one current common subversion client (TortoiseSVN) which caches svn
> log results to speed up the processing; and I expect AnkhSVN will do the
> same in a future version.

Yeah, yeah, I get that. I'm only talking about the get_eligible() API,
though. I'm fine with re-adding the get_merged() one.

> One of the problems is: A full log of *all revisions* between the first
> and last available revision are retrieved. For webdav this tells me that
> mod_dav_svn first logs all log messages in server ram before transferring
> the first to the webdav client. And then the client ignores most of the
> results.

Sure, I could have done repeated log requests for each range in the
rangelist, paying careful attention to renames in the history of the merge
source/target (whichever is being crawled), and so one. Are 300 full
network turnarounds going to be cheaper than a single request with largish
response? That depends largely on things Subversion can't know.

Fortunately these aren't matters of interest to the design of the API, and
be addressed incrementally as performance enhancements in 1.5.1 or later.

>> Is that true? Looking at the code for this function, there are two
>> places where the list of returned values is appended to. Both cases
>> are appending the result of a path-join with the repository root URL
>> and a repos- relative path. Did some bug suddenly appear there?
>
> It seems to only have slipped in the 1.5.x branch... (The last lines of
> mergeinfo.c are different in appending a url prefix)

Uh ... sorry, not seeing it. http://pastebin.ca/975439

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand