Re: What's a "trunk" good for? (apart from eating peanuts)

On Jan 13, 2007, at 00:22, Byron Brummer wrote:

> Another option for this type of situation is to treat the common
> lib as it's own project with its own releases. The separate
> projects,
> A, B, etc treat the common lib as if it was from a 3rd party source.

We do something similar on current project. We're providing a
platform for web services and have split this into two "products",
Commons, which is composed of 6 or so various interdependent modules
(utils, utils_xml, mime, validation, etc.) and Services, which uses
most of the Commons modules and provides the WS infrastructure.

The clients of our Services also make use of Commons. For example,
Commons/validation is a framework for validating the input which
consists of a XML payload and a number of attachments. The client-
specific validation makes use of this part of Commons and may be run
independently of the Services.

The point being, that we've modularized Commons and Services as
separate "products", which helps keep us sane: we don't have to
maintain branches of the "Commons" sources in two separate places.

It's still complicated because we have quite an involved repository
structure and because we have a parallel maven project for each of
our eclipse projects. But that's too involved to get into here.

// ben

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 14 15:29:52 2007