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
Received on Wed Dec 6 11:07:02 2006