Re: svn 1.7 client issues error on update of single file externals

On Tue, Aug 28, 2012 at 8:17 AM, Boe, Aasmund <a.boe_at_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_at_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