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

[Boe, Aasmund]

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: 'us...@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).

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'




Best regards,
Aasmund B. Boe

[Philip Martin]

"Boe, Aasmund" <a....@ti.com> writes:

> 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).
>
> 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'

W160016 is the server-side error SVN_ERR_FS_NOT_DIRECTORY so it looks as
if the server might be the problem. I don't have a 1.1.4 server to try.
If you provide a complete reproduction recipe it would allow you to try
a newer server and allow other people to try as well.

--
Philip

[Johan Corveleyn]

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: 'us...@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

[Boe, Aasmund]

> W160016 is the server-side error SVN_ERR_FS_NOT_DIRECTORY so it looks as
> if the server might be the problem. I don't have a 1.1.4 server to try.
> If you provide a complete reproduction recipe it would allow you to try
> a newer server and allow other people to try as well.
>
> --
> Philip

I will see if I can reproduce the problem with a newer server version.
It seems to me that the 1.7.x client does something that the 1.6.x does not - since updating svn:externals works just fine using a 1.6.x client ..?

--
Åsmund

Texas Instruments Norway AS, Gaustadalléen 21, NO-0349 Oslo, Norway. Org. NO 980499480 MVA

-----Original Message-----

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, Aug 28, 2012 at 11:56:44 +0200:
> 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

A 1.5 _client_ is required for the new externals format. It
will work with any server version.

[Boe, Aasmund]

I tested with the following setup:
Server: VisualSVN Server 2.5.6 (Apache subversion 1.7.6)
Client: TortoiseSVN 1.7.8
TortoiseSvn 1.6.x
Using this setup I did not get error W160016 with either client versions.

I am still puzzled about the fact that single file svn:externals works just fine if I have a 1.16.x client (+ old 1.1.4 server), while it produces an error if I update the client to 1.7.x. To me this means that the 1.7.x client communicates differently to the svn server than the 1.6.x client.

It is difficult for me to update the server, so in the meantime (waiting for IT ...), I'm looking for a quick fix. Can someone tell me if there may be a svn server (or client) configuration option that may alter the server response?

Any response is highly appreciated!

[Philip Martin]

"Boe, Aasmund" <a....@ti.com> writes:

> I tested with the following setup:
> Server: VisualSVN Server 2.5.6 (Apache subversion 1.7.6)
> Client: TortoiseSVN 1.7.8
> TortoiseSvn 1.6.x
> Using this setup I did not get error W160016 with either client versions.
>
> I am still puzzled about the fact that single file svn:externals works just fine if I have a 1.16.x client (+ old 1.1.4 server), while it produces an error if I update the client to 1.7.x. To me this means that the 1.7.x client communicates differently to the svn server than the 1.6.x client.
>
> It is difficult for me to update the server, so in the meantime (waiting for IT ...), I'm looking for a quick fix. Can someone tell me if there may be a svn server (or client) configuration option that may alter the server response?
>
> Any response is highly appreciated!

I've reproduced the problem with a 1.0.9 server and raised an issue:

http://subversion.tigris.org/issues/show_bug.cgi?id=4224


--
Philip