[p4] Script to ship resolves?

Weintraub, David david.weintraub at bofasecurities.com
Mon Jul 24 12:43:37 PDT 2006

I solve problems like this by repointing the "Finger o' Blame" to
someone else.

The "Finger 'o Blame" is my colorful metaphor for helping establish who
is ultimately responsible for a particular process -- especially if
something goes terribly wrong. I use it as a tongue in cheek way to help
point out who really should be responsible for a particular process.

For example, right now, you -- who admittingly is not the folk "with the
context knowledge" for doing the merge -- is responsible for doing the
merge. If something goes wrong in the process, the Finger o' Blame" will
point to you. The idea is to repoint that the Finger 'o Blame to the
person who is really responsible for the process.

So, let's look at the way things stand:

* Who has the knowledge of when work on the branches is completed and
ready to merge back into the main line development?

* Who has the knowledge to resolve conflicts if they happen?

* Who has the ability to run the unit tests necessary after the merge
takes place and BEFORE the code is checked in to make sure the merge
didn't break anything?

The answer to all of the above is the developer, so merging should
really be the job of the developer and not the configuration manager. We
reposition the Finger 'o Blame to point away from you and towards the
developer. Now, we can go back to playing solitaire on our PC.

All right, it isn't that simple. CM's job is also to provide the tools
necessary to allow everyone to do their job. You do need to provide a
tool that lets the developer do the merge as cleanly as possible. Having
the developer manually create a client and run the various Perforce
commands to do the merge and resolve is prone to error. You have to help
automate this process.

Your solution #2 is pretty close to what should be happening. Except,
you shouldn't provide a script to write a script, but simply write a
script that developers will help them through the merge and resolve
process. Writing a script that the developers can directly run for the
merge and resolve process instead of attempting to write meta-scripts to
do the job for the developer is a much easier job.

The developers will already be logged into Perforce, so that takes care
of the logging in problem. Take advantage of Perforce's features, and
the other concerns you have will disappear. For example, I would use a
P4CONFIG file to set the developer's environment. In fact, I insist that
all developers set their P4CONFIG environment variable to ".p4rc". You
don't have to be that strict, but any script you write for developers
should refuse to run unless P4CONFIG is set and doesn't contain any
directory separators. That way, you can create a P4CONFIG file that sits
in the root of the working directory, and that will automatically point
the developers do the correct P4PORT, P4CLIENT, and P4USER. This
eliminates the problem of setting and unsetting the developer's

Have your script create a new client, but to simplify your job, make
sure that the Root directory doesn't already exist, and that no other
Perforce clients use that as a root directory. That simplifies the issue
of two Perforce clients using the same directory, and guarantees that
the directory is clean.

In your script:

1). Ask for the "From" branch, the "To" branch, and a marker on the
"From" branch you're using as a merge from point (or HEAD if none is
selected). This could be a label, changeset, or date/time specification.

2). Create a new temporary Perforce client (I'd use a name like
TMP_$USERID_$GUID where GUID is a global unique identifier). Creating
the client is fairly straight forward. Since the developer is running
the script, they'll own the client. If that client already exists,
either fail the script, or find a new name.

3). Create the Client's root directory, go into the client directory,
and create the P4CONFIG file. Because of the P4CONFIG file, your client
will be setup correctly.

4). Run the "p4 sync //...@$branchPoint where $branchPoint is the marker
on the from branch the developer want to branch from (it could be HEAD,
a changeset, label, or a date/time spec).

5). Run "p4 integrate $fromDir/...@<$branchPoint> $toDir/...". Again,
the "$branchPoint" is the marker on the from branch where the developer
wants to branch from.

6). Run "p4 sync" which "schedules" the resolve.

7). Finally, run the "p4 resolve" command for the developer. The resolve
command will prompt the developer for all changes. You could have
parameters in your script that automatically passes certain parameters
to the "p4 resolve command". My experience so far is that developers
don't trust automated merges, and will prefer to manually make the
needed changes and then simply mark the files as resolved. Your script
will have to help with this process.

8). When the developer finishes, they'll run "p4 sync" to finish the

Of course, you still have the temporary client and its root directory
sitting there. There are a few things you can do:

* Give the developer a special "p4resolved" command. This command can
mark all files that haven't been resolved as resolved, do the submit,
and then deletes the Perforce client and its associated root directory.

* Run a command to look for temporary clients that are over a certain
age, and either automatically deletes them, or emails the owner to
delete them.

* Have a post-submit trigger that if the name of the client begins with
"tmp_", emails you to let you know to delete the client and also
emails the client's owner to remind them that they can delete the
client's root directory.

I think the first one has its advantages, but then developers must
remember to run "p4resolve" and not "p4 submit" when they are ready to
submit their changes. The last one is nice because it uses the standard
"p4 submit", and simply reminds you and the developer to do the clean
up. This will allow you and the developer to let the Perforce client and
its associated root directory hang around for a few days before

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Brad Holt
Sent: Monday, July 24, 2006 1:05 PM
To: perforce-user at perforce.com
Subject: [p4] Script to ship resolves?


Like most of you, we've got piles of branches that are getting
integrated back and forth every day.  I've got it scripted now so that
the changes get integrated over by-changelist, which is an improvement.
However, it still eats up way too much of my time when trying to take
care of the resolve conflicts.  Doing them all myself is time consuming,
and dreary, plus I'd rather have the folks with the context knowledge
tackling them.

So what I need to write is some sort of script that will bundle up the
conflicted file revisions (the theirs, yours, and base) and send them
off.  I've done something similar in the past, but it was unfinished and
a bit sloppy.  This must be something that many of you have to wrestle
with, so I've been a bit surprised that I haven't seen it in the
discussion previously.  So I'm probably just missing something.

I can see this being done in one of 2 ways:
- either -

1. The resolve conflict is shipped out as just the 3 files attached in
an email for the dev to resolve.  They take care of it and send me back
the result which I then slot into my pending resolve and "Accept Merged"
(unless they find that I can take the straight "Yours" or "Theirs").  I
have a sloppy version of this now, but it is not automated to the point
that I need.  Providing the target and source is simple enough (though
there is a danger that the target#head may vary between the time I send
the mail out and get the reply), but getting the base/common ancestor is
more of a problem.  Perhaps "integrate -o" would work to derive this?
Maybe "merge3"?

- or -

2. I have my script write a script that gets sent to the dev.  This
script would create a temporary client rooted in %TEMP% and would then
run the integration to populate a changelist which they could then
resolve and submit.  Sounds reasonable, but I can see problems with it
in the details (cleaup of temp client, resetting dev's defaults,
password stuff, notification that they have finished, etc.)

Any of you lot written anything like this?  I try to stick to perl as
everyone here has to have it on their boxes.  I'll take whatever ideas
or suggestions you have as well.

Thanks much.


perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list