RE: common libraries and several repositories.

We do not currently use multiple repos, but perhaps this is still useful
info on how we choose to work with common code in a single repo.

We use a single repository and svn:externals to reference common libraries
within this repository.

Whilst one can specify specific revision numbers in an externals property
(and it's recommended by the docs), we instead set externals references
exlusively to /tags folders. We think of "tags" subfolders to be read only,
and thereby represent a specific repository revision "snapshot". We enforce
it by preventing modifications to tags via a hook script.

For example, MyLib version 2.0.0.0 is pulled in using a svn:externals
reference like

References/MyLib svn://repo/common/MyLib/tags/2.0.0.0

(by convention, we have all external project references land in a working
copy "References" subfolder).

When a new release of the common library is available (e.g.
MyLib/tags/2.1.0.0) the devs can switch their working copy to this new
release, test, and when all proves dandy, update the external reference to
point to the new tag version.

I may be missing something, but it seems easier for users to think of
externals as referencing a (readonly) tag folder with a meaningful version
name (e.g. MyLib/tags/2.0.0.0) rather than just anywhere in the repository,
anchoring with revision number (e.g. 342342).

-----Original Message-----
From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
Sent: Wednesday, May 23, 2007 5:09 AM
To: users@subversion.tigris.org
Subject: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org