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.
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.
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: WSAEADDRNOTAVAILThe 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\licenseIf running 32-bit versions of Perforce on 64-bit systems, then the default location is:
C:\Program Files (x86)\Perforce\licenseIf 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
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.
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.
Info & Tags
Article #:849Created:12/15/05Modified:11/29/10Sorry, I could not read the content fromt this page.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.
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.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 ywhere 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
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.
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 submitbut 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?
