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

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

From: petermity <6t12-n6js_at_dea.spamcon.org>
Date: Wed, 11 Nov 2009 00:46:40 -0800

Frode Tenneboe <frode_at_tennebo.com> wrote:

>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
>-----libmmi
>:
>--- 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
>products.
>
>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:
>
>DeliverableA:
>
>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
>structure?
>
>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
>
>ProductA/src
>
>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

You didn't mention Externals Definitions - this might be part of the
solution to organizing and using SVN with your software. For instance 3PP
and libs could be separate independent SVN projects (repositories). Then
a project and/or product can pull pieces of those in as needed via
externals.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416424

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-11 09:48:33 CET

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.