You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Hutchinson, Steve (UK)" <st...@mbda-systems.com> on 2013/05/01 13:01:32 UTC
SVN Externals 1.6 to 1.7 migration issue
Hi,
We're been using 1.6 svn externals to manage a FW task.
In the repository we have a folder structure (which is pretty much defined by the tools we are using) as below :-
FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
Then using externals we link to those folder to create a WC PROJECT structure that looks like :-
PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND file_b1.txt
PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
The externals on PROJECT FOLDER we used looked like (not actually using file protocol, just created for example purposes) :-
file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
Worked ok with 1.6. We get the below error in 1.7 when updating of :-
External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
Error: Cannot insert a file external defined on 'D:\FPGA\SVN_ISSUE\PROJECT' into the
Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
We have tried a few things (will not share all at this point due to info overload), but wondered if there were any others that achieve something like this with 1.7 or could offer some advise ?
Thanks for any help.
Regards
Steve H
********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
********************************************************************
Re: SVN Externals 1.6 to 1.7 migration issue
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 2, 2013 at 12:50 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Wed, May 1, 2013 at 5:01 PM, BRM <bm...@yahoo.com> wrote:
>>>> While I have not had the issue you are having, assuming the externals are in
>>>> the same repository I would highly recommend changing from using the syntax
>>>> you have to using the carrot (^) operator as it will save you many headaches
>>>> if your original svn location changes.
>>>>
>>>> I.e. use:
>>>>
>>>> ^/FOLDER_A FOLDER_C
>>>> ^/FOLDER_B FOLDER_D
>>>
>>> Indeed, that's far better than using an absolute url with scheme etc.
>>>
>>>> Also, I think the specific issue you are having (looking more closely at the
>>>> error message below) is that AFAIK, SVN does not let you import specific
>>>> files via externals - you have to do name spaces (aka folders) instead.
>>>
>>> That's not correct. File externals are supported (since 1.6 I think).
>>> They have a couple of specific problems though (a lot of which have
>>> been fixed in 1.7), because their implementation is entirely different
>>> from directory externals (file externals use the "switch" mechanism
>>> underneath, while dir externals are essentially an embedded checkout
>>> with some sugar on top).
>>>
>>> So, concerning to the problem of the OP:
>>>
>>>> From: "Hutchinson, Steve (UK)" <st...@mbda-systems.com>
>>>> To: "users@subversion.apache.org" <us...@subversion.apache.org>
>>>> Sent: Wednesday, May 1, 2013 7:01 AM
>>>> Subject: SVN Externals 1.6 to 1.7 migration issue
>>>>
>>>> Hi,
>>>>
>>>> We're been using 1.6 svn externals to manage a FW task.
>>>>
>>>> In the repository we have a folder structure (which is pretty much defined
>>>> by the tools we are using) as below :-
>>>>
>>>> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>>>> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>>>>
>>>> Then using externals we link to those folder to create a WC PROJECT
>>>> structure that looks like :-
>>>>
>>>> PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND
>>>> file_b1.txt
>>>> PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
>>>>
>>>> The externals on PROJECT FOLDER we used looked like (not actually using file
>>>> protocol, just created for example purposes) :-
>>>>
>>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>>>>
>>>> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>>>>
>>>> External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>>>> Error: Cannot insert a file external defined on
>>>> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>>>> Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>>>>
>>>> We have tried a few things (will not share all at this point due to info
>>>> overload), but wondered if there were any others that achieve something like
>>>> this with 1.7 or could offer some advise ?
>>>
>>> So essentially you are "injecting" a file external (file_b1.txt)
>>> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>>>
>>> Hm, I remember some past discussions about edge cases like these
>>> (during the working copy rewrite of 1.7), but I don't remember exactly
>>> if this is actually a supported use case, or if it just happened to
>>> work by accident in 1.6.
>>>
>>> Perhaps someone else on this list can shed some light on this?
>>
>> I had the following conversation with Philip Martin, on IRC (#svn-dev):
>>
>> <@jcorvel> philipm, perhaps you know the answer to this externals
>> question (works in 1.6, but no longer in 1.7):
>> http://svn.haxx.se/users/archive-2013-05/0006.shtml
>> <philipm> A file external defined in one working copy but located
>> inside another working copy is not going to work in 1.7 or 1.8.
>> <philipm> The directory external is a separate working copy with its
>> own .svn/wc.db and that knows nothing about the external defined in a
>> different .svn/wc.db
>> <@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
>> 1.6, but was never supposed to be supported" category? Or could this
>> be considered a regression?
>> <@jcorvel> I guess it doesn't matter ... semantics ...
>> <philipm> I don't suppose we ever supported it deliberately.
>> <@jcorvel> perhaps the more interesting question then is: is this at
>> all supportable within the externals design (of wc-ng)? Or would this
>> require "externals 2.0"?
>> <philipm> If we change directory externals to be more like switch then
>> the directory externals become part of a single working copy.
>> <@jcorvel> ack
>> <philipm> It may be relatively simple to do that. At present if you
>> try to "svn sw URL path" and path does not exist then the switch
>> fails.
>> <philipm> But it only fails because of a high level check on path, in
>> the past it was possible to switch a non-existant path.
>> <philipm> (In the past being during 1.7 development)
>> <philipm> If you switch a path that does not exist that looks very
>> much like an external (it is how file externals are implemented)
>> <philipm> One of the difficulties about externals is that the
>> specification is so relaxed that there are so many different cases.
>> <philipm> Almost any change is going to break some untested corner
>> cases, while perhaps fixing other corner cases.
>> <@jcorvel> philipm: so, realistically, this will probably not be fixed
>> very soon (as in: in a 1.8.x release). At the very least, it needs (a
>> lot of) work for coming up with a detailed spec etc ... to try and get
>> a grip on the edge cases etc ...
>> <philipm> I don't think it will be fixed in the near future. I don't
>> know what we are going to do about externals.
>>
>>
>> So I guess that answers it. It's not going to work in the near future.
>> Short term I guess you have to find a workaround by structuring things
>> differently. Longer term, someone needs to "champion" an effort to
>> rework externals (starting by driving a discussion about it's
>> specification etc ...). Volunteers welcome :-).
>>
>
> And some additional context was given by Bert Huijben:
>
> <@Bert> jcorvel: Injecting file externals into a separate working copy
> was deemed to be a never intended feature and a potential security
> problem. It was explicitly disabled during 1.7 development.
> <@Bert> jcorvel: The proper fix is part of the externals redesign to
> something like viewspecs... where the file external just becomes a
> working copy containing one file, but properly defined by some
> ancestor
> <@Bert> A problem with this 'feature' was that it was possible to
> inject such externals, but not to remove them. The working copy that
> contained the external didn't even contain the definition.
>
FWIW, "injecting" externals inside other externals seems to "work" in
1.7 when you do it with "directory externals" (for some definition of
"work" ... I haven't tried all use cases with it). However, I wouldn't
recommend it (it feels pretty wonky to me -- not sure if there aren't
any side effects -- for instance, 'svn status' output looks a bit
strange, see below).
Here is a transcript of a quick experiment with SVN 1.7.7:
[[[
C:\Temp\svntest2>svnadmin create repos
C:\Temp\svntest2>svn co file:///C:/Temp/svntest2/repos wc
Checked out revision 0.
C:\Temp\svntest2>cd wc
C:\Temp\svntest2\wc>svn mkdir dir1 dir2
A dir1
A dir2
C:\Temp\svntest2\wc>svn ci -mm
Adding dir1
Adding dir2
Committed revision 1.
C:\Temp\svntest2\wc>svn up
Updating '.':
At revision 1.
C:\Temp\svntest2\wc>svn pe svn:externals . # edit externals in text editor
Set new value for property 'svn:externals' on '.'
C:\Temp\svntest2\wc>svn pg svn:externals
^/dir1 ext_dir1
^/dir2 ext_dir1/ext_dir2
C:\Temp\svntest2\wc>svn ci -mm
Sending .
Committed revision 2.
C:\Temp\svntest2\wc>svn up
Updating '.':
Fetching external item into 'ext_dir1':
External at revision 2.
Fetching external item into 'ext_dir1\ext_dir2':
External at revision 2.
At revision 2.
C:\Temp\svntest2\wc>svn st
X ext_dir1
Performing status on external item at 'ext_dir1':
? C:\Temp\svntest2\wc\ext_dir1\ext_dir2
Performing status on external item at 'ext_dir1\ext_dir2':
C:\Temp\svntest2\wc>echo test > dir1\file.txt
C:\Temp\svntest2\wc>svn add dir1\file.txt
A dir1\file.txt
C:\Temp\svntest2\wc>svn ci -mm
Adding dir1\file.txt
Transmitting file data .
Committed revision 3.
C:\Temp\svntest2\wc>svn up
Updating '.':
Fetching external item into 'ext_dir1':
A ext_dir1\file.txt
Updated external to revision 3.
Fetching external item into 'ext_dir1\ext_dir2':
External at revision 3.
At revision 3.
C:\Temp\svntest2\wc>echo blah > dir2\file.txt
C:\Temp\svntest2\wc>svn add dir2\file.txt
A dir2\file.txt
C:\Temp\svntest2\wc>svn ci -mm
Adding dir2\file.txt
Transmitting file data .
Committed revision 4.
C:\Temp\svntest2\wc>svn up
Updating '.':
Fetching external item into 'ext_dir1':
External at revision 4.
Fetching external item into 'ext_dir1\ext_dir2':
A ext_dir1\ext_dir2\file.txt
Updated external to revision 4.
At revision 4.
C:\Temp\svntest2\wc>svn st
X ext_dir1
Performing status on external item at 'ext_dir1':
? C:\Temp\svntest2\wc\ext_dir1\ext_dir2
Performing status on external item at 'ext_dir1\ext_dir2':
C:\Temp\svntest2\wc>cat ext_dir1\file.txt
test
C:\Temp\svntest2\wc>cat ext_dir1\ext_dir2\file.txt
blah
]]]
--
Johan
Re: SVN Externals 1.6 to 1.7 migration issue
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 2, 2013 at 11:00 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Wed, May 1, 2013 at 5:01 PM, BRM <bm...@yahoo.com> wrote:
>>> While I have not had the issue you are having, assuming the externals are in
>>> the same repository I would highly recommend changing from using the syntax
>>> you have to using the carrot (^) operator as it will save you many headaches
>>> if your original svn location changes.
>>>
>>> I.e. use:
>>>
>>> ^/FOLDER_A FOLDER_C
>>> ^/FOLDER_B FOLDER_D
>>
>> Indeed, that's far better than using an absolute url with scheme etc.
>>
>>> Also, I think the specific issue you are having (looking more closely at the
>>> error message below) is that AFAIK, SVN does not let you import specific
>>> files via externals - you have to do name spaces (aka folders) instead.
>>
>> That's not correct. File externals are supported (since 1.6 I think).
>> They have a couple of specific problems though (a lot of which have
>> been fixed in 1.7), because their implementation is entirely different
>> from directory externals (file externals use the "switch" mechanism
>> underneath, while dir externals are essentially an embedded checkout
>> with some sugar on top).
>>
>> So, concerning to the problem of the OP:
>>
>>> From: "Hutchinson, Steve (UK)" <st...@mbda-systems.com>
>>> To: "users@subversion.apache.org" <us...@subversion.apache.org>
>>> Sent: Wednesday, May 1, 2013 7:01 AM
>>> Subject: SVN Externals 1.6 to 1.7 migration issue
>>>
>>> Hi,
>>>
>>> We're been using 1.6 svn externals to manage a FW task.
>>>
>>> In the repository we have a folder structure (which is pretty much defined
>>> by the tools we are using) as below :-
>>>
>>> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>>> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>>>
>>> Then using externals we link to those folder to create a WC PROJECT
>>> structure that looks like :-
>>>
>>> PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND
>>> file_b1.txt
>>> PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
>>>
>>> The externals on PROJECT FOLDER we used looked like (not actually using file
>>> protocol, just created for example purposes) :-
>>>
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>>>
>>> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>>>
>>> External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>>> Error: Cannot insert a file external defined on
>>> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>>> Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>>>
>>> We have tried a few things (will not share all at this point due to info
>>> overload), but wondered if there were any others that achieve something like
>>> this with 1.7 or could offer some advise ?
>>
>> So essentially you are "injecting" a file external (file_b1.txt)
>> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>>
>> Hm, I remember some past discussions about edge cases like these
>> (during the working copy rewrite of 1.7), but I don't remember exactly
>> if this is actually a supported use case, or if it just happened to
>> work by accident in 1.6.
>>
>> Perhaps someone else on this list can shed some light on this?
>
> I had the following conversation with Philip Martin, on IRC (#svn-dev):
>
> <@jcorvel> philipm, perhaps you know the answer to this externals
> question (works in 1.6, but no longer in 1.7):
> http://svn.haxx.se/users/archive-2013-05/0006.shtml
> <philipm> A file external defined in one working copy but located
> inside another working copy is not going to work in 1.7 or 1.8.
> <philipm> The directory external is a separate working copy with its
> own .svn/wc.db and that knows nothing about the external defined in a
> different .svn/wc.db
> <@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
> 1.6, but was never supposed to be supported" category? Or could this
> be considered a regression?
> <@jcorvel> I guess it doesn't matter ... semantics ...
> <philipm> I don't suppose we ever supported it deliberately.
> <@jcorvel> perhaps the more interesting question then is: is this at
> all supportable within the externals design (of wc-ng)? Or would this
> require "externals 2.0"?
> <philipm> If we change directory externals to be more like switch then
> the directory externals become part of a single working copy.
> <@jcorvel> ack
> <philipm> It may be relatively simple to do that. At present if you
> try to "svn sw URL path" and path does not exist then the switch
> fails.
> <philipm> But it only fails because of a high level check on path, in
> the past it was possible to switch a non-existant path.
> <philipm> (In the past being during 1.7 development)
> <philipm> If you switch a path that does not exist that looks very
> much like an external (it is how file externals are implemented)
> <philipm> One of the difficulties about externals is that the
> specification is so relaxed that there are so many different cases.
> <philipm> Almost any change is going to break some untested corner
> cases, while perhaps fixing other corner cases.
> <@jcorvel> philipm: so, realistically, this will probably not be fixed
> very soon (as in: in a 1.8.x release). At the very least, it needs (a
> lot of) work for coming up with a detailed spec etc ... to try and get
> a grip on the edge cases etc ...
> <philipm> I don't think it will be fixed in the near future. I don't
> know what we are going to do about externals.
>
>
> So I guess that answers it. It's not going to work in the near future.
> Short term I guess you have to find a workaround by structuring things
> differently. Longer term, someone needs to "champion" an effort to
> rework externals (starting by driving a discussion about it's
> specification etc ...). Volunteers welcome :-).
>
And some additional context was given by Bert Huijben:
<@Bert> jcorvel: Injecting file externals into a separate working copy
was deemed to be a never intended feature and a potential security
problem. It was explicitly disabled during 1.7 development.
<@Bert> jcorvel: The proper fix is part of the externals redesign to
something like viewspecs... where the file external just becomes a
working copy containing one file, but properly defined by some
ancestor
<@Bert> A problem with this 'feature' was that it was possible to
inject such externals, but not to remove them. The working copy that
contained the external didn't even contain the definition.
--
Johan
Re: SVN Externals 1.6 to 1.7 migration issue
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, May 1, 2013 at 5:01 PM, BRM <bm...@yahoo.com> wrote:
>> While I have not had the issue you are having, assuming the externals are in
>> the same repository I would highly recommend changing from using the syntax
>> you have to using the carrot (^) operator as it will save you many headaches
>> if your original svn location changes.
>>
>> I.e. use:
>>
>> ^/FOLDER_A FOLDER_C
>> ^/FOLDER_B FOLDER_D
>
> Indeed, that's far better than using an absolute url with scheme etc.
>
>> Also, I think the specific issue you are having (looking more closely at the
>> error message below) is that AFAIK, SVN does not let you import specific
>> files via externals - you have to do name spaces (aka folders) instead.
>
> That's not correct. File externals are supported (since 1.6 I think).
> They have a couple of specific problems though (a lot of which have
> been fixed in 1.7), because their implementation is entirely different
> from directory externals (file externals use the "switch" mechanism
> underneath, while dir externals are essentially an embedded checkout
> with some sugar on top).
>
> So, concerning to the problem of the OP:
>
>> From: "Hutchinson, Steve (UK)" <st...@mbda-systems.com>
>> To: "users@subversion.apache.org" <us...@subversion.apache.org>
>> Sent: Wednesday, May 1, 2013 7:01 AM
>> Subject: SVN Externals 1.6 to 1.7 migration issue
>>
>> Hi,
>>
>> We're been using 1.6 svn externals to manage a FW task.
>>
>> In the repository we have a folder structure (which is pretty much defined
>> by the tools we are using) as below :-
>>
>> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>>
>> Then using externals we link to those folder to create a WC PROJECT
>> structure that looks like :-
>>
>> PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND
>> file_b1.txt
>> PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
>>
>> The externals on PROJECT FOLDER we used looked like (not actually using file
>> protocol, just created for example purposes) :-
>>
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>>
>> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>>
>> External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>> Error: Cannot insert a file external defined on
>> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>> Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>>
>> We have tried a few things (will not share all at this point due to info
>> overload), but wondered if there were any others that achieve something like
>> this with 1.7 or could offer some advise ?
>
> So essentially you are "injecting" a file external (file_b1.txt)
> inside a directory external (FOLDER_C (an external of FOLDER_A)).
>
> Hm, I remember some past discussions about edge cases like these
> (during the working copy rewrite of 1.7), but I don't remember exactly
> if this is actually a supported use case, or if it just happened to
> work by accident in 1.6.
>
> Perhaps someone else on this list can shed some light on this?
I had the following conversation with Philip Martin, on IRC (#svn-dev):
<@jcorvel> philipm, perhaps you know the answer to this externals
question (works in 1.6, but no longer in 1.7):
http://svn.haxx.se/users/archive-2013-05/0006.shtml
<philipm> A file external defined in one working copy but located
inside another working copy is not going to work in 1.7 or 1.8.
<philipm> The directory external is a separate working copy with its
own .svn/wc.db and that knows nothing about the external defined in a
different .svn/wc.db
<@jcorvel> Ok. Sooo, is this more in the "it worked by accident in
1.6, but was never supposed to be supported" category? Or could this
be considered a regression?
<@jcorvel> I guess it doesn't matter ... semantics ...
<philipm> I don't suppose we ever supported it deliberately.
<@jcorvel> perhaps the more interesting question then is: is this at
all supportable within the externals design (of wc-ng)? Or would this
require "externals 2.0"?
<philipm> If we change directory externals to be more like switch then
the directory externals become part of a single working copy.
<@jcorvel> ack
<philipm> It may be relatively simple to do that. At present if you
try to "svn sw URL path" and path does not exist then the switch
fails.
<philipm> But it only fails because of a high level check on path, in
the past it was possible to switch a non-existant path.
<philipm> (In the past being during 1.7 development)
<philipm> If you switch a path that does not exist that looks very
much like an external (it is how file externals are implemented)
<philipm> One of the difficulties about externals is that the
specification is so relaxed that there are so many different cases.
<philipm> Almost any change is going to break some untested corner
cases, while perhaps fixing other corner cases.
<@jcorvel> philipm: so, realistically, this will probably not be fixed
very soon (as in: in a 1.8.x release). At the very least, it needs (a
lot of) work for coming up with a detailed spec etc ... to try and get
a grip on the edge cases etc ...
<philipm> I don't think it will be fixed in the near future. I don't
know what we are going to do about externals.
So I guess that answers it. It's not going to work in the near future.
Short term I guess you have to find a workaround by structuring things
differently. Longer term, someone needs to "champion" an effort to
rework externals (starting by driving a discussion about it's
specification etc ...). Volunteers welcome :-).
--
Johan
Re: SVN Externals 1.6 to 1.7 migration issue
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, May 1, 2013 at 5:01 PM, BRM <bm...@yahoo.com> wrote:
> While I have not had the issue you are having, assuming the externals are in
> the same repository I would highly recommend changing from using the syntax
> you have to using the carrot (^) operator as it will save you many headaches
> if your original svn location changes.
>
> I.e. use:
>
> ^/FOLDER_A FOLDER_C
> ^/FOLDER_B FOLDER_D
Indeed, that's far better than using an absolute url with scheme etc.
> Also, I think the specific issue you are having (looking more closely at the
> error message below) is that AFAIK, SVN does not let you import specific
> files via externals - you have to do name spaces (aka folders) instead.
That's not correct. File externals are supported (since 1.6 I think).
They have a couple of specific problems though (a lot of which have
been fixed in 1.7), because their implementation is entirely different
from directory externals (file externals use the "switch" mechanism
underneath, while dir externals are essentially an embedded checkout
with some sugar on top).
So, concerning to the problem of the OP:
> From: "Hutchinson, Steve (UK)" <st...@mbda-systems.com>
> To: "users@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Wednesday, May 1, 2013 7:01 AM
> Subject: SVN Externals 1.6 to 1.7 migration issue
>
> Hi,
>
> We're been using 1.6 svn externals to manage a FW task.
>
> In the repository we have a folder structure (which is pretty much defined
> by the tools we are using) as below :-
>
> FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
> FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>
> Then using externals we link to those folder to create a WC PROJECT
> structure that looks like :-
>
> PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND
> file_b1.txt
> PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
>
> The externals on PROJECT FOLDER we used looked like (not actually using file
> protocol, just created for example purposes) :-
>
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
> file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>
> Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>
> External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
> Error: Cannot insert a file external defined on
> 'D:\FPGA\SVN_ISSUE\PROJECT' into the
> Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>
> We have tried a few things (will not share all at this point due to info
> overload), but wondered if there were any others that achieve something like
> this with 1.7 or could offer some advise ?
So essentially you are "injecting" a file external (file_b1.txt)
inside a directory external (FOLDER_C (an external of FOLDER_A)).
Hm, I remember some past discussions about edge cases like these
(during the working copy rewrite of 1.7), but I don't remember exactly
if this is actually a supported use case, or if it just happened to
work by accident in 1.6.
Perhaps someone else on this list can shed some light on this?
--
Johan
Re: SVN Externals 1.6 to 1.7 migration issue
Posted by BRM <bm...@yahoo.com>.
While I have not had the issue you are having, assuming the externals are in the same repository I would highly recommend changing from using the syntax you have to using the carrot (^) operator as it will save you many headaches if your original svn location changes.
I.e. use:
^/FOLDER_A FOLDER_C
^/FOLDER_B FOLDER_D
Also, I think the specific issue you are having (looking more closely at the error message below) is that AFAIK, SVN does not let you import specific files via externals - you have to do name spaces (aka folders) instead.
I would suggest doing one of two things in a batch file that gets run after checkout (manually by the user, though TSVN may be able to give you some automatic client-side scripting):
1. Use "mklink" to create an NTFS file link after the checkout for the file you are trying to relocate.
2. Copy the file from the one directory to the other
Or
3. Copy the file as part of the SVN source tree to the other folder; but you'll also have to continuously merge the changes back and forth.
#1 is your best option if you want to not change anything at all, but requires that you are running a newer version of Windows than Windows XP. I think Microsoft first started providing the "mklink" utility with Vista; but it could be WIn7, and might also depend on which edition of each of those you have as well. (e.g. it might not be in the Home Premium version, but might be in Pro and Ultimate).
#2 is an okay backup if you can't do #1, but you'll need to treat the file as read-only as it will certainly be very much manual effort to maintain.
#3 is automatic, but you'd have to ensure the file matches what is at its origin - a bit of a manual effort, but easy to do.
$0.02
Ben
>________________________________
> From: "Hutchinson, Steve (UK)" <st...@mbda-systems.com>
>To: "users@subversion.apache.org" <us...@subversion.apache.org>
>Sent: Wednesday, May 1, 2013 7:01 AM
>Subject: SVN Externals 1.6 to 1.7 migration issue
>
>
>Hi,
>
>We're been using 1.6 svn externals to manage a FW task.
>
>In the repository we have a folder structure (which is pretty much defined by the tools we are using) as below :-
>
>FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt
>FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt
>
>Then using externals we link to those folder to create a WC PROJECT structure that looks like :-
>
>PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND file_b1.txt
>PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt
>
>The externals on PROJECT FOLDER we used looked like (not actually using file protocol, just created for example purposes) :-
>
>file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C
>file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D
>file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt
>
>Worked ok with 1.6. We get the below error in 1.7 when updating of :-
>
>External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt
>Error: Cannot insert a file external defined on 'D:\FPGA\SVN_ISSUE\PROJECT' into the
>Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'.
>
>We have tried a few things (will not share all at this point due to info overload), but wondered if there were any others that achieve something like this with 1.7 or could offer some advise ?
>
>Thanks for any help.
>
>Regards
>Steve H
>
>********************************************************************
>This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
>
>MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
>
>********************************************************************
>
>
>