On my latest project we're using Perforce for source control and my first tasks have been to set up CruiseControl.Net for continuous integration, and define the branching strategy to use. I'm new to P4 and wanted to document the learning curve - the next few posts will cover what I've put in place.
Being an SCM with all the usual features, Perforce naturally has a different set of terminology for all the usual concepts. The repository on the server is the depot
and the local dev repository is a workspace
. The workspace is also known as a client view
, which has a mapping to the depot that looks like:
- meaning all files within the ProjectX node of the depot are mapped to the ProjectX node of a.developer's workspace.
Views are also used in branching and labelling, which I'll cover more in the branch strategy post.
Perforce with CC is a well trodden path, but for reference the sourceControl project node is:
The client node specifies the workspace to connect to, and the view specifies the exact mapping for the project. That view is used to monitor the folder for changes, and if you specify autoGetSource and applyLabel, they'll run over all the files in the view. This allows you to set up one workspace for the build server which has a view over the entire depot, and then specify different views for each build project.
There are various warnings saying that Perforce doesn't work with purely numeric labels, but in version 2007.3 that seems fine. With the standard iteration labeller for every successful build CC will create a label in Perforce and label every file in the specified view.
Perforce seems like a nice SCM, with excellent cross-platform support. The licensing model allows you to download and use it for free with up to 2 users and 5 workspaces: http://www.perforce.com/perforce/loadprog.html