[p4] Depot Organization Thoughts

Gabor Maghera gmaghera at gmail.com
Tue Nov 11 15:59:11 PST 2008


Thank you for the answer.

(The stray * characters in the depot paths were due to having composed the
message with rich formatting, trying to emphasize the differences between
the approaches, making part of the path bold.)

Gabor

On Tue, Nov 11, 2008 at 2:02 PM, Robert Cowham <robert at vizim.com> wrote:

> Some thoughts below.
>
> > 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/...
>
> (What meaning do you attach to * above?)
>
> > 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.)
>
> As a branching structure it looks OK, although life is complicated if
> Prod_2
> has a version of Mod_D which is not the same as the version of Mod_D
> included in Prod_1 which itself is included in Prod_2.
>
> > 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.
>
> As the number of people goes up, the more communication overhead it is to
> keep workspaces updated - thus the more I tend to prefer composing by
> branching where 1 person makes the decision and does it, and everyone else
> just re-syncs.
>
> > 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.
>
> I don't think it as clear cut as that.
>
> > 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.
>
> Looks like you are considering the right things. There is usually no one
> best answer.
>
> The key is to identify all the scenarios you need to support and to test
> different structures against this requirement. This is what you are doing.
>
> Robert
>
>



More information about the perforce-user mailing list