On Wed, Jul 25, 2012 at 6:23 PM, Benjamin Fritz <fritzophrenic_at_gmail.com> wrote:
> I have two repositories and I am using svn:externals to place a
> directory and a few files from one repository into a working copy of
> the other.
>
> I have the following two svn:externals definitions on a directory in
> my working copy for the repo-A repository:
>
> ^/../repo-B/tools/coverity/scripts scripts
> ^/../repo-B/tools/coverity/README.txt scripts/README.txt
Wow, so you're ascending beyond the repository root, to refer to
something from another repository (on the same server). I didn't know
that worked. I'm not sure if that's a supported use case ...
> Note that this will create a "scripts" directory from repo-B in
> repo-A's working copy, and then place a single file from repo-B into
> the directory from repo-B. This worked fine in 1.6.17, but on upgrade
> to 1.7.5, I get the following message when I do "svn update":
>
> Fetching external item into 'scripts\README.txt':
> svn: warning: W200007: Unsupported external: url of file external
> 'http://server/repo-B/tools/coverity/README.txt' is not in repository
> 'http://server/repo-A'
>
> and then:
>
> At revision 885.
> svn: E205011: Failure occurred processing one or more externals definitions
>
> I get the same results on Windows XP 64-bit as I do on a Solaris 9 system.
>
> I searched the bug tracker for "externals" (155 issues found) but none
> of the results seemed relevant. The documentation (
> http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ) says
> that "A file external's URL must always be in the same repository as
> the URL that the file external will be inserted into," but even though
> the file is from a different repository in this case, it is being
> PLACED INTO a directory from the same repository, so I expect it to
> work (especially since it worked in 1.6.17).
No, what it means is that a file external must come from the same
repository, not from a different one. That's because file externals
are implemented internally like a "switch", and "svn switch"-ing
(without --relocate) also only works if you're switching to some other
path inside the same repository. So I think this was never intended to
work, and I'm surprised that it worked for you in 1.6.17.
Maybe the 1.7 (or 1.7-upgrade) code tightened the checks a bit, by
normalizing the url's in those external definitions (so it saw that
those url's are really from a different repository).
Regarding the fact that this worked in 1.6.17: as a test, if you
replace those "^/../repo-B" url's, in the externals definition, with
absolute url's including scheme etc, does that still work?
> A Google search for the W200007 message turns up only a collection of
> hits for commits to the SVN project. I have not spent a lot of time
> deciphering the code changes from these commits, but at a glance (and
> from the commit message) it appears as if a check was added
> specifically to prevent using externals from different repositories.
> I'm not sure whether it was intentional that it removed the use case
> of grabbing a file from a different repository and placing it into a
> directory from that same repository.
>
> Whether or not this is going to be fixed, is there a workaround that
> would allow me to get the README.txt file into repo-A from repo-B
> without getting the entire directory containing it? Or should I just
> give up and put README.txt into repo-A directly (probably in a
> location that multiple projects in the repository can access via
> svn:externals)?
Sorry, no concrete suggestions here ...
--
Johan
Received on 2012-07-26 00:08:45 CEST