Perforce 2007.3 P4 User's Guide
<< Previous Chapter
Resolving Conflicts
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Defect Tracking

Chapter 6
Codelines and Branching

This chapter describes the tasks required to maintain groups of files in your depot. The following specific issues are addressed:

This chapter focuses on maintaining a software code base, but many of the tasks are relevant to managing other groups of files, such as a web site. For advice about best practices, see the white papers on the Perforce web site.

Basic terminology

To enable you to understand the following sections, here are definitions of some relevant terms as they are used in Perforce.

Term
Definition

branch

(noun) A set of related files created by copying files, as opposed to adding files. A group of related files is often referred to as a codeline.

(verb) To create a branch.

integrate

To create new files from existing files, preserving their ancestry (branching), or to propagate changes from one set of files to another (merging).

merge

The process of combining the contents of two conflicting file revisions into a single file, typically using a merge tool like P4Merge.

resolve

The process you use to reconcile the differences between two revisions of a file. You can choose to resolve conflicts by selecting a file to be submitted or by merging the contents of conflicting files.

Organizing the depot

You can think of a depot as a top-level directory. Consider the following factors as you decide how to organize your depot:

A basic and logical way to organize the depot is to create one subdirectory (codeline) for each project. For example, if your company is working on Jam, you might devote one codeline to the release presently in development, another to already-released software, and perhaps one to your corporate web site. Your developers can modify their client views to map the files in their project, excluding other projects that are not of interest. For example, if Earl maintains the web site, his client view might look like this:

//depot/www/dev/... //earl-web-catalpa/www/development/...
//depot/www/review/... //earl-web-catalpa/www/review/...
//depot/www/live/... //earl-web-catalpa/www/live/...

And Gale, who's working on Jam, sets up her client view as:

//depot/dev/main/jam/... //gale-jam-oak/jam/...

You can organize according to projects or according to the purpose of a codeline. For example, to organize the depot according to projects, you can use a structure like the following:

//depot/project1/main/
//depot/project1/release 1.0/
//depot/project1/release 1.1/

Or, to organize the depot according to the purpose of each codeline, you can use a structure like the following:

//depot/main/project1/
//depot/main/project2/
//depot/release1.0/project1/
//depot/release1.0/project2/
//depot/release2.0/project1/
//depot/release2.0/project2/

Another approach is to create one depot for each project. Choose a structure that makes branching and integrating as simple as possible, so that the history of your activities makes sense to you.

Branching

Branching is a method of maintaining the relationship between sets of related files. Branches can evolve separately from their ancestors and descendants, and you can propagate (integrate) changes from one branch to another as desired. Perforce's Inter-File BranchingTM mechanism preserves the relationship between files and their ancestors while consuming minimal server resources.

To create a branch, use the p4 integrate command. The p4 integrate command is also used to propagate changes between existing sets of files. For details about integrating changes, refer to "Integrating changes" on page 75.

When to branch

Create a branch when two sets of files have different submission policies or need to evolve separately. For example:

Solution: create a release branch by branching the development codeline. When the development codeline is ready, it is integrated into the release codeline. Patches and bug fixes are made in the release code and integrated back into the development code.

Solution: create a Macintosh branch from the existing UNIX code. These two codelines can evolve separately. If bugs are found in one codeline, fixes can be integrated to the other.

One basic strategy is to develop code in //depot/main/ and create branches for releases (for example, //depot/rel1.1/). Make release-specific bug fixes in the release branches and, if required, integrate them back into the //depot/main/ codeline.

Creating branches

To create a branch, use the p4 integrate command. When you create a branch, the Perforce server records the relationships between the branched files and their ancestors.

You can create branches using file specifications or branch specifications. For simple branches, use file specifications. For branches that are based on complex sets of files or to ensure that you have a record of the way you defined the branch, use branch specifications. Branch specifications can also be used in subsequent integrations. Branch specifications also can serve as a record of codeline policy.

Using branch specifications

To map a set of files from source to target, you can create a branch specification and use it as an argument when you issue the p4 integrate command. To create a branch specification, issue the p4 branch branchname command and specify the desired mapping in the View: field, with source files on the left and target files on the right. Make sure that the target files and directories are in your client view. Creating or altering a branch specification has no effect on any files in the depot or client workspace. The branch specification merely maps source files to target files.

To use the branch specification to create a branch, issue the p4 integrate -b branchname command; then use p4 submit to submit the target files to the depot.

Branch specifications can contain multiple mappings and exclusionary mappings, just as client views can. For example, the following branch specification branches the Jam 1.0 source code, excluding test scripts, from the main codeline.

Branch:   jamgraph-1.0-dev2release

View:
    //depot/dev/main/jamgraph/... //depot/release/jamgraph/1.0/...
    -//depot/dev/main/jamgraph/test/... //depot/release/jamgraph/1.0/test/...
    //depot/dev/main/bin/glut32.dll //depot/release/jamgraph/1.0/bin/glut32.dll

To create a branch using the preceding branch specification, issue the following command:

To delete a branch specification, issue the p4 branch -d branchname command. Deleting a branch specification has no effect on existing files or branches.

As with workspace views, if a filename or path in a branch view contains spaces, make sure to quote the path:

Using file specifications

To branch using file specifications, issue the p4 integrate command, specifying the source files and target files. The target files must be in the client view. If the source files are not in your client view, specify them using depot syntax.

To create a branch using file specifications, perform the following steps:

  1. Determine where you want the branch to reside in the depot and the client workspace. Add the corresponding mapping specification to your client view.

  2. Issue the p4 integrate source_files target_files command.

  3. Submit the changelist containing the branched files. The branch containing the target files is created in the depot.

      He issues the following command to create the branch:

      Finally, he issues the p4 submit command, which adds the newly branched files to the depot.

Integrating changes

After you create branches, you might need to propagate changes between them. For example, if you fix a bug in a release branch, you probably want to incorporate the fix back into your main codeline. To propagate selected changes between branched files, you use the p4 integrate command, as follows:

  1. Issue the p4 integrate command to schedule the files for resolve.

  2. Issue the p4 resolve command to propagate changes from the source files to the target files.

    To propagate individual changes, edit the merge file or use a merge program. The changes are made to the target files in the client workspace.

  3. Submit the changelist containing the resolved files.

    p4 integrate //depot/release/jam/2.2/src/Jambase //depot/dev/main/jam/Jambase

To run the p4 integrate command, you must have Perforce write permission on the target files, and read access on the source files. (See the Perforce System Administrator's Guide for information on Perforce permissions.)

By default, a file that has been newly created in a client workspace by p4 integrate cannot be edited before being submitted. To edit a newly integrated file before submission, resolve it, then issue the p4 edit command.

If the range of revisions being integrated includes deleted revisions (for example, a file was deleted from the depot, then re-added), you can specify how deleted revisions are integrated using the -d or -D flags. For details, refer to the Perforce Command Reference.

Integrating using branch specifications

To integrate changes from one set of files and directories to another, you can use a branch specification when you issue the p4 integrate command. The basic syntax of the integrate command when using a branch specification is:

Target files must be mapped in both the branch view and the client view. The source files need not be in the client view. If you omit the tofiles argument, all the files in the branch are affected.

To reverse the direction of integration using a branch specification, specify the -r flag. This flag enables you to integrate in either direction between two branches without requiring you to create a branch specification for each direction.

Integrating between unrelated files

If the target file was not branched from the source, there is no base (common ancestor) revision. To integrate between unrelated files, specify the -i flag. Perforce uses the first (most recently added) revision of the source file as its base revision. This operation is referred to as a baseless merge.

Integrating specific file revisions

By default, the integrate command integrates all the revisions following the last-integrated source revision into the target. To avoid having to manually delete unwanted revisions from the merge file while editing, you can specify a range of revisions to be integrated. The base file is the common ancestor.

Reintegrating and reresolving files

After a revision of a source file has been integrated into a target, that revision is usually skipped in subsequent integrations with the same target. To force the integration of already-integrated files, specify the -f flag when you issue the p4 integrate command.

A target that has been resolved but not submitted can be resolved again by specifying the -f flag to p4 resolve. When you reresolve a file, yours is the new client file, the result of the original resolve.

Integration reporting

The following reporting commands provide useful information about the status of files being branched and integrated. Note the use of the preview flag (-n) for reporting purposes.

To display this information
Use this command

Preview of the results of an integration

p4 integrate -n [filepatterns]

Files that are scheduled for resolve

p4 resolve -n [filepatterns]

Files that have been resolved but not yet submitted.

p4 resolved

List of branch specifications

p4 branches

The integration history of the specified files.

p4 integrated filepatterns

The revision histories of the specified files, including the integration histories of files from which the specified files were branched.

p4 filelog -i [filepatterns]

Using labels

A Perforce label is a set of tagged file revisions. For example, you might want to tag the file revisions that compose a particular release with the label release2.0.1. In general, you can use labels to:

Labels and changelist numbers both refer to particular sets of file revisions but differ as follows:

Changelists are suitable for many applications that traditionally use labels. Unlike labels, changelists represent the state of a set of files at a specific time. Before you assume that a label is required, consider whether simply referring to a changelist number might fulfill your requirements.

Tagging files with a label

To tag a set of file revisions (in addition to any revisions that have already been tagged), use p4 tag, specifying a label name and the desired file revisions.

For example, to tag the head revisions of files that reside under //depot/release/jam/2.1/src/ with the label jam-2.1.0, issue the following command:

To tag revisions other than the head revision, specify a changelist number in the file pattern:

Only one revision of a given file can be tagged with a given label, but the same file revision can be tagged by multiple labels.

Untagging files

You can untag revisions with:

This command removes the association between the specified label and the file revisions tagged by it. For example, if you have tagged all revisions under //depot/release/jam/2.1/src/... with jam-2.1.0, you can untag only the header files with:

Previewing tagging results

You can preview the results of p4 tag with p4 tag -n. This command lists the revisions that would be tagged, untagged, or retagged by the tag command without actually performing the operation.

Listing files tagged by a label

To list the revisions tagged with labelname, use p4 files, specifying the label name as follows:

All revisions tagged with labelname are listed, with their file type, change action, and changelist number. (This command is equivalent to p4 files //...@labelname).

Listing labels that have been applied to files

To list all labels that have been applied to files, use the command:

Using a label to specify file revisions

You can use a label name anywhere you can refer to files by revision (#1, #head), changelist number (@7381), or date (@2003/07/01).

If you omit file arguments when you issue the p4 sync @labelname command, all files in the client workspace view that are tagged by the label are synced to the revision specified in the label. All files in the workspace that do not have revisions tagged by the label are deleted from the workspace. Open files or files not under Perforce control are unaffected. This command is equivalent to p4 sync //...@labelname.

If you specify file arguments when you issue the p4 sync command (p4 sync files@labelname), files that are in your workspace and tagged by the label are synced to the tagged revision.

Deleting labels

To delete a label, use the following command:

Deleting a label has no effect on the tagged file revisions (though, of course, the revisions are no longer tagged).

Creating a label for future use

To create a label without tagging any file revisions, issue the p4 label labelname command. This command displays a form in which you describe and specify the label. After you have created a label, you can use p4 tag or p4 labelsync to apply the label to file revisions.

Label names cannot be the same as client workspace, branch, or depot names.

For example, to create jam-2.1.0, issue the following command:

The following form is displayed:

Label:    jam-2.1.0
Update:    2005/03/07 13:07:39
Access:    2005/03/07 13:13:35
Owner:    earl
Description:
     Created by earl.
Options:     unlocked
View:
     //depot/...

Enter a description for the label and save the form. (You do not need to change the View: field.)

After you create the label, you are able to use the p4 tag and p4 labelsync commands to apply the label to file revisions.

Restricting files that can be tagged

The View: field in the p4 label form limits the files that can be tagged with a label. The default label view includes the entire depot (//depot/...). To prevent yourself from inadvertently tagging every file in your depot, set the label's View: field to the files and directories to be taggable, using depot syntax.

Using static labels to archive workspace configurations

You can use static labels to archive the state of your client workspace (meaning the currently synced file revisions) by issuing the p4 labelsync command. The label you specify must have the same view as your client workspace.

For example, to record the configuration of your current client workspace using the existing ws_config label, use the following command:

All file revisions that are synced to your current workspace and visible through both the client view and the label view (if any) are tagged with the ws_config label. Files that were previously tagged with ws_config, then subsequently removed from your workspace (p4 sync #none), are untagged.

To sync the files tagged by the ws_config label (thereby recreating the workspace configuration), issue the following command:

Using automatic labels as aliases for changelists or other revisions

You can use automatic labels to specify files at certain revisions without having to issue the p4 labelsync command.

To create an automatic label, fill in the Revision: field of the p4 label form with a revision specifier. When you sync a workspace to an automatic label, the contents of the Revision: field are applied to every file in the View: field.

Preventing inadvertent tagging and untagging of files

To tag the files that are in your client workspace and label view (if set) and untag all other files, issue the p4 labelsync command with no arguments. To prevent the inadvertent tagging and untagging of files, issue the p4 label labelname command and lock the label by setting the Options: field of the label form to locked. To prevent other users from unlocking the label, set the Owner: field. For details about Perforce privileges, refer to the Perforce System Administrator's Guide.


Perforce 2007.3 P4 User's Guide
<< Previous Chapter
Resolving Conflicts
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Defect Tracking
Please send comments and questions about this manual to [email protected].
Copyright 2005-2007 Perforce Software. All rights reserved.
Last updated: 11/29/07