[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 07 Apr 2008 10:10:16 -0400

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.

> b) Likely bug in the new API. It appears that the new API only works
> when TARGET is a WC. The old API also supported a URL. We had to
> change the JavaHL tests because of this. At the time, I thought this
> was OK, but now realize it is probably a bug. If nothing else, the
> error message has to be better.


> Mike Pilato, can you look at these?


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

Received on 2008-04-07 16:10:30 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.