[p4] Repository Structure

Robert Cowham robert at vaccaperna.co.uk
Tue Jul 18 15:20:49 PDT 2006


As Steve says, encourage users to have separate branches under their
personal areas, or to use task branches - if there is any staff turnover you
can lose checked in work because it was somewhere in a users branch and not
merged back.

I would always go for leading zeros, e.g. 01.00, so that things sort nicely,
especially when you get to double digits.

Other tips:
http://www.robertcowham.com/blog/scm/p4_branch_depot_structure.html

Basically I think you're on a good track.

Regards
Robert

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Simon Timms
> Sent: 18 July 2006 21:03
> 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