Yes, I have different repositories hosted by the same Apache vhost (with
the SVNParentPath directive), and I can use relative paths to make
externals of folders between different repositories (different databases).
And they actually are on different hosts thanks to NFS.
From Piotr Kabacinski response (I compiled the mails) "You can use
relative path when accessing the same repository"
This is exactly the ambiguous use of terms I'm talking about. I can
think that I can't use svn:externals on different repositories, but I
can if they have the same FQDN (I think we're currently using 20-30
externals of this kind).
My question is, is there an ambiguous use of terms in the svn-book ?
I can't find any reference on the multi-HTML book. They are some in the
single-HTML :
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals
It is said "File externals are configured just like externals for
directories and appear as a versioned file in the working copy"
It is a bit more explicit than the PDF version I read before posting.
The best way is, I think, to test it.
I'll answer with my results.
P.S. : The rest of your mail is slightly out of the scope of my
question, but in our case the "freezers (i.e. project managers)" have
the choice to manually edit svn:externals properties or use built
externals librairies. This choice is mostly dependent on the persons.
Le 23/11/2010 15:09, David Weintraub a écrit :
> On Tue, Nov 23, 2010 at 8:43 AM, Bastien Semene
> <bsemene_at_cyanide-studio.com> wrote:
>> Hi,
>>
>> I read in the svn-book that file externals are supported only in the same
>> repository. But it is not clear in my repositories architecture :
>>
>> My repositories are accessed through Apache and all use the same FQDN/vhost.
>
> So, you have multiple repositories on the same host?
>
> No, each repository has its own database and is distinct even though
> they maybe on the same host and even in the same Apache instant.
>
> However, I've usually find that externals aren't really worth the
> effort it takes to really support them.
>
> Let's say you have a project "foo" which is
> http://FQDN/repo1/foo/trunk, and it is using as an external project
> http://FSND/repo1/bar/trunk. So, you create the following external:
>
> $ svn propset svn:externals http://FQDN/repo1/bar/trunk bar
>
> Everything is fine, and you're ready to do a release of foo:
>
> $ svn cp http://FQND/repo1/foo/trunk http://FQND/repo1/foo/tags/FOO-1.0
>
> However, all is not well. Your tag is not static because whenever
> http://FQND/repo1/bar/trunk changes, the files you'd checkout under
> FOO-1.0 will change. That's because your svn:externals property points
> to the trunk of bar, and not to a particular revision. If you need to
> create a new release FOO-1.0.1 based upon FOO-.1.0, the files under
> bar would not be what you think they are.
>
> In order to get around this, you need to point your svn:externals
> property in foo to a particular revision of bar. This could be a
> tagged revision (although in theory tags can change, but not likely).
> Or to an actual revision of bar (using the -r parameter). Also, you
> may want to peg bar to that revision while you're at it. Otherwise,
> the directory structure of bar could change, and that would affect
> your tag of foo. Thus, when you create the external, you really should
> do something like this:
>
> $ svn propset svn:externals -r1000 ^/repo1/bar/trunk_at_1000 bar
>
> This will freeze your svn:externals project at revision 1000 of your
> repository, and make sure that the way the bar directory looks the
> same as it did at revision 1000.
>
> Another thing I've seen is from sites where the trunk, branches, and
> tags directories are all on the root of the repository. Thus the URL
> for FOO would be:
>
> http://FQDN/repo1/trunk/foo
> http://FQDN/repo1/tags/foo/FOO-1.0
>
> and the URL for BAR would be:
>
> http://FQDN/repo1/trunk/bar
> http://FQDN/repo1/tags/bar/FOO-1.0
>
> In this case, you could set the svn:externals like this:
>
> $ svn propset svn:externals ../../bar bar
>
>
> This way, the branching and tagging schemes of BAR and FOO will match
> even when you do a URL copy and create new branches and tags (as long
> as both FOO and BAR have the same branches and tags setup).
>
> I find the best way is to just make BAR a releasable subproject. You
> could zip up its source code or compile bar into some sort of object
> file that FOO can use (a jarfile for a Java project, or a *.dll or
> *.so for C or C++ projects). Then, I'd have my build file copy the
> correct version of bar down from the release repository as part of my
> build process. That way, you don't have to maintain svn:externals, or
> be limited by the fact that svn:externals projects have to live in the
> same repository as the master project.
>
> The svn:externals seemed like such a good idea when I first heard of
> Subversion, but I quickly discovered that it can be very difficult to
> implement correctly.
>
--
Bastien Semene
Administrateur Réseau& Système
Cyanide Studio - FRANCE
Received on 2010-11-23 15:47:12 CET