You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Elbert Wall <El...@hilton.com> on 2006/03/07 21:06:59 UTC
Practical experience using externals
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
Re: Practical experience using externals
Posted by Jacob Atzen <ja...@aub.dk>.
On Tue, Mar 07, 2006 at 03:06:59PM -0600, Elbert Wall wrote:
> 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.
I have practical experience doing this, and it's not that hard. Say you
have a directory structure like:
- project
- source
- libs
And you want to import some libraries into libs you simply do something
like:
svn pe svn:externals /path/to/libs
And in that "file" you insert the references as described in the
book[1]:
third-party/sounds http://sounds.red-bean.com/repos
Or you might want to check out a speciel revision instead of the head:
third-party/sounds -r21 http://sounds.red-bean.com/repos
I hope this helps.
--
Cheers,
- Jacob Atzen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Practical experience using externals
Posted by Jean-Baptiste Maillet <jb...@free.fr>.
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
one.
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/
foobar
http://myrepos/svn/main/Modules/autoconf/trunk/
foobar/configs
http://myrepos/svn/main/Modules/configs/trunk/
foobar/utils
http://myrepos/svn/main/Modules/utils/trunk/
foobar/devices/gizmo
http://myrepos/svn/main/Modules/devices/gizmo/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
pck_foobar/foobar,
checkout http://myrepos/svn/main/Modules/configs/trunk and place it in
pck_foobar/foobar/configs,
checkout http://myrepos/svn/main/Modules/configs/trunk and place it in
pck_foobar/foobar/utils,
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/
foobar/configs
http://myrepos/svn/main/Modules/configs/tags/delivery-20060308-thisandthat/
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
external.
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 :
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=45807
External properties are a great feature, I encourage any subversion user to
experiment with it.
Quoting Elbert Wall <El...@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