On Thu, Jul 26, 2012 at 2:10 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt > <subversion-20...@ryandesign.com> wrote: >> >> It's my understanding that file externals (which are a relatively new >> feature for Subversion) are implemented very very differently under the hood >> from directory externals (which have been around for a long long time) so >> it's not surprising they would have very different restrictions and >> behaviors. >> >> Directory externals are implemented as additional "svn checkout"s (or >> updates) following the primary checkout (or update). >> > > Indeed. Directory externals are a lot like an embedded checkout with > some sugar around. This was a pretty early feature of Subversion. > > But this technique could only work for embedding entire directories, > because a checkout is directory-based as well (you can't checkout a > single file). So later someone implemented file externals as an > additional feature, but had to use a different technique for that > (using the 'switch' infrastructure, yielding the additional > restriction of being able to use only "intra-repository" file > externals). >
Thanks, that does clear things up. That's a pretty clever trick. > > Just to double-check that we're testing the right thing here: > http://asvn/ifis-sw (or http://asvn/ifis-sw/tools or > http://asvn/ifis-sw/tools/coverity) is a different repository than the > one where you set the externals property (the repository from which > your working copy is a checkout), right? So we're testing pulling in > externals from a *foreign repository*. > Correct. The repository is http://asvn/ifis-sw, and I'm pulling it into a working copy in http://asvn/ifis-dev (plus a few directories). > Just checking because it's not really clear from your example, and > above you also mention that "absolute paths work", but the problem is > not about absolute paths per se, but about externals from foreign > repositories (and I asked you to verify the 1.6 behavior also with an > absolute path to that foreign repository). > Right, but you mentioned I should try with absolute paths. I chose to demonstrate it works with absolute paths, and also to demonstrate the problem with a transcript rather than just a prose description. >>> >>> scarecrow_SunOS_btfritz> svn update > ... >>> Fetching external item into 'scripts/README.txt' >>> E scripts/README.txt >>> Updated external to revision 8699. > > Hm, I'm not sure if that indicates success actually. The 'E' > notification means that some unversioned file obstructed the update, > so I'm not sure if README.txt was actually updated to be like > http://asvn/ifis-sw/tools/coverity/README.txt. > > [snip] > > This seems to indicate that the scripts/README.txt was already there > in the working copy, and that it wasn't updated at all. > Good to know. I should have read the documentation, I assumed it meant "external" and since there was no warning message that it worked as expected. I thought maybe that's because I was using update on an existing working copy after removing the directory. I tried again, using just "svn checkout" on a completely empty directory, but get the same results: ========================================== scarecrow_SunOS_btfritz> cd temp /accts/btfritz/temp scarecrow_SunOS_btfritz> mkdir external-test [update path to use old svn] scarecrow_SunOS_btfritz> cd external-test /accts/btfritz/temp/external-test scarecrow_SunOS_btfritz> svn --version svn, version 1.6.17 (r1128011) compiled Oct 12 2011, 12:29:56 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.apache.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). [snip RA modules] scarecrow_SunOS_btfritz> svn checkout http://asvn/ifis-dev/[project path]/trunk/coverity . A cov5data A cov5data/build_output U . Fetching external item into 'user_models' A user_models/mutex.c A user_models/mutex_funcs.xmldb U user_models Checked out external at revision 8700. Fetching external item into 'scripts' A scripts/compiler_setup_FSA-5000.csh A scripts/compiler_setup.csh A scripts/cov5run.csh Checked out external at revision 8700. Fetching external item into 'scripts/README.txt' E scripts/README.txt Checked out external at revision 8700. Checked out revision 901. scarecrow_SunOS_btfritz> ls scripts compiler_setup.csh cov5run.csh compiler_setup_FSA-5000.csh README.txt scarecrow_SunOS_btfritz> svn info scripts/README.txt Path: scripts/README.txt Name: README.txt URL: http://asvn/ifis-sw/tools/coverity/README.txt Repository Root: http://asvn/ifis-sw Repository UUID: 2c721b55-c2f9-124f-bb0b-342981104e5a Revision: 8700 Node Kind: file Schedule: normal Last Changed Author: ccanet\btfritz Last Changed Rev: 8633 Last Changed Date: 2012-07-03 17:02:58 -0500 (Tue, 03 Jul 2012) Text Last Updated: 2012-07-26 10:48:57 -0500 (Thu, 26 Jul 2012) Checksum: 714960c230b3f57b093a065092c9b3b1 ========================================== It is strange that I'm getting 'E' for "existed" when there was no README.txt file already in that directory. Additionally, it DOES result in an README.txt file exactly where I want it when the checkout completes, and svn info shows that it is associated with the correct repository location. When I delete the external-test directory and follow exactly the same procedure using the 1.7.5 svn client, I get the W200007 message given earlier, and no README.txt file in the scripts directory.