Updated: 2005-11-29 - see link to scripts.
Updated: 2006-03-16 - some clarifications and link to Miki Tebeka's scripts

A common branching pattern is to have mainline and then task branches where work is done and then "published" by merging to the mainline as shown in Figure 3 of the article Building for Success.

In perforce the "publish" and the "catchup" are both performed by using the integrate command, typically with a branch spec. For example, you might have a branch spec

Branch:	task/fred
View:
	//depot/main/... //depot/task/fred/...

The key thing is that Fred should "catchup" before doing the "publish". This is so that the more risky merging is done in his task branch and not in the mainline. When doing the merge Fred should be bringing all changes by other people in the project into his branch and with the publish he should just be able to copy his code into the mainline.

There are several ways to achieve this:

• Education - tell Fred what to do and rely on him doing it - so what happens if he doesn't - can you "persuade" him not to?!
• Don't give Fred write access to the mainline (e.g. via protections or a trigger), and instead have the integration team do it. The problem then being that the integration team may not know the code as well as Fred and are perhaps more likely to make a mistake.

The basic way of detecting in Perforce whether a catchup has been done is to do a preview integrate from main to task/fred and check that nothing needs to be done, so check for no results from:

p4 integrate -n -b task/fred

If the above produces no results then proceed to do the publish:

p4 integrate -r -b task/fred
p4 resolve -as

The key step is that the "resolve -as" (safe automatic merge), resolves as many files as it can. It looks to see if their are only "theirs" (source) diff chunks or "yours" (target) diff chunks and will select the theirs or yours file appropriately. (Note that "theirs" and "both" or "yours" and "both" are also processed in the same way). The key point is that if there are "theirs" and "yours" (or "conflict") diff chunks, then safe automatic resolve will not process that file.

Of course having done the automatic resolve and with the changed files sitting in our client workspace it is usually a good idea to do things like a build and smoke test - there's not a whole heap of trust otherwise...

Thus, in our script we can check for anything not safely resolved automatically (resolve -n shows what still needs to be resolved).

p4 integrate -r -b task/fred
p4 resolve -as
p4 resolve -n
if any results from above command then exit with error

build
if any problems then exit with error

run smoke tests
if any problems then exit with error

If no errors at this point we are ready to submit.

There are some extra wrinkles to this:

• the "resolve -as" may validly not work if you have done a merge with edit during the catchup ("edit from" in the terminology from p4 integrated). You need to detect such situations and do a "resolve -at" to copy them over.
• as soon as one person has done a publish then all other branches will require to do a catchup to pull it in - this means publishes are going to become serial
• there is a window during which the publish is being performed when someone else might sneak in and do a publish thus meaning you need to do a catchup - consider a simple "locking" strategy to prevent this.

Note that the build and smoke test steps need to take an appropriate amount of time. If it takes hours to do them then the process is unlikely to work. Thus a few minutes or tens of minutes is likely to be the limit - this may mean cutting down on the number of tests that are executed - but that is usually OK. Apply judgement!

Although at the last point you might think it would be a brave person to do the submit automatically in a script! It's probably a good idea to do things like run diffs and give a visual once over before finally checking in, but it should be a pretty easy decision at this point.

In terms of automating the above, I can heartily recommend the various scripting languages with built-in calls to the Perforce API: Ruby, Python and Perl. Getting the results of a command is easy, and exceptions allow you to make error handling pretty easy as well.

Very brief examples of scripts designed to perform the above check in Python and Ruby are now available online. Note they are designed to be run from Custom Tools menu in p4v/p4win. Please note that Miki Tebeka has kindly published more production quality script implementations in python including a GUI front end. He also includes an example of an installer to automate installation of tools for p4win and p4v - check them out. Thanks Miki!

p.s. The above works for any codeline for which you have responsibility for accepting changes - it doesn't have to be a mainline - it can be a subsidiary integration line with third parties contributing, or team members "proposing" changes. You could automate the script and put it on an intranet page - let people try it out, and if successful then have changelists auto-checked in.