Perforce Notes

Changing source branches

To change what you've got from Perforce, simply modify the client specification via

p4 client

To switch branches, for instance, you have only to...

1. Run p4 client
2. Change the lone View: line in the client specification referring to the branch, e.g.: from "2011.6" to "Integration".
3. Exit p4 client with update.
4. Run p4 sync and, possibly p4 sync -f ... in places where you don't get exactly what you should. See "Forcing synchroniztion".

Templates

If you're excluding files like .png, .gif and .jpg from templates then you're removing most of the grief caused by the templates. The best solution is to prepare a shared directory for accessing templates, per office. At present, there is no working implementation of this.

Synchronization (updating)

This is a simple matter; you can update everything you've told Perforce is a concern to you (via p4 client) by just

p4 sync

If you're in a specific subdirectory, do this:

p4 sync ...

Forcing synchronization

When encountering build errors because of missing directories or files in the Snapfish sources, as long as local.properties is accurate, you may find the need to force synchronization.

Every time you perform synchronization, Perforce keeps track of what files (and versions of files) it thinks you have in your hos filesystem. The next time you synchronize, it compares what it thinks you have with what it has that's new and only sends down the items for which there is a delta. It does not examine your local filesytem to ascertain the truth.

This is calculated to lessen traffic on the wire and pressure on Perforce itself. You should not over-use this option with Perforce.

For this reason, some things will get out of sync, if rarely. If you're changing product branches frequently, this is likely to happen less rarely and you'll have to resort to forcing things.

The use of the -f option says, in effect, "Disregard what you think I have and give me everything my client specification says to give me."

To force resynchronization of everything, ...

p4 sync -f

If you're reacting to a build error and you understand where the disconnect is occurring, force resynchronization only of that portion that's necessary by going to the top of the filesystem you wish to resynchronize. This does just your current working directory and everything under it (assuming all these are under Perforce control).

p4 sync -f ...

Don't do this!!!

Okay, now that you've just read how to force synchronization, try never to use it. Daniel says he never has to (but then, he's just the little wizard, isn't he?). Here are some work-arounds to try first:

p4 diff -se                   # show unopened files that differ from the depot revision
p4 diff -se | p4 -x- edit     # fix files modified without being formally opened for edit
p4 diff -sd                   # show missing files
p4 diff -sd | p4 -x- sync -f  # force-sync missing files

Changing and committing files

Assuming you have synchronized files from a Perforce repository, you must tell Perforce that you wish to edit the file in order, later, to commit changes.

p4 edit filepath
//depot/somewhere/snapfish-core/blah/filepath - opened for edit

To commit a file you've edited, ...

p4 submit filepath

This will launch vi just as other source code-control software permitting you to explain the reason for committing the change.

Rules for committing

These depend on the repository owner, i.e.: your company. In the illustrations below you'll see my company's policy in the form of VID, PID, FF, etc.

Organizational policy can disallow a submission. This cannot be described here.

Adding new files

To add a file you've created, use

p4 add filepath
//depot/somewhere/snapfish-core/blah/filepath - opened for add

As soon as you like, you may commit it using p4 submit.

Deleting files

To delete a file currently under Perforce control, do

p4 delete //depot/<path>/foo.txt

Reverting changes

p4 status

There is no p4 status command, but this works for finding untracked files from the current working directory down:

find -type f ! -name '*~' -print0| xargs -0 p4 fstat 2>&1|awk '/no such file/{print $1}'

File status hints

There is no p4 status command as in cvs, svn and git. However, there are some commands that will show somewhat similar things about your filesystem copy to put you at ease. The responses shown demonstrates there is nothing to worry about.

p4 opened                         (Show all files opened for editing)
p4 diff -sa                       (Show opened files that are different from the depot, or missing)
File(s) not opened on this client.
p4 diff -sb                       (Show files opened for integration that have been resolved, but later modified)
File(s) not opened on this client.
p4 resolve -n                     (Show files in need of resolving)
No file(s) to resolve.

To find files you've failed to add (p4 add), use this. What comes out is a list of files that aren't tracked by Perforce—there will be many and many that should not.

find . -type f -print0 | xargs -0 p4 fstat > dev/null
./rsync/rsyncd.global.conf.bak - file(s) not in client view.

Who's editing a file?

When you open a file for editing using p4 edit, Perforce tells you who else has that file open via the format <user>@<workspace>. However, you likely will not know who this really is. The following command will dump the first few lines of his Perforce client configuration:

p4 user -o <user>

...where <user> is the first string before '@' in what Perforce echoed back.

Juggling multiple Perforce clients

You can have as many Perforce clients as you like. Normally your p4 client comes from the P4CLIENT environment variable. Those using multiple clients do the following.

Set P4CONFIG in your .bashrc to something like .p4config.

If you set this environment variable then instead of consulting environment for the Perforce client, user, password and port, Perforce will search your current working directory (and every directory above this) for a file named the same as the value of ${P4CONFIG}. If it finds such a file, it'll read that file for its configuration.

By way of example, to maintain two different clients you create two clients (make sure their root directories are different), then put a .p4config in the root of the client with the content

P4CLIENT=client-name

Create a separate client for every branch you wish to maintain or work with. When you're done with a branch, delete your client. Keep a separate client for shared resources, like modules, templates, dna_binaries, etc.

Daniel Rogers' .p4config files look like:

P4CLIENT=dsrogers-creamy

or

P4CLIENT=dsrogers-environment

Appendix: Some additional notes

Here are some brief notes on additional Perforce topics that might later be integrated into the article above. Most of these are from a session with Ravi (Vanga Palli Ravinder Kumar).

Merging