[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: early reflections on subversion methodology

From: Richard Taylor <r.taylor_at_eris.qinetiq.com>
Date: 2005-08-09 13:57:27 CEST

On Friday 05 August 2005 08:00, Brad Appleton wrote:
> Karan, Cem (Civ, ARL/CISD) wrote:
> >> The problem arises when you have a bunch related projects/products,
> >> or you have a set of "components" and you make multiple
> >> products/projects form those components. Each product has its own
> >> releases and uses a subset of "common" components as well as 1 or
> >> more components specific to that project. So release-numbers need
> >> to be tracked that are specific to each particular product, to the
> >> "core/common" set of components, and to the entire product-line as
> >> a whole.
> [...]
> > I see your point, as that is exactly the sort of thing that is going
> > on; we have a core set of utility 'libraries' which, if broken, cause
> > all the other projects to go haywire. The problem is that if you
> > have a per-group revision number, you need to be able to have other
> > groups be aware that they are working against a group.
> Yes. I would think they have to be aware of this even if they dont have
> a per-group revision number, because the revision of a component being
> used by the group that is developing it is likely to be different from
> the rev referred to by others that need it so they can build.
> I.e., if I
> > have groups A, B, and C, when I commit a revision of group A that
> > depends on B and C, I need to able to state that A depends on B::234
> > and C::38, and have that built into the commit command. If you don't
> > do this, then it becomes more of a problem then a solution.
> That's the part I think one ends up having to do anyway (even with
> repo-wide revisions).
> ClearCase/UCM has an interesting notion of "Composite Baselines". It's
> like a "Label of Labels" (or "Tag of Tags") where the "Composite" Tag is
> really a reference to the other tags that make up the whole "assembly".
> It gets even more interesting when you have the notion of "LATEST" (or a
> dynamic/floating tag). so if I had a composite "LATEST_SYSTEM_BUILD" tag
> that consisted of "LATEST_COMPONENT1_BUILD" and
> "LATEST_COMPONENT2_BUILD" - then when I "promote" a components flaoting
> label to the new latest component build, the "composite" tag picks up
> the new stuff :-)

We manage all of this with svn:externals. We create a "meta-project" that has
its own trunk/branch/tags directories and consists of mostly just
svn:externals referencing other components. Each component has its own
trunk/branches/tags directories and the svn:externals in the meta-project
refer to trunk/branch/tag directories of the subcomponents as appropriate.

Using this model you can organise any combination of subcomponents and version
all the releases of the meta-project. It can also be done with out any
recourse to revision numbers at all. You just have to be scrupulous about
sticking to a consistent repos layout and release management process for all


B009 Woodward Building
St. Andrews Road
Worcs WR14 3PS
Jabber: RichardTaylor@jabber.org
PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7DA9FD9
Key fingerprint = D051 A121 E7C3 485F 3C0E  1593 ED9E D868 A7DA 9FD9

  • application/pgp-signature attachment: stored
Received on Tue Aug 9 14:04:11 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.