[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Practical experience using externals

From: Jean-Baptiste Maillet <jb.maillet_at_free.fr>
Date: 2006-03-08 13:39:49 CET

Externals are what you're looking for.

We do use external properties in all our projects. External properties is
one of the reasons (with handling of binary files and special files like
symlinks) why we switched from CVS, and the reason why ClearCase users
accept to switch with us (external properties can be viewed as the
equivalent of CC's config specs). External properties is what makes
subversion a configuration management tool, rather than just a versionning

Let's say we have a path http://myrepos/svn/main/Packages/pck_foobar/trunk,
containing nothing but an external property which content is :

# foobar package, trunk :
# http://myrepos/svn/main/Packages/pck_foobar/trunk/


Now, one can issue :
svn co http://myrepos/svn/main/Packages/pck_foobar/trunk pck_foobar
... and this will :
checkout http://myrepos/svn/main/Modules/autoconf/trunk and place it in
checkout http://myrepos/svn/main/Modules/configs/trunk and place it in
checkout http://myrepos/svn/main/Modules/configs/trunk and place it in
checkout http://myrepos/svn/main/Modules/devices/gizmo/trunk/ and place it
in pck_foobar/foobar/devices/gizmo

Thus, you obtain 1 working copy, actually made of 4 separate svn projects.
A svn up from
The point is that this way, each project can have its own developement
rythm. (Actually, this is not 1 big workin copy, but 4 : the commit have
to be performed in the various subdir)

The syntax is :
<where in the WC> <revision> <repository path>

Examples (this can be mixe in a single external) :
foobar http://myrepos/svn/main/Modules/autoconf/trunk/
foobar/configs -r1234 http://myrepos/svn/main/Modules/configs/trunk/

Basic commands :
svn proplist .
svn propget .
svn propedit svn:externals .

Now, if one want to make a branch of this, he may have to actually create
two branches : one for the external (which is just a container, pulling
other repos path), and one/some for each of the path pulled by the

Note that it is possible to make externals pointing to externals (a russian
doll scheme, tink of pointers to pointers) - I tried it, it works, I don't
think we'll use it soon though...

These external properties are great if you use subversion in a big
organisation, running multiple projects with several soft teams. A
product, as delivered to the customer, can be defined as a set of modules
at various state of dev/config : this is exactly what an external is.

Now, what's still missing :
- a way to "visualize" external, for instance in RapidSVN and ViewVC. Its a
bit tricky to stat/diff/merge/manage conflicts on externals.
- support for date in external. The main documentation states that a date
can be used werever a revision is, this does not seems to be the case for
revisions, see :

External properties are a great feature, I encourage any subversion user to
experiment with it.

Quoting Elbert Wall <Elbert_Wall@hilton.com>:

> I've been poring over the posts to this list, and can't find much in the
> way of information on the use of externals. We are in the process of
> converting from SCCS to subversion for our AIX code, and have some
> libraries that are shared among projects. We'd like to create a project
> for, say, DatabaseUtilities, and then use that as an external to, say,
> project RevenueTracking.
> Does anyone have any hands-on experience doing this? The Subversion
> manual section on this is pretty thin gruel. I'd like something that
> will stick to my ribs.
> E W Wall
> elbert_wall@hilton.com

Jean-Baptiste Maillet
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 8 13:42:21 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.