Linking repositories

["Gourlay, Colin " <C....@hw.ac.uk>]

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 possible.

 

Any advice is really appreciated.

 

Thanks

 

 

 

Re: Linking repositories

[Ulrich Eckhardt <ec...@satorlaser.com>]

On Wednesday 06 December 2006 10:20, 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.

The 'normal' approach is to treat the component as a library and use it in 
those other applications. Of course, this requires that the component is 
properly versioned and doesn't have a volatile interface whos changes always 
break the applications using it.

If you only have a handful of apps and the component is changing a lot, you 
could also simply copy the component into the apps. This means that you will 
need a "main" store for the component where it is developed and you will 
manually have to update projects for those changes to take effect. This is 
not the way that scales best, but it definitely is a way to go with few 
applications using a common part. For this it is typically better to have 
everything in one repository.

> 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 possible.

Theoretically, the component and the apps using it can be separate. It isn't 
necessary to keep them in separate repositories though. How to connect those 
is a different thing: depending on how the component is installed, setting a 
path in the application's local setup (using e.g. environment variables) 
might be one way, binding it into the app's own source directory using 
svn:external (see the book) might be another.

Uli

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Linking repositories

[Tim Hill <dr...@comcast.net>]

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.

--Tim


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  
> possible.