Re: Subversion 1.5 issues blocking RC1

Mark Phippard wrote:
> On Mon, Apr 7, 2008 at 10:10 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Mark Phippard wrote:
>>
>>> I thought it would be useful to start a new thread where we can gather
>>> a sort of to-do list of things we need to look at before we can make
>>> the RC1. We did a lot of work yesterday to get close to the release,
>>> but there are still some things left to do.
>>>
>>> 1) Clean out STATUS. Hyrum pointed this out. Basically, there were a
>>> couple of items discovered yesterday that got fixed late and added to
>>> STATUS. Getting them approved for backport should be trivial but
>>> still needs to be done.
>>>
>>> 2) Mergeinfo API.
>>>
>>> a) As Bert and Stefan have pointed out, the new API can be pretty
>>> slow. The new API is good, they just have a valid case for leaving
>>> the "old" API in place rather than remove it. I have to say we had a
>>> few instances in the JavaHL tests where it the old API was more
>>> appropriate. For example, sometimes you just want to check that there
>>> is mergeinfo, you do not care so much about the details. The log
>>> based approach is too heavy for this.
>>>
>> I'm fine with re-adding a completely naive svn_client_get_mergeinfo() (so
>> named for closer parity with the RA API), but I oppose re-adding the
>> "eligible" version of this API.
>
> That is fine with me. I cannot speak for Stefan or Bert. I think the
> main place where the performance hit becomes ugly is in getting the
> already merged revisions.

I only need svn_client_get_mergeinfo(), I haven't used the other APIs.
The reasons I need this API:

For the log dialog, I'd like to mark already merged revisions. To do
that, we first fetch the log (which we might already have in our cache),
then we call svn_client_get_mergeinfo(), go through the returned hash
and then mark the merged revisions.

The APIs currently available are not really suited for this, because
they both fetch the log too (svn_client_mergeinfo_log_eligible and
svn_client_mergeinfo_log_merged). If there was an API which would
combine those two, that would be a start - I need *all* log entries and
mark those which have already been merged, not just either the merged or
not-merged ones.
But since we can cache the log info in TSVN now, I'd rather have the
svn_client_get_mergeinfo() API back...

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net