On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt
<subversion-2012c_at_ryandesign.com> wrote:
>
> On Jul 25, 2012, at 17:50, Benjamin Fritz wrote:
>
>> That's interesting that it works like a switch underneath. But it IS
>> very possible to pull in *directory* externals from other
>> repositories
>
> Absolutely.
>
>> which makes me wonder about whether this is relevant.
>
> 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.
>
>> The explanation works for file externals but doesn't explain why
>> directory externals from other repositories work.
>
> 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).
>> Yeah, absolute paths work in 1.6.17, but not in 1.7.5. See the
>> following transcript from a 1.6.17 working copy. I've removed output
>> from directories not related to this discussion:
>>
>> scarecrow_SunOS_btfritz> svn --version
>> svn, version 1.6.17 (r1128011)
>> compiled Oct 12 2011, 12:29:56
...
>> scarecrow_SunOS_btfritz> svn propget svn:externals
>> ##### latest version of scripts and user models #####
>> http://asvn/ifis-sw/tools/coverity/user_models user_models
>> http://asvn/ifis-sw/tools/coverity/scripts scripts
>> # also pull in the readme file
>> http://asvn/ifis-sw/tools/coverity/README.txt scripts/README.txt
>>
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*.
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).
>>
>> 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.
From 'svn help update' (a similar explanation is in 'svn help switch'):
[[[
For each updated item a line will be printed with characters reporting
the action taken. These characters have the following meaning:
...
E Existed
...
If --force is used, unversioned obstructing paths in the working
copy do not automatically cause a failure if the update attempts to
add the same path. If the obstructing path is the same type (file
or directory) as the corresponding path in the repository it becomes
versioned but its contents are left 'as-is' in the working copy.
This means that an obstructing directory's unversioned children may
also obstruct and become versioned. For files, any content differences
between the obstruction and the repository are treated like a local
modification to the working copy. All properties from the repository
are applied to the obstructing path. Obstructing paths are reported
in the first column with code 'E'.
]]]
This seems to indicate that the scripts/README.txt was already there
in the working copy, and that it wasn't updated at all.
--
Johan
Received on 2012-07-26 15:32:33 CEST