You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Frode Tenneboe <fr...@tennebo.com> on 2009/10/26 15:40:52 UTC
Best practise for large projects with many product "sub-units"
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
--
Frode Tennebø <fr...@tennebo.com>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411442
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Best practise for large projects with many product "sub-units"
Posted by petermity <6t...@dea.spamcon.org>.
Frode Tenneboe <fr...@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@subversion.tigris.org].