[p4] Perforce newcomer - Need some help setting up my CM strategy (long post)

[Ildefonzo Arocha]

Hello all,

I am (still) in the process of evaluating P4 for our development team.
 I was able to convert our CVS to a P4 repository with success.  I
have been playing around with p4v, I feel a lost between so many
options.  To get started, the best is to explain to you guys our
current setup and starting from there you can (hopefully) provide some
suggestions.  I have developing for years, and I must say that the
development work-flow we use is not the best, its old-fashioned, and
mostly come from people used to work the old way, my goal is to start
shifting our processes to the current century, and P4 will be the
starting point, in order force things a little.

The company develops ERP applications, in some 4GL that almost no one
knows: Progress.  We have a standard version of our application, which
our customers buy, plus customizations made individually per customer
(yes, you cant start guessing about the mess!); mostly, these
customizations are made locally and then updated to our customer
sites, and sometimes made at customer sites via Citrix/RDP.

To keep this post as short as possible, I will use an example of our
directory structure:

/erp
/erp/in
/erp/gl
/erp/op

Now, as almost every software shop in the world, we have a development
version (head/trunk/main) and several branches; v1, v2 and v3.  When a
customer purchases our software he gets the latest stable version (say
v3 in this example). Some old customer have old versions of our
application and NOT ALL are thrilled about updating to the latest
version, because of fear, costs, etc, and also due to the fact that
our company cannot handle so frequent updates, because of lack of
proper CM and RM *blush*

So in this example: We got customers (a,b,c,d) with their
corresponding versions:

a -> v1
b -> v2
c -> v3
d -> v3

In order to implement our customizations, we create a subdirectory
called 'home_X', where 'X' represents a customer mnemonic we assign
(home_a for customer a, home_b for customer b, and so on).  so the
structure at our customer sites looks like:

/erp
/erp/in
/erp/gl
/erp/op
/erp/home_X
/erp/home_X/op
/erp/home_X/gl

You will notice that /erp/home, has only 'op' and 'gl', that is
because we create these directory as soon as changes are requested.
Which means, that at install time the '/erp/home' directory is empty.

Our central (local) directory structure, looks something like this:

/erp/v1/in
/erp/v1/gl
/erp/v1/op
/erp/v1/home_a/in

/erp/v2/in
/erp/v2/gl
/erp/v2/op
/erp/v2/home_b/op

/erp/v3/in
/erp/v3/gl
/erp/v3/op
/erp/v3/home_c/in
/erp/v3/home_d/gl

/erp/head
/erp/head/home_a/...
/erp/head/home_b/...
/erp/head/home_c/...
/erp/head/home_d/...

In case you are wondering why /erp/head/ has also the funny 'home_X'
directories, the reason is that we keep a copy of the customer changes
in our development environment, in order to 'try' to replicate bugs
against our current development version together with customizations
the customer has (even though mostly NEVER they are on the same
version level).  Sounds stupid heh? I think so also.

Ok, so now you got a picture about it, now, imagine our nightmare when
we find a bug on a core program that traces back to v1, all I can say
is that, I have become an Araxis expert, by spending probably about
20% of my weekly work time comparing source code (btw, Araxis is an
excellent tool!). It goes something like this:

- compare/update/merge head with v3/home
- compare/update/merge head with v3
- compare/update/merge head with v2/home
- compare/update/merge head with v2
- compare/update/merge head with v1/home
- compare/update/merge head with v1
- login into each customer site and perform an update and then compile
... yups, best case scenario: 2 to 3 hours, plugs lots of frustration.
 I hope the integration functions of p4 can leverage this problem.

Our CVS repository has branches on v1,v2 and v3.  However
customizations are stored in separate folders as explained above.  CVS
history is very important, reason why I converted the repository.

Questions:
I plan to leave in the p4 depot, branches v1,v2 and v3 as they are.  I
have 'temporally' deleted home_* directories, as these should be
branches of a given version branch and not a sub-directory. So, can I
branch from a branch?

Is this approach correct? If yes, then how would I manage our local
development environment? My idea would be to have on my workspace v3
for example and then only the changed files for customer a,b,c and d.
We have about 20.000 programs, its already bad enough to have 20.000 x
3 (number of versions) files, to multiply that by the amount of
customers: 20.000 x 3 x 4.  Note that our largest customer has changes
in about 500 programs, so branching all 500 programs and syncing them
to disk seems like overkill, is it possible to tell p4 only to copy to
my workspace only the changed files in a given branch?

Next round of questions:

Sometimes when our customers report a bug that we are not able to
replicate it in our environment, we login into our customers server,
make some fixes there and commit the changes back (sounds disgusting,
I know).  Therefore we will need a p4 client on our customers server.

a.) We are currently 5 developers, my guess is that developers that
login remotely count as 1 license

b.) Because not all 5 developers login simultaneously to a customer's
site (max 3 in the case of new customers during setup phases,
otherwise 1 on stable systems), how would I setup p4v for these
developers? Each would need its separate workspace? Or can I create
one special p4 user with only one workspace and let the developers
share the same workspace (remember this is a RDP/Citrix server)?

So, if you are still awake, I would really appreciate some
suggestions/hints about how to get along with this.  I have no
experience with p4, and not so much with CVS, however I worked >5
years with a SCM called Roundtable, and I know that careful planning
of the repository structure from the beginning is critical.

Thanks in advance,
Ildefonzo