1.6 Release blockers

[Mark Phippard <ma...@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&dsMessageId=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?

Are there any blockers not in the file?  Maybe the problem Paul
reported earlier from his tree conflicts work?

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1102813

I ask because the two tree conflicts blockers seem like they are
closer to the finish line.  So I am wondering what else there is
blocking us when these are finalized.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103933

RE: 1.6 Release blockers

[Julian Foad <ju...@btopenworld.com>]

Bert Huijben wrote:
> > From: Mark Phippard [mailto:markphip@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

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1107055

RE: 1.6 Release blockers

[Bert Huijben <rh...@sharpsvn.net>]

> -----Original Message-----
> From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: woensdag 4 februari 2009 21:42
> To: dev@subversion.tigris.org
> Subject: 1.6 Release blockers
> 
> 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)


A big TODO is deprecating the old path api, but I don't think we should do
that for 1.6. Replacing svn_path_* through our entire code base (especially
svn_wc_*) will be a lot of work, but will probably also fix a lot of path
parsing corner cases currently unhandled.

Other dirent TODOs (no 1.6 blockers) are:
* implementing and/or verifying some extra Windows specific relative path
handling (c:file  (Relative from C:'s current directory, not just the
current directory).
* Providing some kind of svn_dirent_is_universal() API that doesn't return
true on '/' on Windows like svn_dirent_is_absolute() does now, but does on
'C:/dir/file'

I'm pretty sure the old svn_path api won't be enough to handle all cases for
the centralized working copy area on case insensitive systems like Windows
and Mac, but I think the dirent api can be extended to cover that.

I see a lot of possible compatibility problems for the administrative area
completely outside the working copy on case insensitive file systems. But
we'll see when we get there. 
(Just moving everything up to the working copy root won't alter the behavior
of the directory levels above the working copy and will be the default
behavior anyway)

	Bert

> Are there any blockers not in the file?  Maybe the problem Paul
> reported earlier from his tree conflicts work?
> 
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1102813
> 
> I ask because the two tree conflicts blockers seem like they are
> closer to the finish line.  So I am wondering what else there is
> blocking us when these are finalized.
> 
> --
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/
> 
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=1103933

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1106748