[p4] Depot Organization Thoughts

Gabor Maghera gmaghera at gmail.com
Mon Nov 10 15:43:37 PST 2008


We are converting our SCM system from CVS to Perforce and would like to
re-organize its structure during the move.  Currently, our CVS repository
has a number of top-level modules, and we branch a set of those based on the
scope of the project.

When moving to Perforce, I'd like to group these modules into codeline
groupings, so we can branch that grouping together as projects come up.
There is some coupling present between our products, which make this
difficult.  We have started the effort of decoupling, but it will be a while
before it is completed.

Let's say the converted CVS modules are mod_a, mod_b, MOD_C, and MOD_D.  The
products we offer are Prod_1 and Prod_2.  Prod_1 consists of mod_a and
mod_b; Prod_2 has the remaining two, MOD_C and MOD_D.

Prod_2 requires Prod_1, but they are on different delivery timetable.
Prod_2 is something analogous to a plug-in for Prod_1 (they have to be
compatible at run-time). Currently, releasing either product involves
deploying the other as well, even if the other one has had no changes (the
two products are deployed together shrink-wrapped).

Let's say there is need for a Prod_1 release, rel_1.  The project requires a
change in mod_d as well (which is under Prod_2).

If the Perforce depot structure is set up as:

//.../Prod_1/main/mod_a/...
//.../Prod_1/main/mod_b/...
//.../Prod_2/main/MOD_C/...
//.../Prod_2/main/MOD_D/...

1. We could create a codeline under Prod_1 that contains the three required
modules (mod_a, mod_b, and MOD_D).   We would end up with:

//.../*Prod_1/rel_1*/mod_a/...
//.../*Prod_1/rel_1*/mod_b/...
//.../*Prod_1/rel_1*/MOD_D/...

I am not sure I like having a module of Prod_2 branched into Prod_1.  We'll
be doing this often, and doing so offsets the benefit of grouping
codelines.  (We do this for third-party codelines, where I feel it is
acceptable.)

2. Branch each codeline under its own codeline grouping:
//.../*Prod_1/rel_1*/mod_a/...
//.../*Prod_1/rel_1*/mod_b/...
//.../*Prod_2/rel_1*/MOD_D/...

This scenario requires documenting the various codelines, which make up the
release, and bootstrapping one's workspace calls for a more complex client
workspace.

3. Create some namespace dedicated to releases:

//.../*Releases/rel_1*/mod_a/...
//.../*Releases/rel_1*/mod_b/...
//.../*Releases/rel_1*/MOD_D/...

This approach is perhaps the least appealing; there is really no connection
between lineage and location.  It feels like giving up one of the fortes
Perforce can give you, that visual cue of lineage based on location.

Another option would be not trying to group these modules before they are
truly decoupled. Then either branch everything all the time (and accept the
slight metadata cost) or branch only what is needed (requiring more up front
communication with the project owners).  I am leaning towards this option,
although it was initially the least favored one.

Any thoughts or ideas are appreciated,
Gabor


[image: Close] Read more >>   Options >>
[image: Visit Answers.com] <http://www.answers.com?initiator=FFANS>



More information about the perforce-user mailing list