[p4] Repository Structure

Weintraub, David david.weintraub at bofasecurities.com
Tue Jul 18 14:06:21 PDT 2006

I wouldn't make a big difference between coding branches and release
branches since coding branches could end up becoming release branches.
Otherwise, it looks pretty good. Get the book Practical Perforce and
look at the way the book recommends to layout your depot in Chapter 8. I
would also use the naming conversion in the book Practical Perforce.
Plus, I'd avoid spaces in depot names whenever possible. Here's a quick
overview of Practical Perforce's recommendation:

Used as organizational ID. First letter capitalized, rest all lower

Code Line Groupings
This may or may not be 100% product lines. Depends exactly how you do
product releases. Basically it's a way of grouping common code. For
example, in Microsoft, MS-Word and MS-Excel are two distinct products,
but might be better organized as a single product line. Basically, if
you'd branch them together, they're a product line.

Also first letter uppercase, rest of word lower case.

Code Lines
These are your branches, and should be completely in uppercase. The book
makes the statement "There's no reason that a codeline's location in the
depot hierarchy *should* match its branching lineage. Nevertheless, the
fact that it doesn't can be a source of confusion to new Perforce
users.". This seems to indicate that REL1_PATCH2 should be in the REL1
directory. However, the example they give, they don't show this.
Instead, they flatten out the branching structure to make it all on the
same level.

All lower case letters

So, according to the book, your branching structure would look something
like this:


Keeping branching all at the same level does have an advantage, you know
that "p4 dirs //*/*/*" will list your branches, but I guess you could
also match your actual hierarchy too:


The problem with this is that it starts to get hard to distinguish a
branch vs. a file directory. For example, is "comp1" in
"//Autonomy/Prod_a/MAIN/comp1/..." a branch off of MAIN, or is it a
component located on the MAIN branch. I guess the all upper case will

I'd also think of the users' private branches as their own "Code Line
Grouping" instead of a branch off of a particular "Code Line Grouping"
because a user's private branch may or may not have anything to do with
other projects. We allow users to put their own private projects in
Perforce under their own private branch, and how they structure the
depot under their branch is really up to them. BTW, the name "TRUNK"
seems to be more popular than "MAIN" from what I've seen (although the
examples in the book uses MAIN). CVS and Subversion use TRUNK. ClearCase
uses MAIN.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Simon Timms
Sent: Tuesday, July 18, 2006 4:03 PM
To: perforce-user at perforce.com
Subject: [p4] Repository Structure

My company is looking at migrating some source code out of a perforce
repository arranged in a somewhat ad-hoc manner  into a new one which is
more inline with our development methodology.  We currently pursue a
mainline style of development with branches spun off for each release
(1.0, 1.1, 2.0,...) then branches off of them for patches (1.1p1, 2.0p3,
...) finally all actual development occurs in a developer private branch
(1.1p3_printPreview, 2.0p3_spellcheck).  Similarly nobody actually
develops on mainline but rather on a project or private branch which is
then merged into mainline.
I was thinking that at the top level my structure would look like
Product A
  |-->User Branches
  |------>user 1
  |------>user 2
  |------>user 3...
  |-->Project Branches
  |------>project 1
  |------>project 2...
  |-->Release Branches
  |--------->patch 1
  |--------->patch 2...
  |--------->patch 1
  |--------->patch 2 ... 
  |--------->patch 1
  |--------->patch 2...
Product B
Product C
So that main would contain, well, main.  User branches would contain
branches created by individual developers to work on small projects, be
they bug fixes for a patch branch or a minor enhancement to mainline.
Project branches would contain branches off of main which would be
worked upon by multiple developers. Release branches would contain the
source trees for each release and the subsequent patches for that
I was wondering if anybody would care to comment on the structure they
use or on the structure I've proposed.
perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list