"svn copy" or svn:externals?

[Michael Pruemm <mp...@eso.org>]

We are in the process of converting our old source code repository to 
svn. The old repository is flat, all modules are stored on the same 
level. We have a build tool that, given a configuration file, checks out 
all modules that form an individual application and place them in an 
appropriate hierarchy and then builds and installs the application.

The layout for a typical application is:

   ./mod1
   ./ICS/mod2
   ./ICS/...
   ./DCS/...
   ...
   ./COMMON/modX
   ./COMMON/...

In svn, we want to store all modules in this hierarchical form.

My question is what to do with the "COMMON" directory above. The modules 
in this directory do not belong to the application, but are specific 
versions of modules that override the version preinstalled on all our 
systems. Ideally, an application has no need to override one of these 
modules, but sometimes it is necessary e.g. because of a bugfix needed 
by the application.

A module override must refer to a tagged version of the module.

As I see it, we have two options for the modules in "COMMON":

1) use "svn copy modX/tags/... COMMON/modX" for each module
2) use an svn:externals property to place all modules in COMMON

What are the advantages and disadvantages of these options?
Which one is better, and why?

- Michael

Re: "svn copy" or svn:externals?

[Nico Kadel-Garcia <nk...@gmail.com>]

On Wed, Aug 11, 2010 at 6:20 AM, Michael Pruemm <mp...@eso.org> wrote:
> We are in the process of converting our old source code repository to svn.
> The old repository is flat, all modules are stored on the same level. We
> have a build tool that, given a configuration file, checks out all modules
> that form an individual application and place them in an appropriate
> hierarchy and then builds and installs the application.
>
> The layout for a typical application is:
>
>  ./mod1
>  ./ICS/mod2
>  ./ICS/...
>  ./DCS/...
>  ...
>  ./COMMON/modX
>  ./COMMON/...
>
> In svn, we want to store all modules in this hierarchical form.
>
> My question is what to do with the "COMMON" directory above. The modules in
> this directory do not belong to the application, but are specific versions
> of modules that override the version preinstalled on all our systems.
> Ideally, an application has no need to override one of these modules, but
> sometimes it is necessary e.g. because of a bugfix needed by the
> application.
>
> A module override must refer to a tagged version of the module.
>
> As I see it, we have two options for the modules in "COMMON":
>
> 1) use "svn copy modX/tags/... COMMON/modX" for each module
> 2) use an svn:externals property to place all modules in COMMON
>
> What are the advantages and disadvantages of these options?
> Which one is better, and why?

It's a tradeoff: having local modules means you can check out projects
indipendently, and modify "COMMON" locally, only merging contents back
to the trunk "COMMON" when needed. But it leaves you vulnerable to
version skew in COMMON:

You mgiht consider using "svn:externals" to provide access to COMMON
from within a project. That could also lock down the revision of the
copy you're using.