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

Best practise for large projects with many product "sub-units"

From: Frode Tenneboe <frode_at_tennebo.com>
Date: Mon, 26 Oct 2009 16:40:52 +0100

Apologies if this has been answered before. I have studied the FAQ and
other best practises on the Net without getting much enlightenment.

At work we have a rather complex way of doing revisioning. However,
right now, due to time constraints, everything is relatively flat:

- SystemUnit
-- tags
--- R1A01
---- src
--- R1A02
-- trunk
--- src
---- libmmi
----- [files]
---- libcau
----- [files]
---- librlib
----- [files]

When I want a new revision I just tag the entire src directory, and
presto! This work because we at the moment only have this one product
in SVN. This will soon change. What I would like is to group the
[files] below each lib??? into several individual products which are
"tagged" individually (we use R1A, R1B, R2A...), for reuse in all our

According to the development process, we have at the top-level, three
distinct types of information needed to be version controlled:

1. Products
2. 3rd party products (3PP)
3. Projects

Normally, all development is done on the Base or Variant trees of our
products (in reality they are sub-products, but we just call them
products as there are many levels of sub-sub-subs...):

- Products
-- BaseA
--- FunctionUnitA
---- ProductA
----- tags
------ R1B
----- trunk
------ src
------- file1
------- file2
--- FunctionUnitF
---- ProductZ

-- BaseB
-- VariantA
--- FunctionUnitZ
---- ProductVariantA

We have around 75 base products grouped into various aspects (GUI,
communication, database, libraries, etc.) and some variants which depend
on which configuration (e.g. for different types of hardware) the
finished system contains.

In addition we have 3PP:

- 3PP
-- Solaris
-- Linux
--- GCC
---- tags
----- R1A
--- XRT
---- tags
----- R2A

(It will typically have no trunk as this is something we normally won't
touch ourselves.)

A Project consists of many base products, some variant products, several
3PP, and additionally a few project unique products:

- Projects
-- ProjectA
--- DeliverableA
---- ProjectProductA
----- trunk
------ src
------- file1
------- file2
----- tags
------ R1A
------- src
-------- file1
-------- file2
---- ProjectProductB
--- DeliverableB
---- ProjectProductC
-- ProjectB

Project unique products are typically specific configuration-files,
localisation, specific script-files, etc. At this level I also want to
tell the build/retrieve process which of the products I described above
the deliverables (CD/DVD) for this project should consist of, typically
something like:


ProductA R1A
ProductB R1B
ProductVariantA R1C
ProductVariantB R2A
ProjectProductA R1F
ProjectProductB R3C

The list will typically consist of ~80-85 such products with a total of
~3500 files.

Q1: Can the structure above effectively be used directly in SVN, both in
terms of performance (I'm guessing with sharding and packing performance
is less of an issue), but also in terms of administration from
developers, QA and CM people? Am I over-complicating things by
organising it like this?

Q2a: Can I maintain the flat structure as described on top in the
checked-out form for the developers, or must the complexity in the
versioned structure inevitably be reflected in the checked out

Q2b: Is there a middle-road, i.e. have the complex structure, but
dispense with the tags/[version]/ sub-hierarchy? E.g. instead of

ProductA/tags/R1A/src, or
ProductA/trunk/src, I can have


but which are updated/checked in to the correct structure (or in case of
a tag, I get the appropriate restrictions)?

Q2c: Can sparse checkouts help in any way?

Q3: Are there any other best practises to be considered?


Frode Tennebø <frode_at_tennebo.com>
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-26 17:49:45 CET

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