On Thu, Jul 26, 2012 at 2:10 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt
> <subversion-2012c_at_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.
Received on 2012-07-26 17:52:28 CEST