[p4] Repository Structure

Melissa Kacher mkacher at intrinsyc.com
Tue Jul 18 13:58:36 PDT 2006


You don't want to know the structure I actually use. (I inherited it.)
What I would like to use is exactly like you propose though. I makes
things easy to find for all of your users. It generates very little
"clutter" at the top levels of the depot. I like it.



Thanks,
Melissa


-----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 1:03 PM
To: perforce-user at perforce.com
Subject: [p4] Repository Structure

Hi,
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
  |
  |-->main
  |-->User Branches
  |------>user 1
  |------>user 2
  |------>user 3...
  |-->Project Branches
  |------>project 1
  |------>project 2...
  |-->Release Branches
  |------>1.0
  |--------->main
  |--------->patch 1
  |--------->patch 2...
  |------>1.1 
  |--------->main
  |--------->patch 1
  |--------->patch 2 ... 
  |------>2.0
  |--------->main
  |--------->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
release.
 
I was wondering if anybody would care to comment on the structure they
use or on the structure I've proposed.
 
Thanks,
Simon
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list