First, you don't _need_ a distinct repository for the component. In
general, its not necessary to use the repository itself as a unit of
organization; typically distinct repos are used for other reasons,
such as size, performance, separate servers and different security
domains. You can organize the tree of a single repo to support any
number of discrete projects with a little planning.
If you do choose to use a distinct repo then you will have to use
externals to pull the component source into each application. If you
use the same repo, you can just use branches.
There are several solutions to sharing a component, depending upon
how tightly the component is bound to the apps and on your overall
life-cycle process. One way is to use the "vendor branch" model (see
the Subversion book for details), in which the component is a
distinct project with its own release cycle etc. Then, you simply use
a branch to bring the desired version of the component into each
application. This approach has the advantage that you can choose when
each application upgrades to newer versions of the component
independently. However, you have to manually take action in each
dependent app to get the latest version when it released.
Another approach is to integrate at build time. That is, treat the
component as discrete at the source level but integrate during build.
This means that each build always gets the latest component, but also
means that they _must_ get the latest. This is also more suitable for
using externals to integrate the component source.
On Dec 6, 2006, at 1:20 AM, Gourlay, Colin wrote:
> I have a situation where I have a main stream of development (the
> application being developed) and a component that I see being used
> in a variety of different applications because it is so generic.
> I am not sure how to manage this in Subversion.
> Is it good form to have a repo for the CRM and a different repo for
> the application being developed and somehow link them – if that is
Received on Wed Dec 6 17:32:26 2006