Thursday, 9 December 2010

Using P4Broker With Replica Servers

Article #:1354Created:12/08/10Modified:12/08/10

One of the most common uses of using a Perforce replica server is to re-direct read-only commands using the P4Broker application. This allows Perforce administrators to create a single server and host address for their users, and transparently enforce key commands to use the appropriate Perforce server to reduce overall server load.

For this example:

The broker is at port "broker:33333"The production server is at port "master:11111"The read only replica is at port "replica:22222"

Installing and configuring P4Broker:

Install the P4Broker software for your platform. Create a blank broker configuration file: p4broker -C > /p4broker/root/p4broker.confEdit the P4Broker configuration file to add the target, listen port, and other broker information: target = master:11111;listen = 33333;directory = /p4broker/root/;logfile = broker.log;debug-level = server=1;admin-name = "your name";admin-phone = x1234;admin-email = your.name@yourcompany.com;redirection = selective;

Add an "altserver" for the replica:

altserver: replica1{ target = replica:22222;}

Add command handlers to re-direct read only commands to the replica:

command: annotate{ action = redirect; destination = replica1;}command: branches{ action = redirect; destination = replica1;}command: changes{ action = redirect; destination = replica1;}command: clients{ action = redirect; destination = replica1;}command: counters{ action = redirect; destination = replica1;}command: depots{ action = redirect; destination = replica1;}command: describe{ action = redirect; destination = replica1;}command: diff2{ action = redirect; destination = replica1;}command: dirs{ action = redirect; destination = replica1;}command: filelog{ action = redirect; destination = replica1;}command: files{ action = redirect; destination = replica1;}command: show{ action = redirect; destination = replica1;}command: fstat{ action = redirect; destination = replica1;}command: grep{ action = redirect; destination = replica1;}command: groups{ action = redirect; destination = replica1;}command: jobs{ action = redirect; destination = replica1;}command: labels{ action = redirect; destination = replica1;}command: print{ action = redirect; destination = replica1;}command: sizes{ action = redirect; destination = replica1;}command: fixes{ action = redirect; destination = replica1;}command: verify{ action = redirect; destination = replica1;}command: where{ action = redirect; destination = replica1;} command: workspaces{ action = redirect; destination = replica1;} command: users{ action = redirect; destination = replica1;}# Read/Write Commands with Read-Only flags:## sync -p does not write anything to db.have, so it goes to the replica:command: sync{ flags = -p; action = redirect; destination = replica1;}# Specifications using the -o flag to output to STDOUT also do not write to the DB:command: *{ flags = -o; action = redirect; destination = replica1;}Start the broker: p4broker -c /p4broker/root/p4broker.conf &

Now any read-only commands directed to the P4Broker at port "broker:33333" are directed to the replica at port "replica:22222".

Note: Any commands not matching the above handlers are re-directed to the master server "master:11111" by default.

Details on how to use P4Broker can be found here.

Details on setting up a replica server can be found in the replication chapter of the Perforce System Administrator's Guide.

View the original article here

Subversion vs. Perforce

Article #:301Created:12/08/10Modified:12/08/10

A comparison of features, terminology, and commands in Perforce and Subversion.

This comparison is for the experienced Subversion user who is new to Perforce. The following comparisons are high-level and intended to help you take advantage of your Subversion knowledge to learn Perforce.

The following table compares Subversion terms to their Perforce equivalents.

The following table lists Subversion commands and their closest Perforce equivalents.

SVN command Perforce command(s)Description RemarksCreate a new depot (repository).Open file(s) in a client workspace for addition to the depot. The specified file(s) are linked to a changelist. Perforce: The files are not actually added to the depot until the changelist is sent to the server with p4 submit. Opens file(s) in a client workspace for addition to the depot. The specified file(s) are linked to a changelist.Perforce:The files are not actually added to the depot until the changelist is sent to the server with  p4 submit.
SVN: The files are not actually added to the repository until the changes from your working copy are sent to the server with svn commit.
Copy files from the depot into the client workspace and open file(s) for edit. Perforce: p4 sync populates the client workspace. Use p4 edit to open file(s) for edit.
SVN: Unless watch is on, files can be changed once they are checked out.
Send changes made to open files to the depot. Perforce: Changes are grouped into changelists - an atomic change transaction for a set of files all submitted together.
SVN: An svn commit operation publishes changes to any number of files and directories as a single atomic transaction.
Bring the client workspace into sync with the depot. Display information about workspace files. Provides information about changelists and the changelists' files.Display information about the current client and server.

View the original article here

P4Ant

Sorry, I could not read the content fromt this page.

View the original article here

Wednesday, 8 December 2010

Perforce: Is it possible to execute an integrate command on multiple files (not folders) ?

Hi,

I'm trying to execute an "Integrate" perforce command (see: http://www.perforce.com/perforce/doc.current/manuals/cmdref/integrate.html) on a list of files and not on a single file or a specific folder.

Is such a thing possible ?

In other words, is it possible to specify multiple files (and their respective integration paths) in one command ? This would save me the trouble of having to call this command for each file that I'd like to integrate and in the process reduces the number of round-trips on the P4 server.

If not, do you have another command to recommend?

Thanks


View the original article here

Monday, 6 December 2010

Distributed Development

"Cloning" clients to bootstrap large workspaces TASK: How do I create and populate new client workspaces from a master. SOLUTION: When you create a new workspace, you normally use ...

View the original article here

Alternate Perforce Client?

Can recommend a P4Win-like alternative for Perforce, hopefully that supports shelving and may be open source? Needn't be cross platform, just Windows would be fine.

I'm asking as I'm not a fan of the new P4V interface, and I found P4Win a lot more intuitive, easier to use, and much more stream lined.

I haven't found much in my Google searching, but I'm hoping this nexus of programmers might know of a hidden jewel out there. :)


View the original article here

Perforce with dynamic ip

Hi everyone

I've set up a perforce server on an old always-on laptop which is always assigned a reserved address by the router. I have have an account at no-ip.com, which sends to my router, which in turn redirects port 1666 requests to this laptop.

when i try to set p4port to this no-ip.org address, that part is fine, but when i run p4d i get:

Perforce server error: Listen USERNAME.no-ip.org:1666 failed. TCP listen on USERNAME.no-ip.org:1666 failed. bind: USERNAME.no-ip.org:1666: WSAEADDRNOTAVAIL

Whereas if i just set the p4port to 192.168.0.6 i can access the server from behind the network using this one.. but i'd rather be able to access it externally as well..

I've read one other post on here in which someone had the same setup working (http://stackoverflow.com/questions/2397642/online-perforce-repositories , user was gaminghorror) but s/he hadn't gone into as much depth as I obviously needed..

have tried with router and windows xp firewalls off, and xp and router firewalls forward 1666 to this local ip

cheers!


View the original article here

Integration/Resolve Records

Each time an integration is performed, records are stored that guide the Perforce server in performing future integrations and can be examined by users to see what resolve option was used. This article explains the format that these articles are displayed in from the command line and how they relate to the integration operations that they represent.

Integration records are displayed in the output of p4 filelog as follows:

... ... ...

And in the output of p4 integrated:

-

The output of p4 resolved is identical to that of p4 integrated, except that is a local workspace file with no associated revision.

Each integration record associates a range of source revisions with a single target revision. The indicates how the resolve was performed, and therefore the relationship between the contents of the source revision range and the target.

The also includes a direction, either from or into, that indicates which of and is the source and which is the target. In p4 resolved output, the is always a from, indicating that <file1> (the local file) is the target and (the depot file) is the source. In filelog and integrated output, records are displayed for both the source and the target, with one of the records reversed. For example:

//depot/target#1 - branch from //depot/source#1//depot/source#1 - branch into //depot/target#1The possible "how" types are as follows:
copy from/copy into: Indicates that the target revision is identical to the ending source revision. A p4 resolve -at will always produce a "copy".merge from/merge into: Indicates that the target revision was the result of an automatic merge between the previous revision of the target and all of the revisions in the source revision range. A p4 resolve -am will produce a "merge" if there are no conflicts but the final result is not identical to either the source or target revisions.ignored/ignored by: Indicates that the target revision was not changed, and the source revisions were "ignored". A p4 resolve -ay will always produce an "ignore". The "ignored" source revisions are treated as if they were merged, and will be disregarded by future integrations.edit from/edit into: Indicates that the target revision was edited manually before submit, and might contain unique changes. Re-opening a resolved file for edit, or introducing new changes during resolve, will produce an "edit".
branch from/branch into: The same as a "copy", but produced as a result of creating a new branched file, rather than resolving and copying over a pre-existing file.
add from/add into: A "branch" that was edited manually before submit, by re-opening it with p4 add or p4 edit.delete from/delete into: Indicates that the target revision is deleted, as is the ending source revision. Integrating a deleted revision will always produce a "delete".move from/move into: The same as an "add", but created by the p4 move command rather than by p4 integrate and p4 add.
//depot/target... #3 change 1000 integrate on 2009/08/18 by bruno@bruno_ws (text) 'Merging.'... ... merge from //depot/source#3,#5... #2 change 997 edit on 2009/08/17 by bruno@bruno_ws (text) 'Editing.'... #1 change 995 branch on 2009/08/16 by bruno@bruno_ws (text) 'Branching.'... ... branch from //depot/source #1,#2In this filelog example, the target file was branched from revision #2 of the source file in changelist 995, and then edited in changelist 997. Revisions #3 thru #5 of the source file were then merged into the target without conflicts or editing in changelist 1000. //depot/target#2 - ignored //depot/source#2//depot/target#2 - copy from //depot/source#3In this integrated example, revision #2 of the target file was created by performing two integrates and resolves. The second resolve (from revision #3 of the source) was performed as a "copy", overriding the results of the earlier resolve (from #2 of the source). The first resolve is therefore displayed as an "ignore", since it does not have any net effect on the target file.
3 users have rated this article 4.7 out of 5

View the original article here

Sunday, 5 December 2010

How can I clear the list of recent connections from Perforce P4V?

Are you in Linux/Unix? If so, in your home directory is a .p4qt/ directory. If Windows, I'm sure you have something similar.

You should have a file called appsettings.xml. It should have something like this.

server:1666, bob, bob_workspace server:1666, steve, steve_ws server:1666, joe, joe_workspace

Please note, I do not know XML, but you should be able to clear this out of your file. Or, you can delete this file and have it be recreated if you don't mind some preferences being reset.


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

Get files from perforce other than workspace

how to get files from perforce. I dont want to get it into workspace.

eg. I have made changes in 2 files. file1.cs file2.cs Now I want to build the project using updated file1.cs

So I want to get latest files except file1.cs I thought i will get another local copy of project and build it.


View the original article here

The Perforce Plug-in for Microsoft Office

Info & Tags

Article #:849Created:12/15/05Modified:11/29/10Sorry, I could not read the content fromt this page.

View the original article here

problem with hudson

Check your perforce polling log for the job in question to see if it's having some trouble. You can get to it through the link on the left hand side of the job page.

Common pitfalls when dealing with polling with this plugin include:

Incorrect "Path to perforce executable" specified in the job config.Workspace spec is incorrect, so no files, and thus no changes, are found.Sharing client workspaces between jobs. In short: don't do it.The use of on-demand slaves. The plugin needs access to a node that is used to build the project in order to get polling information. If no nodes are available, polling doesn't work correctly.The incorrect use of the "View Mask" option can cause polling to stop working entirely. If you aren't sure how to use this option correctly, then you probably don't need to use it.There is a known issue (HUDSON-2062) related to clogging/leaked pipes on certain operating systems (it seems restricted to CentOS/RedHat). If it works after a restart, but stops working after a few hours or days, then this is likely your problem.

You may want to contact the developer of the plugin directly, their contact info is on the link Sagar provided in his comment: http://wiki.hudson-ci.org/display/HUDSON/Perforce+Plugin, or file an issue here. Remember to include your Perforce Plugin and Hudson version numbers in either case.


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

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