Bill
We have a more somewhat general situation. Our software contains a
collection of modules in SVN. We have multiple product applications that
use different combinations of the modules. That is, modules are shared
across the different applications. For such sharing to work, we find
that it is critical to use a 2-tier approach to track and tag the
evolution of the software - both at the component module level as well
as at the application level.
Each module's software development is managed in very much the
branch/tags/trunk structure you describe. Our application definition
however is very lightweight. An application is simply a clearly defined
combination (via a config file) of the modules it needs. For practical
purposes, an application is simply a configuration file that lists its
modules and their tagged versions. Given such a configuration file, we
have a mechanism to checkout the required modules to create an
application specific sandbox. Application version evolution consists of
the evolution of its configuration file, i.e. an application evolves in
time by using different versions of the modules. Arbitrary combinations
of modules will typically not work togethger - and application tags are
ways of tracking configuration files that list the module version
combinations that do work together. So releases are made both at the
module as well as the application level.
Basically, we found that we could not fully solve the problem of sharing
code across applications all within SVN (or CVS). However SVN gets us a
long way there. We have an additional collection of Perl scripts -
collectively known as YaM - that when used with SVN as described above,
allows us to manage multiple application products that share
software. YaM originally worked with CVS but now supports SVN as
well. You can read find out more about it at
http://dartslab.jpl.nasa.gov/yam and/or read the paper at
http://dartslab.jpl.nasa.gov/References/pdf/2006-yam-smcit.pdf.
If there is interest I can look into making YaM more easily available.
Abhi
On Mon, Dec 18, 2006 at 10:50:32PM +0000, Bill Mill wrote:
> Here's a rough sketch of our repository:
>
> /project.root
> /Apps
> /app1
> /branches
> /tags
> /trunk
> /app2
> /branches
> /tags
> /trunk
> /Common
> /branches
> /tags
> /trunk
>
> ATM, all applications statically compile in the source of "Common", because it's
> under very heavy development. (I plan to change this once it stabilizes, but
> assume that this is unchangeable for now.)
>
> The question is, how should I create a Tag for version 1 of app1, such that it
> includes Common in some way?
>
> After much discussion of svn:externals, various branching schemes, and other
> weirder ideas, a fellow programmer and I decided that the best answer was to
> copy the app1 release into app1/tags/version1 , then copy /Common/trunk into
> app1/tags/version1/commonlib .
>
> Is this the way you would do it? Is there a better way?
>
> You may either assume that repo structure is fixed, or argue that there's a
> structure which is *so* better that it justifies the cost of rearranging
> everything - both are valid.
>
> The only 2 requirements are that I can
> a) build app1/tags/version1 10 months from now, and
> b) svn diff app1/tags/version1 app1/tags/version2
>
> Thanks for any ideas,
> Bill Mill
> bill.mill at gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 19 18:56:10 2006