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

RE: 1.6 Release blockers

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 05 Feb 2009 11:35:55 +0000

Bert Huijben wrote:
> > From: Mark Phippard [mailto:markphip_at_gmail.com]
> >
> > Is this still a blocker?
> >
> > * Review the new "svn_dirent/svn_uri" API and ensure we aren't putting
> > functions into the public name space that we won't want to support.
> > See
> > <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessage
> > Id=1010183>.
> >
> > If so, then what exactly needs to be done, who has signed up for it,
> > and when is it expected to be done? I think I saw someone attach
> > Bert's name to this a while back, but in my experience with Bert if he
> > was looking at this, it'd be done now. So was it just not removed?
> The TODO is pretty unclear in what /has to be/ done, and what /must be/
> done.
> I reviewed the public API to make sure it has pool parameters where needed
> and added a few missing methods that were required to make it possible to
> deprecate big parts of the svn_path_* api.
> The current status of the dirent API is that it allows much better
> normalization of URIs then the old path, and really separates the code paths
> of local directories and of uris/repository paths.
> E.g. http://SERVER/repos/ is the same as http://server/repos/ in 1.6, where
> in 1.5 they were seen as different (The server name is now always normalized
> to lowercase).
> This will resolve a lot of usability issues where users are trying to
> merge/switch old locations.
> (I did a lot of testing on this normalization as SharpSvn already did some
> of this normalization by using the .Net Uri class.. and this bit us a few
> times in specific user cases; but 1.6 will resolve this nicely.).
> Generally it really improves the 1.5 behavior and allows future
> improvements.
> The new API allows improving the local path code in future releases without
> breaking the new defined api, but it currently handles not much more than
> the old API did.
> I don't think its current status should block the 1.6 release. (That's why I
> didn't continue working on it)

Thanks for the info. I added that TODO item to reflect the concerns that
Lieven expressed in the linked email thread. I'm happy for you to remove
it if you feel the concerns are sufficiently addressed, and it sounds
like you do.

- Julian

Received on 2009-02-05 12:36:21 CET

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.