Upgrading a Perforce Server

How do I upgrade to a new version of the Perforce Server?

To run a newer version of the Perforce Server, your Perforce license must be current. You will not be able to upgrade to a Perforce Server version that is dated beyond your license expiry. This is not a problem if you are running an unlicensed installation, which is limited to two users and two (2004.2 and earlier) or five (2005.1 and later) client workspaces. An unlicensed installation is sometimes used for evaluating Perforce.

Please be sure to read the P4D Release Notes before proceeding with your upgrade to be aware of the latest changes to the current Perforce Server version.

In general, you cannot downgrade a Perforce Server. It is therefore imperative that you create a checkpoint prior to upgrading to a new version.

In general, you can upgrade from any previous version of the Perforce Server. For example, you can upgrade directly from a 2007.2 version to 2009.2. There is no need to perform any incremental upgrade; the built-in upgrade process automatically performs the incremental Perforce database updates and reports them.

Assuming you have a good license (or are running an unlicensed two user/two or five client workspace installation), and you are upgrading from a recent release, Perforce Server upgrading can be as simple as performing the following steps:

Stop the current p4d.Make a checkpoint of the database by issuing the following command, where "root" is the directory in which your db.* files are located:p4d -r root -jcBack up the versioned files.Download the new p4d executable. Note: On Windows, download the perforce.exe or perforce64.exe installer.
Install the new p4d in the desired location. Note: On Windows, run the perforce.exe or perforce64.exe installer.Run the following command:p4d -r root -xuRestart p4d with your usual parameters.

There is an optional task to consider after completing the upgrade. It would be an opportune time to make a checkpoint of your newly upgraded database, in case there is a subsequent need to recover the db.* files. To make a new checkpoint, repeat steps 1 and 2 from the preceding list.

See Supporting Perforce: Backup and Recovery in the Perforce System Administrator's Guide for information on making a checkpoint of the database and backing up the versioned files.

If you are upgrading the Perforce server from a release prior to 2001.1, there may be additional considerations. To ensure a successful upgrade from releases prior to 2001.1, please send an email to support@perforce.com.

For upgrades to release 2005.1 and later, p4 verify -u must be run at least once following the upgrade to generate file length data for any files in your depot before the upgrade. For more information, see: Important Notes for 2005.1 and later.

Older Perforce client programs (p4, P4Win, and P4SCC) work with newer server versions with no trouble. Some features in a new server release require a client upgrade as well; users with older client programs cannot use the new server features.

Perforce's remote depot support requires all your Perforce Servers to be at or above Release 98.2. 2005.1 and later servers can be used as remote depots from only 99.2 and later servers.

Significant metadata database schema upgrades are performed by the p4d -xu command. The p4d -xu command is generally required when upgrading a server with 1000 or more changelists. If a server has fewer than 1000 changelists, it is automatically upgraded when the new server is started. Attempting to start a new server using a metadata database containing 1000 or more changelists, and for which significant schema upgrades are needed, results in the following server error:

Database is at old upgrade level x. Use 'p4d -xu' to upgrade to level y

where x and y are server internal upgrade levels.

After writing the error, the server terminates. On Windows, error messages are written to the server log but are not displayed.

The p4d -xu command is not required for all server upgrades. For example, p4d -xu is not required when upgrading a 2005.2 server to 2006.1, regardless of the number of changelists. But this does not imply that a 2006.1 server can be downgraded to 2005.2 by simply starting a 2005.2 server using a metadata database previously used by a 2006.1 server. New servers make additional schema modifications in the metadata database as the new server executes.

For most upgrades, additional space is required for both the db.* files and the journal. The maximum additional space required for each of these during the p4d -xu is listed in the following tables. For most upgrades, the actual additional space used is less than what is listed in the tables, since what is listed is based upon a worst-case scenario.

Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journalPlease see 2008.1 -xu for upgrade requirements from earlier versions
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal

If you are upgrading the Perforce server from a release prior to 2002.1, and you use jobs, you must run p4 jobs -R to reindex the jobs. The maximum additional space required for the db.* files during the p4 jobs -R is equal to the size of db.ixtext. The maximum additional space required for the journal during the p4 jobs -R is the sum of three times the size of db.ixtext, twice the size of db.boddate, twice the size of db.bodtext, and twice the size of db.ixdate, or (3x size of db.ixtext) + (2x size of db.boddate) + (2x size of db.bodtext) + (2x size of db.ixdate).

To minimize the additional space required for the journal, disable journaling during the upgrade. Be sure to re-enable journaling and make a checkpoint immediately following the successful upgrade. For information on enabling and disabling journaling, see the "Journal files" section of Supporting Perforce: Backup and Recovery in the Perforce System Administrator's Guide.

View the original article here

git p4 submit always tries to re-apply every patch

We've moved to Git but still have some systems that depend on that same data being in Perforce I'm mirroring our Git repo over to Perforce as follows:

git pull origin mastergit p4 rebasegit p4 submit

but the problem I'm seeing is that every time I run submit after a pull from the origin it tries to re-apply every commit, even ones that were already submitted previously which results in self generated conflicts. What's interesting is that this works:

git p4 submit <--- submit some changes
git p4 submit <--- no changes to submit, so it recognizes that it's up to date

but as soon as I throw in a git pull origin master (even if there is nothing new on the origin) it loses track and on the next submit it tries to re-apply EVERYTHING. For example:

git p4 submit <--- no changes to submit
git pull origin master <--- no activity on the git server side so no changes applied
git p4 submit <--- tries to re-apply all changes that were already submitted earlier

Is git pull origin master somehow wiping out git p4's notion of which changes have been applied and which haven't?

View the original article here

Does perforce track deltas unique to a changeset or does it just store the whole file?

I tried to merge some work that a developer did in a working branch to a stable branch. The files a, b, and c had been changed by at least a dozen changesets since the common ancestor of STABLE and HEAD branches were separated.

I expected that since this developer changed five lines in each of file a, b, and c, that when I integrated from the HEAD to the STABLE branch, I would get his changes in my pending changset, which I could then review and commit.

Instead, it seems that it has taken every change that happened to file A, since the two were branched, and applied all of those changes that also existed in my colleague's working copy.

In other words, there seems to be no record in a perforce changeset, of what my colleague actually changed, versus what the file before contained.

If I browse the submitted changesets, I can see the difference between my colleague's version of the file, and the immediately preceding version. But then, that does not, it seems, determine what goes into the merge.

Doesn't a changeset mean, "a set of changes made between rev X and revision X+1 of a file"? Can anybody help me understand what it means to "integrate a changeset" when in fact, what it seems is that Perforce doesn't track changes, it tracks files.

It is entirely possible that I am doing everything wrong, and would appreciate any pointer as to how it is that you can can merge accurately and safely between Perforce working branches and stable branches, without stuff that you don't want to get integrated to the stable branch getting integrated. It seems that no matter how simple the changes that actually get made in the product, the merge does not actually work for me.

View the original article here

How can I work with multiple perforce client specs in TextMate?

I am using perfoce TextMate bundle to work with perforce from my TextMate editor. As far as I understood, you can only work with one client spec at a time. So I was wondering if anybody figured out a way to work with multiple client specs, without changing the P4CLIENT environment variable in TextMate.

View the original article here

p4v cannot see the default tree in pending tab

hi

I am new to P4V (perforce) while working with this, i cannot see the default folder in pending tab as i cannt drag any files for editing.

Thanks

View the original article here

How can I work with multiple perfoce clinet specs, in TextMate?

I am using perfoce TextMate bundle to work with perforce from my TextMate editor. As far as I understood, you can only work with one client spec at a time. So I was wondering if anybody figured out a way to work with multiple client specs, without changing the P4CLIENT environment variable in TextMate.

View the original article here

After installing perforce and eclipse plugin, team->share option doesn't appear

Hello,
I have eclipse installed in my Mac Pro (OS X). I installed Perforce server on my own machine and then installed Eclipse Plugin for perforce. All seems to be working fine except for the face that I don't have the option: "team->share"! Under team i just have patch. I have even added my perforce server in Perforce perspective! could someone please help?
cheers
Ali

View the original article here