doing CM for a consulting group?

MarkD.Andersonmda at MarkD.Andersonmda at
Mon Apr 13 21:03:21 PDT 1998

We are switching our development teams over to perforce.

But in addition to the development groups which produce a 
generic base product, we also have a consulting group,
that takes that base product and customizes it for every
customer. These customizations are mostly html, but other
config files as well, and sometimes custom shared libraries.

I'd appreciate recommendations on how to structure the
depot and what perforce features to use to support this.

The release time sequence is something like this:
 base A
    customer Bob
    customer Sally
    customer Mary
 base B
    customer Sally
    customer Fred
There might be a new base every few months, and meanwhile
a few dozen customer releases might be made, about half of
which are to new customers and half are to old customers.

In addition to the series of base products (which sometimes
must have patches, which sometimes must be customer-specific),
the set of customizations also evolves as well. That is, there
is a significant amount of code (well, html) that is re-used
on successive customers, and the consultants always start a new
customer by copying a previous one. That evolution (use of
html frames, edirects, etc.) is entirely orthogonal to the evolution
of releases that comes of development. (Not sure that made sense;
the point is that the customizations themselves have versions 
across customers.)

Some customizations must be made for every
customer, but there are some files managed by the consulting
group that change rarely and are shared across customers
(via symbolic links).

Currently there is *no* source control. There is just a big
single file system managed by the consulting group like this:
All consultants work on the very same set of files, in the same
workspace (and even as the same unix user). Snapshots of previous
releases to a customer (say, customer Sally) are just done with
tar balls.

This whole thing makes me queasy, but it does work pretty
efficiently for them. They never have to go back and fix
previous releases (they just fix the current one), and they
negotiate file sharing by just talking to each other.

Any recommendations for how to structure the depot, what
sort of view definitions, where to use branching and/or
labelling, etc.? Keep in mind that this has to be kept fairly
simple for this crowd.


- -mda

More information about the perforce-user mailing list