Helix Core — version control from Perforce — tracks, manages, and secures changes to all your digital assets, including large binary files. Scale your infrastructure, support your remote teams, and move faster.
Full Video Transcript
Branching code lines provides a method for developing and maintaining multiple separate groups of files related by purpose such as a new product or maintenance release. Here, we will use P4V to visualize a branch structure, move code between the branches, and quickly create a branch while preserving the relationships and version history of all the files.
If we take a look at the Revision Graph for ENut, we can visualize the branching structure of this project, specifically for this file. We see it started life in the main-dev code line before it was branched to rel1.0 where we are working currently. It was also branched into the rel1.5 codeline where it has seen some other updates. The rel1.0 code line is in a stable state so we want to move all the new code to the main-dev code line.
This operation is called an “Integrate” since we will be merging all the code changes from the selected files into their ancestor files in the main-dev code line. The advantage of integration over copying the files to another directory is that Perforce can track all changes and maintain history no matter how they traverse the code tree. We context-click on the rel1.0 branch folder and select Merge/Integrate.
First off, you are given two options on the method to integrate. The first option is perfect for simple integrations like this one where we are integrating changes from one whole branch to another and there is no difference in the branch structure. You simply select the source and target folders, and complete the operation.
The branch mapping method is useful if you have branches with different structures and want the files to traverse to the correct locations with each operation to and from the target branches.
You can see a summary of the submit options in this line, or you can toggle this section open to make changes. In this tab, you can elect how you want files to be resolved. We will elect to have a Safe Automatic Resolve, which will allow us to manually merge any conflicts if required.
The filter tab enables you to select the range of code evolution you want to integrate from several different elements including changelists that might contain a bug fix, or file revisions that contain a new feature.
The advanced tab provides several more specialized selections for branching and merging. If you want to permanently modify any options to be part of your normal workflow, you can click the Set Defaults button to bring up the P4V preferences.
For this integration, the source will be the whole rel1.0 branch, and we designate the target as the main-dev code line.
When you select Merge, a new pending changelist is formed. The system knows which files are different between the source and the target so only those files will be integrated. None of the files have a question mark by the icon indicating a conflict, so we perform a submit operation.
Now all the latest changes from the rel1.0 branch have been integrated into the main-dev code line and it is up to date.
Next, let’s create a new branch. We select the top level of the main-dev code line, and the Merge/Integrate command from the context menu again. We now have the same dialog box used for the integrate operation when we were moving code from the rel1.0 branch to main-dev. This time the target is going to be a brand new branch, rel2.0.
When you select Merge, a new pending changelist is created showing the addition of all the main-dev files into the new rel2.0 branch. We complete the Submit dialog and the changes are now in the depot.
Now an exact copy of the main-dev code line can be seen in the rel2.0 branch. The version numbers all restart at “1” since they’re relative to the branch they are in.
When Perforce creates a branch, it doesn’t actually generate another whole set of files on the server, it performs a “virtual copy” whereby a set of pointers is created to the most recent versions. No new files are created until there is a modification. With this method, you can branch quickly while conserving disk space and bandwidth.
A quick trip back to the revision graph tool shows the last few operations. We can see where we started with version 4 in the rel1.0 branch, then the integration of that code back into main-dev, and finally the creation of the rel2.0 branch.
Thanks for watching.