On Wed, Aug 11, 2010 at 6:20 AM, Michael Pruemm <mpruemm_at_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.
Received on 2010-08-11 13:39:18 CEST