subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: [vote] pin-externals branch to trunk
Date Wed, 28 Jan 2015 14:41:32 GMT
On Wed, Jan 28, 2015 at 11:39:18AM +0100, Bert Huijben wrote:
> 
> 
> > -----Original Message-----
> > From: Branko ─îibej [mailto:brane@wandisco.com]
> > Sent: woensdag 28 januari 2015 11:11
> > To: dev@subversion.apache.org
> > Subject: Re: [vote] pin-externals branch to trunk
> > 
> > On 28.01.2015 10:54, Stefan Sperling wrote:
> > > There is a known problem where relative URLs in the externals definition
> > > may become absolute when pinned. This happens if the URL of an external
> > > resolves to a different path at its last-changed revision. For instance,
> > > an external definition at r600 might look like this:
> > >   ^/moo/bar ext_bar
> > > If the last-changed revision of /moo/bar resolves to r500, and 'moo'
> > > was renamed from 'foo' between r500 and r600, then the pinned external
> > > will use an absolute URL in the current implementation:
> > >   http://svn.example.com/svn/repos/foo/bar@500 ext_bar
> > > This problem could probably be solved by adding additional APIs which
> > > resolve the URL http://svn.example.com/svn/repos/foo/bar to a particular
> > > type of relative URL (such as ^/foo/bar, /svn/repos/foo/bar, ../foo/bar,
> > > //svn.example.com/svn/repos/foo/bar, or ^/../repos/foo/bar). Additionally,
> > > APIs which provide information about the type of a given relative external
> > > URL would be neded. Currently, our APIs don't offer such functionality.
> > 
> > Ouch. This shouldn't stop the merge, but I really think we can't release
> > with this restriction. A major problem here is that the generated
> > absolute URL depends on the access method being used for the copy, or
> > the one used during checkout for a WC->WC copy. Depending on server
> > configuration, this could easily make the resulting copy (tag) unusable;
> > consider a configuration where everyone has read-only access to http://
> > but read/write access through https:// always requires authentication.
> > Read-only users would not be able to export or check out from the tag.
> > 
> > More review later ...
> 
> (Also asked on IRC)
> Why does this branch go through all the trouble of pinning the 'last changed revision'
of all URLs to be pinned
> 
> I would say that pinning, should pin exactly how a current checkout behaves. Now it goes
find older urls of things, etc.
> 
> E.g.
> I have a working copy with an external pointing to ^/subversion/tags/1.8.11/subversion/
libsvn_fs_util
> 
> If I would now call this new pin operation I would get an external pointing to ^/subversion/trunk/subversion/libsvn_fs_util@1460176
> (as nothing on this directory was changed during 1.8.x, and this is the url where it
last changed)
> 
> While I would really expect an external pointing to something like ^/subversion/tags/1.8.11/subversion/libsvn_fs_util@1655064
(assuming r1655064 is HEAD at the time of pinning)
> 
> 
> Somebody reviewing this, would probably note that I should stick to using released code,
instead of using 'trunk' code...

Both concerns should be addressed as of r1655324. Thanks!

Mime
View raw message