Perforce Branching Specification Typo
Published by marco on
This article was originally published on the Encodo Blogs. Browse on over to see more!
At Encodo, we use the Perforce source control system. Recently, I created a branch specification in order to maintain bug fixes in a released product. See below:
//depot/branches/customername/versionnumber/projects/encodo/quino... //depot/projects/encodo/quino/...
Naturally, the next thing I did was to branch the files under //depot/projects/encodo/quino/ to the branch, using the P4V client. It displayed the new changelist, but did not update the statuses of the files therein (there were only a couple of hundred files). Strange. Stopping the command progress and refreshing manually also didn’t help and, within a few seconds, complaints rained in from coworkers that Perforce had stopped responding.
Even stranger.
I’ve been using Perforce for at least a dozen years and the server has never crashed or hung. That’s why you can let your support contract lapse for years without suffering any consequences.
A quick look into the processes list on the server showed several forks of the P4 server, each pulling as much of the CPU as it can. The processes quit after a while, but the commands never seemed to return. Ah, so it wasn’t even really hanging or crashed, it was just very, very busy with something. So, I restarted the server just to clear out the busy processes and tried to connect again; still no luck and both the P4V or P4Win clients could not retrieve the information they needed.
Since I had just integrated the files in that branch, I suspected it had something to do with those files, so I needed to revert them. To the rescue came the P4 command-line program, with which I could revert all files in the offending changelist without actually retrieving the status of those files. The changelist reverted successfully...and all the GUI clients were magically back online.
Curiouser and curiouser.
I branched the files again and ran into the exact same problem; at least it was reproducible. Instead of reverting the files, I just submitted them from the command line instead and went to look at the branch in P4V. It could display the files in the depot without any problem but, instead of all of the projects being in the //depot/branches/customername/versionnumber/projects/encodo/quino, as expected, the projects were one level higher, in the encodo folder, but each was prepended by the word “quino”.
Hmmm...those projects seem to have been branched incorrectly.
Before blaming Perforce for an error that had never, ever happened before, I took a look at the branch specification again and noticed that I’d introduced a small typo in the specification:
//depot/branches/customername/versionnumber/projects/encodo/quino[ ]... //depot/projects/encodo/quino[/]...The missing forward-slash is highlighted in green above. It’s relatively easy to miss, but once you see it, it’s obvious why the files and folders branched as they did. What’s not so obvious is why the Perforce server had such a tough time handling requests for the statuses of these files.[1] At any rate, should you run into a similar problem, check those branch specifications!
The Perforce clients have only gotten nicer over the years and the latest beta of P4V (June 2009) is the nicest yet, but it would be nice if they finally offered better support for their mapping format. The workspace definitions include a visual editor that is quite good, but a sanity check with “are you sure you mean what I think you mean?” checks for common errors would be a welcome addition.
[1]
The Perforce server version we use is slightly older---we let the support contract lapse because it is so stable and does what we need---so newer versions may not have this problem. This is the version we are using:
P4D/LINUX24X86/2006.1/104454 (2006/08/02)