Using the server flag -Cn

Please note that the use of -C1 is documented, however the use of other -Cn options are still undocumented, and are subject to change or removal without prior notice. Consider using the p4migrate utility instead to translate case. If you choose to use the -Cn flag, you must ALWAYS use this flag.  This is necessary both when starting your Perforce Server and when running checkpointing or upgrade operations.  If you do not do so, you risk corrupting your Perforce database and/or your checkpoint and journal.

What does the -Cn flag do?

When do I use it?

The -Cn flag instructs the Perforce Server to override the operating system's case handling behavior for the Perforce database. The flag was introduced in release 2004.2, and is a server side flag. From the release notes:

Forces the server to operate in case-sensitive (n=0) on Windows orcase-insensitive (n=1) mode on Unix. -C2 is an experimental 'hybrid'order: case folding but uniqueness preserving.

You use the -Cn flag when:

You want to change the way the Perforce Server handles the case, overriding the operating system's default case-handling.
You are migrating your Perforce Server to an operating system with a different case-handling method, but you wish to retain the existing method for case-handling.

You do NOT use the -Cn flag when:

You are not intending to override the operating system case-handling.

If you do not intend to override case-handling, you checkpoint the database, resolve any case conflicts and inconsistencies, then restore from this case-consistent checkpoint. This process is explained in more detail in Article #75: Cross-Platform Server Migration.

You MUST NOT use -C0 or -C2 when:

running your Perforce Server on a Windows platform, and one file name or path differs from another only in case. This will corrupt the corresponding archive files.

When using either -C0 or -C2, the Perforce Server makes a distinction between "//depot/file.txt" and "//depot/FILE.TXT", and tells the operating system to write "file.txt,v" or "FILE.TXT,v" accordingly. Although Windows is capable of preserving the case used, it is unaware of the difference between these two names. Therefore, "file.txt,v" overwrites or is appended to "FILE.TXT,v", and so too for the reverse, causing loss or corruption of revision content.

If you have not created a database, you can simply start the Perforce Server using the appropriate -Cn flag.

For an existing database, call or email Perforce Technical Support at support@perforce.com because this is not a trivial task. You will need to take a checkpoint of the database, then restore it including the appropriate -Cn flag in the "restore" command. This restore ensures that the order of the keys is appropriate for the case-handling. In addition, you will need to correct case differences using the p4migrate script, and change versioned file line endings.

Important: The -Cn flag can only be used against new Perforce databases. Using the -Cn flag against a Perforce Server that is already in use instantly renders the keys out of order. Not only does it make the data largely inaccessible, it could easily cause the btree code enough confusion to corrupt the tree.

Notes:

The 2007.2 release of the Perforce Server checks the case order of the database on startup. If there is a mismatch, an error is reported in the log:

Perforce server error:Database open error on db.counters!BTree Case Order Mismatch
As of 2010.1 -C1 is now documented in p4d -h $p4d -h$ -C1 Force server to be case insensitive

For a working example of using the -Cn flag see Article 516: Moving from Windows to Linux, Retaining Case-handling.

3 users have rated this article 3.3 out of 5

View the original article here

How to Monitor a Swamped Perforce Server

How to monitor a swamped Perforce server not responding to p4 monitor show commands. In most circumstances, you can run the p4 monitor command to identify the client processes currently running on your Perforce Server. However, it is possible that a long-running Perforce command can block other Perforce processes, including the p4 monitor request.

It is possible to prevent the blocking of p4 monitor on a Perforce Server running on UNIX or MacOS (or other operating systems that natively support symbolic links). To do so, you must create a new Perforce Server instance that shares the db.monitor table by means of a symlink.

Below is an example of configuring a new "monitor server". Note the new monitor server runs in a different P4ROOT (/perforce/monitor) location and on a different port (1999) than the production server. # Create a new monitor server P4ROOT directory #mkdir /perforce/monitor# Link the production server monitor table into the new P4ROOT directory#ln -s /perforce/production/db.monitor /perforce/monitor/db.monitor# Start up the new "monitor server" (with journaling off)#p4d -r /perforce/monitor -J off -p 1999 -d# Remember to enable monitoring by setting the monitor counter to 1 on the new server#p4 -p 1999 counter -f monitor 1# Stop and restart the monitor server for the new monitor setting to take effect#p4 -p 1999 admin stopp4d -r /perforce/monitor -J off -p 1999 -dOnce the monitor server instance is set up (as above), you can then monitor your production server by running the p4 monitor command on the new monitor server. For example: p4 -p 1999 monitor show

View the original article here

Perforce Windows Service Fails to Start: Invalid Server IP

On a Windows machine with more than one network interface card (NIC), I see the Perforce service failing to start. When I check the Perforce log, I see a message like this:

Perforce server error:Licensing error -- invalid server IP address.bind: 10.1.1.218:1666: WSAEADDRNOTAVAIL

The Host IP Address Does Not Match the License

Confirm that the IP address in the license file matches at least one of the IP address on the server.

The license file is located in the Perforce server root directory. On 32-bit and 64-bit Windows systems the default location is:

C:\Program Files\Perforce\license

If running 32-bit versions of Perforce on 64-bit systems, then the default location is:

C:\Program Files (x86)\Perforce\license

If none of the server interfaces has an IP address matching the address in the file, then you need to obtain a new license file. Contact sales@perforce.com for more information on updating your Perforce license file.

Note: Changing the IP address by editing the license file will not work, as the license file uses a checksum digest to prevent tampering.

The Host IP Address Matches the License

If the Network Interface Card (NIC) is assigned an IP address by way of DHCP, or the Windows system is on a domain, the NIC initialization might be delayed. Windows will verify a single network interface has started before declaring the network to be in a running state. Because the NIC initialization is delayed, the local loopback network interface can trigger a network active signal. The NIC can have a self-assigned IP address which is unlikely to match the IP address located in the Perforce license file.

To confirm the problem, look in the Windows system event log for entries like this:

Source=DHCP, Type=Warning, EventID=1003: Your computer was not able to renew its address from the network (from the DHCP Server) for the Network Card with network address 001143D97C73. The following error occurred: The semaphore timeout period has expired. . Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.Source=NETLOGON, Type=Error, EventID=5719: This computer was not able to set up a secure session with a domain controller in domain INTERNAL due to the following: There are currently no logon servers available to service the logon request. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. Source=DHCP, Type=Warning, EventID=1007: Your computer has automatically configured the IP address for the Network Card with network address 001143D87C73. The IP address being used is 169.254.209.1.Source=Service Control Manager, Type=Error, EventID 7022: The Perforce service hung on starting.Source=Service Control Manager, Type=Error, EventID 7034: The Perforce service terminated unexpectedly. It has done this 1 time(s).

For more information on how to access the Windows system event log:

How to view and manage event logs in Event Viewer in Windows XP

Windows 7 - Open Event Viewer

Right now the only known workaround is to configure the Perforce Windows Service to restart if startup fails:

Select the Windows "Start" menu. Right-click on "My Computer" and select the "Manage" menu item. The Computer Management utility is started. Double-click on "Services and Applications". Double-click on "Services". You will now see a list of available Windows services. Scroll down until you see the "Perforce" service. Right-click on the Perforce service and select the "Properties" menu item. This will display the dialog for the Perforce service. Click on the the "Recovery" tab to display the Perforce service recovery options. Next to the "First failure" label there is a drop-down menu. Select "Restart the Service". Click the "OK" button to save the recovery option. Close the "Computer Management" window.

The Perforce service will now attempt to restart if the initial startup fails.

View the original article here

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

Proprietary Version Control Systems: Bitkeeper, Ibm Rational Clearcase, Perforce, Team Foundation Server, Microsoft Visual Sourcesafe

Chapters: Bitkeeper, Ibm Rational Clearcase, Perforce, Team Foundation Server, Microsoft Visual Sourcesafe, Visual Studio Team System, Accurev, Code Co-Op, Starteam, Ibm Rational Clearcase Ucm, Sun Workshop Teamware, Ic Manage, Allfusion Harvest Change Manager, Ftpvc, Mks Source, Ibm Configuration Management Version Control, Qvcs, Vault, Ibm Rational Multiversion File System. Source: Wikipedia. Pages: 78. Not illustrated. Free updates online. Purchase includes a free trial membership in the publisher's book club where you can select from more than a million books without charge. Excerpt: Rational ClearCase is a software tool for revision control (e.g. configuration management, SCM) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base of version control for many large and medium sized businesses and can handle projects with hundreds or thousands of developers. ClearCase supports two kinds of use models, UCM, and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure (upon which UCM is built) which allows for more flexibility. Both can be configured to support a wide variety of needs. ClearCase can run on a number of platforms including AIX, z/OS, Linux, HP-UX, Solaris and Windows. It can handle large binary files, large numbers of files, and large repository sizes. It handles branching, labeling, and versioning of directories. ClearCase was developed by Atria Software and first released in 1992 on Unix and later on Windows. Some of the Atria developers had worked on an earlier system: DSEE (Domain Software Engineering Environment) from Apollo Computer. After Hewlett-Packard bought Apollo Computer in 1989, they left to form Atria. Atria later merged with Pure Software to form PureAtria. That firm merged with Rational Software, which was purchased by IBM in 2003 . IBM continues to develop and ma...More: http://booksllc.net/?id=343023

Price: $19.99

Click here to buy from Amazon