You open an ra session to one canonical url and then get a session to another one.
At that point you can't trust the relative path apis, nor reparent the session to something using based on the other url. This breaks checkout, diff, or even simple ‘svn ls’ to these url forms. The biggest problem is that one of the sources is libsvn_wc, which we can’t just change.. But that is one of the sources. Most other sources already canonicalize using svn_uri_canonicalize(). Also note that the applying the ‘localhost’ rule I mentioned as one of the examples already got a -1 in a recent mail for applying in the generic uri canonicalize code. Mark Phippard and at least one other user reported this regression on dev@s.a.o recently. The proposed change is reverting a 1.8 behavior change with unwanted side effects. Not relaxing a rule. Making it strict will take quite some work; which as I mentioned includes a wc.db format bump. But this also includes option parsing changes and applying more canonicalizations than standardized. Bert Sent from Windows Mail From: Daniel Shahaf Sent: Sunday, May 26, 2013 9:25 PM To: Bert Huijben Cc: dev@subversion.apache.org Bert Huijben wrote on Sun, May 26, 2013 at 20:51:10 +0200: > > > > -----Original Message----- > > From: danie...@apache.org [mailto:danie...@apache.org] > > Sent: zondag 26 mei 2013 08:49 > > To: comm...@subversion.apache.org > > Subject: svn commit: r1486397 - /subversion/branches/1.8.x/STATUS > > > > Author: danielsh > > Date: Sun May 26 06:48:49 2013 > > New Revision: 1486397 > > > > URL: http://svn.apache.org/r1486397 > > Log: > > * STATUS: Ask a question about r1485127. > > > > Modified: > > subversion/branches/1.8.x/STATUS > > > > Modified: subversion/branches/1.8.x/STATUS > > URL: > > http://svn.apache.org/viewvc/subversion/branches/1.8.x/STATUS?rev=1486 > > 397&r1=1486396&r2=1486397&view=diff > > ========================================================== > > ==================== > > --- subversion/branches/1.8.x/STATUS (original) > > +++ subversion/branches/1.8.x/STATUS Sun May 26 06:48:49 2013 > > @@ -104,6 +104,10 @@ Candidate changes: > > Restores functionality that was lost in 1.8 compared to 1.7. > > Votes: > > +1: rhuijben (for 1.8.1 or soak restart) > > + +0: danielsh (looks right, but all this does is cause sess->repos_url > > + to be set to a non-canonical value; I wonder if the > > right > > + fix is to add a canonicalize() call in front of a > > strcmp() > > + in libsvn_client) > > I wish it were that simple. > > The usage of file://localhost/some/location to a repository on > /some/location has been hardcoded in ra_local since before 1.0, but is > not part of our canonicalization rules in svn_uri_canonicalize(). > > The 'simple fix' to change the canonicalization rules by including > this rule would require a working copy format bump, as this prefix is > currently perfectly valid as a repository location. What is the libsvn_wc problem that setting svn_ra_session_t.repos_root_url to a different value fixes? (You haven't said that yet either in the log message or in this thread; you only said what URLs are involved in it.) It is still not clear to me why we are fixing a libsvn_wc issue by changing an implementation detail of libsvn_ra_local. It sounds like libsvn_wc could invent its own notion of "equal URL" which ignores drives letters and considers file:/// and file://localhost/ equivalent, with no changes to libsvn_ra*. With the new code, will svn_ra_session_t->repos_root_url always be set to a canonical value? The code before your change would. Thanks for the additional background. Daniel > And then for this > example the api works for us, but is not really part of any RFC. > > That 'localhost' refers to the local machine is a convention on many > platforms, but not really a standard. > > On Windows we also have file:///some/path urls that refers to > E:\some\path when E: happens to be the current harddrive. And this has > similar conversion problems. > > > I think that for 1.8 we have to keep the same one to many relation > between local dirents and repository urls, as in 1.0-1.7 :( > > For 1.9+ we might be able to apply new canonicalization rules via > a proper upgrade, but doing this now would just delay 1.8, at no real > gain for our users. > > Bert > > > > > > > > * r1485447, r1485449 > > Make 'SQLITE_VERSION=3.7.15.1 ./get-deps.sh' work. > > > >
