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 ... -- Brane
