On Thu, May 2, 2013 at 9:55 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Wed, May 1, 2013 at 5:01 PM, BRM <bm_witn...@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)" <steven.hutchin...@mbda-systems.com> >> To: "users@subversion.apache.org" <users@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