[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