On Tue, Aug 28, 2012 at 8:17 AM, Boe, Aasmund <a....@ti.com> wrote: > Bump. Has anyone observed the below issue, where subversion 1.7.x client > issues an error when using 'svn update' on folders containing single file > svn:externals? Note that subversion does indeed update the externals, it > marely issues an error. > > Any response is appreciated! > > Best regards, > Åsmund B. BØ > > > Texas Instruments Norway AS, Gaustadalléen 21, NO-0349 Oslo, Norway. Org. NO > 980499480 MVA > > -----Original Message----- > From: Boe, Aasmund > Sent: 24. juli 2012 08:53 > To: 'users@subversion.apache.org' > Subject: svn 1.7 client issues error on update of single file externals > > Using subversion 1.7(.5), updating a working copy that has single file > svn:externals results in an error, even if the update does indeed work. > Bug, or am I doing something wrong? > > Details posted on stackoverflow.com (before I was aware of this mailing list): > http://stackoverflow.com/questions/11615043/subversion-client-1-7-file-externals-update-error > > And the content of the above url: > I have come across an error using svn update on a working copy folder with > single file svn:externals. I wonder if there is a work-around for this, if I > am doing something wrong, or if this is a bug in the client 1.7.x of > subversion. > > The error occurs when calling svn update using subversion 1.7.5 (tried > TortoiseSvn 1.7.7 and slikSvn 1.7.5) on a folder that has single file > svn:externals. I'm tempted to say it's a bug in the subversion client, > because the update does indeed occur, but it says it fails. > > For reference, the server side uses a very old version (1.1.4 [r13838]), but > from what I know externals is a client "feature" so an old server should not > be a problem. Besides, this workes well using subversion 1.6.x (client).
Hm, you should really upgrade your server. Anything < 1.6 is not supported anymore (but of course people on this list will still try to help). I have no idea whether the server version is related to the problem, but it might be. It might be best if you can reproduce the issue with a more recent server. > This is the scenario I observe: > > 1. Checkout a project (that has single file svn:externals) > svn checkout http://my/repo/projects/proj1 proj1 > > 2. Browsing to the folder in my working copy with single file svn:externals. > E.g. > myFile.txt http://my/repo/components/comp1/myFile.txt > > 3. Executing svn update and I get the following output: > Fetching external item into 'trunk\proj1\source\myFile.txt': > : warning: W160016: Failure opening > '/components/comp1/myFile.txt/myFile.txt' > > If change the svn:externals so that the local file has a different name, like > below: > my_file.txt http://my/repo/components/comp1/myFile.txt > > Then the error message in 3. becomes as below, so the the file after the last > forward slash ('/') is the local version of the file. > > Fetching external item into 'trunk\proj1\source\myFile.txt': > : warning: W160016: Failure opening > '/components/comp1/myFile.txt/my_file.txt' Strange indeed. An important thing to know is that a externals syntax was introduced in 1.5 (but the old format should still work). The old format is (line format inside the multiline svn:externals property): local_relative_path [-rREV] external_url The new format is: [-rREV] external_url[@PEGREV] local_relative_path In the new format the external_url can be a relative url (in the old format only fully qualified urls without peg revision are accepted). See [1] for more details and examples. Since there is some kind of mixup between the local relative path and the external url, it seems that there is some problem with the interpretation between the old and the new syntax by the client, or something like that. Important to know: ../, ^/, // and / are used to start a relative url (see [1]), so if your local_relative_path starts with those, it would be interpreted as a url by the client, and it would parse everything with the new syntax. Could you show us the exact svn:externals property (maybe redacted to hide urls and such, but preferably as close as possible to the original)? Or it would be even better if you could reproduce the issue with a self-contained recipe, starting with 'svnadmin create testrepo', and checking out a working copy with 'svn checkout file:///path/to/testrepo'. [1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html -- Johan
