Externals Bug with 1.6

[Adam Seyer]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Our users are experiencing a problem with TortoiseSVN 1.6.  When a directory with an external pointing into a nested subfolder is updated, the external download removes the “\”.

 

Reproduction steps:

 

Create an external in application “B” pointing to sub item A.

 

The trunk has an svn:external :

 

ExternalPackages\ProjectA http://svn/applications/ProjectA/tags/releases/3_4_5_0259/Release

 

Expected behavior:

A folder ExternalPackages with a subfolder of ProjectA will contain the contents of the URL (.\ExternalPackages\ProjectA)

 

Actual behavior:

A folder called ExternalPackagesProjectA contains the contents of the URL. (.\ExternalPackagesProjectA)

 

TortoiseSVN version: 1.6.0 15855 (Both Vista 32-bit and Windows XP 32-bit exhibited behavior, unsure of 64-bit)

Server SVN Version: version 1.5.5 (r34862).

 

Thank you.

 

Adam Seyer

 

[Bob Archer]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Have you tried using a forward slash in your external definition instead?

 

ExternalPackages/ProjectA http://svn/applications/ProjectA/tags/releases/3_4_5_0259/Release

 

 

BOb

 

 

---

From: Adam Seyer [mailto:adam.seyer@...]
Sent: Friday, March 27, 2009 11:14 AM
To: [e-mail]
Subject: Externals Bug with 1.6

 

Our users are experiencing a problem with TortoiseSVN 1.6.  When a directory with an external pointing into a nested subfolder is updated, the external download removes the “\”.

 

Reproduction steps:

 

Create an external in application “B” pointing to sub item A.

 

The trunk has an svn:external :

 

ExternalPackages\ProjectA http://svn/applications/ProjectA/tags/releases/3_4_5_0259/Release

 

Expected behavior:

A folder ExternalPackages with a subfolder of ProjectA will contain the contents of the URL (.\ExternalPackages\ProjectA)

 

Actual behavior:

A folder called ExternalPackagesProjectA contains the contents of the URL. (.\ExternalPackagesProjectA)

 

TortoiseSVN version: 1.6.0 15855 (Both Vista 32-bit and Windows XP 32-bit exhibited behavior, unsure of 64-bit)

Server SVN Version: version 1.5.5 (r34862).

 

Thank you.

 

Adam Seyer

 

[Kurt Pruenner]

Adam Seyer wrote:
> Our users are experiencing a problem with TortoiseSVN 1.6.  When a
> directory with an external pointing into a nested subfolder is updated,
> the external download removes the "\"

I'm pretty sure the "\" is illegal here; according to the subversion
documentation you need to use "/" as the directory separator - see the
first example here:

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
np: Adolf Noise - Afrika (Wo Die Rammelwolle Fliegt)

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1445376

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Konstantin Kolinko]

2009/3/27 Adam Seyer <adam.seyer@...>:
> Our users are experiencing a problem with TortoiseSVN 1.6.  When a directory
> with an external pointing into a nested subfolder is updated, the external
> download removes the “\”.
>

AFAIK, you need to use the forward slash. The backslash has changed its
meaning there in 1.6.

See the section entitled "Support usual shell quoting rules in
externals definitions"
in the Release Notes 1.6:
http://subversion.tigris.org/svn_1.6_releasenotes.html

The good part is that you can now have spaces coded as '\ ' in the local path of
an external.

Best regards,
Konstantin Kolinko

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1445849

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Simon Large-5]

2009/3/27 Konstantin Kolinko <knst.kolinko@...>:

> 2009/3/27 Adam Seyer <adam.seyer@...>:
>> Our users are experiencing a problem with TortoiseSVN 1.6.  When a directory
>> with an external pointing into a nested subfolder is updated, the external
>> download removes the “\”.
>>
>
> AFAIK, you need to use the forward slash. The backslash has changed its
> meaning there in 1.6.
>
> See the section entitled "Support usual shell quoting rules in
> externals definitions"
> in the Release Notes 1.6:
> http://subversion.tigris.org/svn_1.6_releasenotes.html
>
> The good part is that you can now have spaces coded as '\ ' in the local path of
> an external.

Thanks for the info Konstantin. Docs updated and backported to 1.6.x
in r15980 and following.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1461874

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Anton V. Kravtsov]

Hi all,

The advice to replace backslashes '\' with forward slashes '/' for "nested externals" is fine for on-going developments, but our repository has hundreds of Tags using backslashes for "nested externals", like:

Source -r 12345 https://svn.xxx.xxx/Repo/Source
Source\SubProj -r 12345 https://svn.xxx.xxx/ExtraRepo/SubProj

And now they are all broken. It is a disaster! :(

I propose to allow usage of backslashes '\' for old-formatted externals (dir url).
It is a matter of backward compatibility.
And it surprised me much that such compatibility wasn't preserved :(

Is it possible to fix this behavior in the nearest future version of TortoiseSVN?
I didn't check the behavior in 1.6.6, but in 1.6.5 and 1.6.4 the compatibility is broken.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2412639

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Andy Levy]

On Thu, Oct 29, 2009 at 09:48, Anton V. Kravtsov <ka5@...> wrote:

> Hi all,
>
> The advice to replace backslashes '\' with forward slashes '/' for "nested externals" is fine for on-going developments, but our repository has hundreds of Tags using backslashes for "nested externals", like:
>
> Source -r 12345 https://svn.xxx.xxx/Repo/Source
> Source\SubProj -r 12345 https://svn.xxx.xxx/ExtraRepo/SubProj
>
> And now they are all broken. It is a disaster! :(
>
> I propose to allow usage of backslashes '\' for old-formatted externals (dir url).
> It is a matter of backward compatibility.
> And it surprised me much that such compatibility wasn't preserved :(
>
> Is it possible to fix this behavior in the nearest future version of TortoiseSVN?
> I didn't check the behavior in 1.6.6, but in 1.6.5 and 1.6.4 the compatibility is broken.

I'm pretty sure you'll have to lobby for this on the Subversion
mailing list; externals are handled by the Subversion library.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2412647

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Bob Archer]

> The advice to replace backslashes '\' with forward slashes '/' for
> "nested externals" is fine for on-going developments, but our
> repository has hundreds of Tags using backslashes for "nested
> externals", like:
>
> Source -r 12345 https://svn.xxx.xxx/Repo/Source
> Source\SubProj -r 12345 https://svn.xxx.xxx/ExtraRepo/SubProj
>
> And now they are all broken. It is a disaster! :(
>
> I propose to allow usage of backslashes '\' for old-formatted externals
> (dir url).
> It is a matter of backward compatibility.
> And it surprised me much that such compatibility wasn't preserved :(
>
> Is it possible to fix this behavior in the nearest future version of
> TortoiseSVN?
> I didn't check the behavior in 1.6.6, but in 1.6.5 and 1.6.4 the
> compatibility is broken.

I'm not quite sure how this would work. How is svn supposed to know what version you were running when your external was created.

I think on the svn list someone had writting a script to go through all the externals and modify the backslashes to wacks.

BOb

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2412656

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Anton V. Kravtsov-2]

> I'm not quite sure how this would work. How is svn supposed to know what version you were running when your external was created.

I suppose, the format of an external is known at the moment of a checkout: it is either old-fashioned "path url", or new-fashioned "url path".
If it is old-fashioned, just treat a backslash as a directories separator.
I don't know the internals of svn, but it should be simple in the implementation :)

> I think on the svn list someone had writting a script to go through all the externals and modify the backslashes to wacks.

Yes, the script would help.
I hope, we don't have old repositories with read-only access :)

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2412665

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Urs-5]

On 29 Okt., 15:33, "Anton V. Kravtsov" <k...@...> wrote:

> > I'm not quite sure how this would work. How is svn supposed to know what version you were running when yourexternalwas created.
>
> I suppose, the format of anexternalis known at the moment of a checkout: it is either old-fashioned "path url", or new-fashioned "url path".
> If it is old-fashioned, just treat abackslashas a directories separator.
> I don't know the internals of svn, but it should be simple in the implementation :)
>
> > I think on the svn list someone had writting a script to go through all the externals and modify the backslashes to wacks.
>
> Yes, the script would help.
> I hope, we don't have old repositories with read-only access :)

A script is not the solution for this problem. The backward
compatibility is not solved with this script. Eeach old revision is
not buildable and a big problem.

>
> ------------------------------------------------------http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr...@...].

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2415761

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Simon Large-5]

2009/11/9 Urs <urs.geser@...>:

> On 29 Okt., 15:33, "Anton V. Kravtsov" <k...@...> wrote:
>> > I'm not quite sure how this would work. How is svn supposed to know what version you were running when yourexternalwas created.
>>
>> I suppose, the format of anexternalis known at the moment of a checkout: it is either old-fashioned "path url", or new-fashioned "url path".
>> If it is old-fashioned, just treat abackslashas a directories separator.
>> I don't know the internals of svn, but it should be simple in the implementation :)
>>
>> > I think on the svn list someone had writting a script to go through all the externals and modify the backslashes to wacks.
>>
>> Yes, the script would help.
>> I hope, we don't have old repositories with read-only access :)
>
> A script is not the solution for this problem. The backward
> compatibility is not solved with this script. Eeach old revision is
> not buildable and a big problem.

The problem is that externals are handled within the subversion
library so there is nothing we can do. You need to ask on the
subversion users mailing list.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2415779

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].