http://public.perforce.com/wiki/P4DTI show an integration with bugzilla.

"The Perforce Defect Tracking Integration (P4DTI) connects your defect tracking system to Perforce, so that you don't have to switch between them and enter duplicate information about your work. It also links changes made in Perforce with defect tracker issues, making it easy to find out why a change was made, find the work that was done to resolve an issue, or generate reports relating issues to files or codelines."

Hello,

If you set $P4VFOLDER to where you installed the p4v.real file, this should work in a bash shell:

perl -e '$p4CLI=exec "p4 -V"; ' | grep -G "^Rev." | echo "P4CLI="`awk '{ print $2 }'`
perl -e '$p4D=exec "p4d -V"; ' | grep -G "^Rev." | echo "P4D="`awk '{ print $2 }'`
$P4VFOLDER/p4v.real -V | grep -G "^Rev." | echo "P4V="`sed 's/.*Client\///'`

This will result in:
P4CLI=P4/MACOSX104X86/2007.3/143793
P4D=P4D/DARWIN80X86/2007.3/152469
P4V=MACOSX104X86/2007.3/151553
or the like.

Notice the different method to get p4v's revision. Did you know the p4v.real can be run from the command line while p4v can not?

On Mac and Unix command line clients, you know, or learn shortly, that you can't "export" system variables from a script. But if you work on several projects, you will soon get tired of exporting various P4 required variables.

You can use the P4CONFIG to group several of these P4 variables together. But you still have to type
export P4CONFIG=<SOMEFILE>

Here is a more structured way....

If you do this below when it returns, you won't have any more aliases then when you started. Unless you put it in your .profile file!

export P4CONFDIR=~/p4config
# This sets aliases for P4
for P4C in `find $P4CONFDIR -type f`
do
alias p4c`basename -s .P4CONFIG $P4C`='export P4CONFIG='$P4C
done
# End of setting aliases for P4.

Now, what does this do? Well if for each P4 client you have you create a "client.P4CONFIG" file in the $P4CONFDIR, you can create a simple alias to change to your different clients.

http://farrago.sourceforge.net/privateBranch.html

is a good page on branching in P4. It does not help towards automating the use of a Private Branch, but covers the topic well.

http://kb.perforce.com/UserTasks/CodelinesAndBranching/BranchingCod..gin...

is the Perforce article on Branching. It doesn't discuss using branches for other activities such as private branching.

http://geekswithblogs.net/EltonStoneman/archive/2008/04/04/scripting-bra...

uses a tool from codeplex one has to download. Why? Anything a P4 client can do can be scripted in lowly batch files. Ant is better, especially with the exec target in 1.7.0. Yet, Perforce gives out API's for Perl, Python and C++. But, it does show a good plan for those who may want a starting point.

Basically, to branch code one needs to set up Perforce first.

1) Decide what kind of branch you want:

"The p5layer product attempts to implement Private Developer Branches (PDB's) on top of Perforce. It is currently in beta, but seems to work well enough under load."

This is a product in open source from Release Engineering, Inc. It has been around since 1999. http://www.releng.com/company.html

http://www.releng.com/p5layer.html

Having looked at the actual code, we could use a little touch up.
http://www.math.columbia.edu/~bayer/OSX/Perforce/

is a somewhat old but good source for XCode developers.

"p4files:
#! /bin/bash

find . -type f -print | egrep -v '^\./build/|\.DS_Store$|~\.nib' | rev | sort | rev "

or getting developers to keep the build folder out of the source!