On Fri, Nov 5, 2010 at 10:09 AM, Stefan Sperling <s...@elego.de> wrote:
> The designers of the externals feature envisioned maybe a handful
> of external library dependencies that don't vary much over time.
> These are automatically pulled into a working copy, much like an automated
> svn checkout.
>
> But the design doesn't account for what happens when people start using
> svn:externals for variant management or large-scale component reuse.
> If you're pulling together project components from externals in various
> combinations, like lego blocks, or simply have many externals, don't use
> the svn:externals properties as the primary source of your configuration data.

The big problem with svn:externals is that they don't version very well.

Imagine I have a project called "foo", and in the root directory, I
set an svn:external property to pull in the trunk of module "bar" that
contains certain routines I'm using:

    $ svn propset svn:externals "bar /externals/bar/trunk"

When "foo" is ready for Release 1.0, I create a tag:

    $ svn copy svn://subversion/foo/trunk svn://subversion/foo/tags/REL-1.0

Everything is fine and dandy, but we found a few bugs, so we're going
to create a Release 1.1 to fix those bugs. I create my 1.1 branch:

    $ svn copy svn://subversion/foo/tags/REL-1.0
svn://subversion/foo/branches/1.1

But, there's a problem. I discover that what is tagged as REL-1.0
isn't the code I released. In fact, all the difference between what
has been tagged and what was released are in that bar subdirectory
that was created by my svn:externals property.

The problem is that the external directories themselves aren't tagged
or branched when I did my tag or branch. Instead, the "svn:external"
property itself was versioned, and if you have that pointing to just
the branch or the trunk without a version number, that external
directory can keep changing in the tag.

You can partially solve that problem by making sure your svn:external
property points to a specific tag and/or a specific version of the
external directory. But, then you have to start keeping the
svn:external tags up to date which can be a headache if you have a lot
of them.

When I first started using Subversion, I though svn:externals was a
great feature. But I quickly discovered what a mess they can create. I
now take the approach of thinking of my externals as "releasable
components" that are also versioned and released, and I put them into
a release repository where various projects can import a specific
revision of that component. This makes it much easier for developers
to track what particular version of that component they're using.

-- 
David Weintraub
qazw...@gmail.com

Reply via email to