Re: common libraries and several repositories.

On Wednesday 23 May 2007 12:49, claudia logan wrote:
> I am new to subversion and I am trying to figure out the best way to set
> up my repositories. Right now the plan is to have three repositories
> housing major projects, the challenge is the sharing of common
> libraries/files between all three. Our first thought is to have the common
> libraries in one repository and follow the externals procedure.

My first one would be to not put them into separate repositories. If they are
related and share code, having things within a single repository helps
merging changes while preserving history.

> however, it seems that it wont properly capture the right revision of
> the common library.

IIRC, externals simply capture what they find at the given URL, and that is
the (moving) HEAD revision. I'm not sure if you can also specify a specific
revision for externals.

> My questions are:
> 1. what is the proper way to set up the common libraries so that are
> three repositories share them, and CMing the right revisions with the right
> product.
> 2. If a common library is changed affecting one repository, and
> not the others, what is the best way to capture the proper revision and
> recreat it 6 months later. and conversely,
> 3. how to manage the other two
> repositories that do not need the immediate change, but may later.

I'd suggest this:
You put the related projects and the library into a single repository. While
developing, the projects point to the trunk of the library (via externals or
other means doesn't matter). Otherwise, all parts follow the suggested
trunk/branches/tags layout (see the Subversion book).

Now, if you want to release a project, you first create the release folder and
then copy both the library and the project into it (remember, those are cheap
copies in Subversion) or use a different way to connect this to a specific
release of the library.

A different model would be to maintain copies of the library within each
project dir. This makes tagging/branching less complicated. However, it
requires a conscious effort from a developer to import bug-fixes to the
library's trunk into these copies. Moving changes from those copies to the
trunk might be necessary, too, unless you forbid changes to the copies. If a
project isn't touched, its copy of the library also remains unchanged, so you
would get the exact state for both the lib and the project using it.

This would be pretty much the same as using externals with an explicit
revision. Those also require a developer to explicitly update the external
and hopefully run the regression tests afterwards.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Ronald Boers, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           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