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

Re: Subversion 1.5 issues blocking RC1

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 7 Apr 2008 10:46:48 -0400

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-07 16:47:02 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.