On Wed, Jan 28, 2015 at 11:39:18AM +0100, Bert Huijben wrote: > > > > -----Original Message----- > > From: Branko Čibej [mailto:br...@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!
