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ø <frode_at_tennebo.com>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2411442
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-26 17:49:45 CET