Perforce Software Build Engineer - Bracknell

Perforce Software Build Engineer - Bracknell

Huxley Associates are recruiting for a Software Build Engineer to work for a key client based in Bracknell.

You will join at a fantastic time as they continue in a period of signifant growth due to the demand for their market leading sofware products. The company previously used Subversion as their source-control system but having moved to Perforce they require someone who can bring expertise in that area they currently do not have.

You will be part of a techncially strong software team who currently look after the build process but they want someone to take the burden from them and allow them to focus on the software development process.

To be considered your CV should demonstrate your experience in a Build Engineer role using Perforce, Hudson and Shell Scripting. If you have any knowledge of Java that would be highly beneficial to help understand the software product.

Salary £40,000 - £45,000 + benefits

Apply NOW!!

View the original article here

Perforce Replication

This section of the Knowledge Base augments the Perforce Replication chapter of the Perforce System Administrator's Guide.

SUMMARY: Replication is the duplication of server metadata from one Perforce Server (the master server) to another Perforce Server (the replica server). The basics of replication are covered in ...

View the original article here

Using Stunnel with Perforce

I need to set up bi-directional communications between a Perforce client and a Perforce server across an untrusted network. How do I secure the Perforce network transport?

In order to secure communication between a Perforce client and Server (p4d), you must use a third-party tool to encrypt network traffic between the two. Network encryption tools include ssh, proprietary VPNs, and Stunnel. This article describes the latter.

Note that the following applies to using stunnel to secure a Perforce connection.  For securing P4Web (i.e., setting it up to use https, see: Creating and Optimizing a Secure P4Web Connection With "stunnel".

Stunnel is an open-source encryption package that allows users to set up SSL tunnels between client(s) and server(s). Using stunnel allows you to set up a port that accepts SSL connections from an SSL-enabled client or another stunnel server. Because both the Perforce server (p4d) and its clients (p4, p4v, p4win) do not support SSL, this article demonstrates how to set up two stunnel servers to talk to each other:

One on the client machine, to accept client requests, encrypt them, and forward them on.One on the server machine, which accepts the encrypted connection, decrypts it and passes it on to the Perforce server.The following information is used to demonstrate how to set up Stunnel: The server machine in named foo. It runs Perforce on localhost:1666, and wants to accept incoming SSL connections for Perforce on foo:2666.The client machine is named bar. Stunnel will be set up so that client requests to localhost:1666 are forwarded, encrypted, to foo:2666 (the server machine).
Why set up Perforce on localhost:1666? This prevents anyone from contacting the server without first going through the stunnel. However, this is not a requirement - stunnel can forward the connection to any host and port.

Before you can set up stunnel, you need to create a self-signed SSL certificate for the stunnel server to provide to stunnel clients contacting it. While any SSL software should be able to do this, the quickest way to do it is via the OpenSSL package. When you have OpenSSL installed, run the following command to generate your certificate:

openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem

When you have the certificate, you are ready to set up Stunnel.

The most recent version of Stunnel, as of this writing, is 4.34. The following information applies to version 4.x of Stunnel. Version 3.x uses a substantially different format, please see the Version 3 section below for information on how to set up version 3 of stunnel.

Stunnel is available as part of the base distribution for a lot of Linuxes and some Unixes.  Check the documentation for your particular OS, or go and grab the source.

Windows users should use this package: http://www.stunnel.org/download/binaries.html

Place the following in a file named "stunnel_client.cnf". Place that file somewhere that stunnel can access it.

; stunnel_client.cnfpid=/var/run/stunnel.pid[p4]accept=localhost:1666connect=foo:2666client=yesStart the client-side stunnel on Linux/Unix with: stunnel /stunnel_client.cnf

Client Configuration (Windows)

cert = stunnel.pemsocket = l:TCP_NODELAY=1socket = r:TCP_NODELAY=1debug = 7output = stunnel.logclient = yes[p4s]accept = 1666connect = :2666

Now start the stunnel program.

Any client requests to port 1666 on the local machine are encrypted and forwarded to foo:2666.

Place the following in a file named "stunnel_server.cnf", and place that file somewhere that stunnel can access it.

; stunnel_server.cnfpid=/var/run/stunnel.pid[p4d]cert=/etc/ssl/certs/stunnel.pemaccept=2666connect=localhost:1666

Start the server the same way as the client:

stunnel /stunnel_server.cnf

Now the server is set up to listen for incoming SSL requests to port 2666 and forward them on to port 1666 on the localhost.

Edit the service's "stunnel.conf" and place the following within it: cert = stunnel.pemkey = stunnel.pemsocket = l:TCP_NODELAY=1socket = r:TCP_NODELAY=1debug = 7output = stunnel.logclient = no[p4s]accept = 2666 connect = 1666 

Now start the stunnel program.  Incoming requests to port 2666 will now be decrypted and sent to port 1666.

If you are using version 3 of Stunnel, then you do not need to set up configuration files - you can specify everything on the command line.

stunnel -p /stunnel.pem -d 2666 -r localhost:1666

The above command sets up stunnel to listen to port 2666 and pass connections on to localhost:1666.

stunnel -c -d localhost:1666 -r foo:2666

The above command sets up stunnel to forward requests to port 1666 on to foo:2666.

View the original article here

Perforce Metadata Replication

Replication is the duplication of server metadata from one Perforce Server (the master server) to another Perforce Server (the replica server). The basics of replication are covered in Chapter 10 of the Perforce System Administrator's Guide. This article provides answers to common questions that come up when setting up and implementing Perforce metadata replication.

With the release of Perforce Server 2009.2, the p4 replicate utility is the supported method of Perforce metadata replication. Information on system requirements and limits and restrictions when using p4 replicate can be found in the Perforce System Administrator's Guide.

The functionality provided by p4 replicate was first introduced in beta (prior to the release of Perforce Server 2009.2) as a standalone utility called p4jtail. p4jtail is now available as open source in the Public Depot as an example of a client program that uses the Perforce C++ API to do replication. It also serves as a starting point for those interested in extending or customizing replication behavior in some way not supported by p4 replicate.

Prior to p4 replicate and p4jtail, the common utility used for replication was p4jrep, a user-contributed Perforce journal replication utility available from the Public Depot. Both p4jrep and p4jtail remain unsupported but customers can obtain assistance and advice on usage by contacting Perforce Technical Support.

What is p4 replicate?
Where do I run the p4 replicate command?
Does p4 replicate work against archive file content?
Can I replicate from one master server to multiple replica servers?
Can I replicate bidirectionally?
Can I checkpoint the master server?
Can I checkpoint the replica server?
How does p4 replicate extract journal records from the master server?
How does p4 replicate locate journal files on the master server?
How does p4 replicate track what journal records have been processed?
Can I filter what gets replicated from the master server?
What is the upgrade process when doing replication?

Q. What is p4 replicate?

A. p4 replicate is a client command that polls a primary Perforce Server (the master) for new journal records, then provides these records to a subprocess that restores the records into the database of a Secondary Perforce Server (the replica).

Q Where do I run the p4 replicate command?

A. You run p4 replicate on the machine that will host the replica Perforce Server. Because p4 replicate is a client command, you can run it from any client machine that can connect to the master server.

Q. Does p4 replicate work against archive file content?

A. No. p4 replicate only replicates Perforce Server metadata, that is the information contained in the db.* files. Depending on the requirements for your replica server, you can optionally configure the replica server to read the master server's versioned files, or use third-party or native OS functionality to mirror the versioned file content to the replica server.

Q. Can I replicate from one master server to multiple replica servers?

A. Yes, multiple instances of p4 replicate can be run against the same master server.

Q. Can I replicate bidirectionally?

A. No, replication is unidirectional.

Q. Can I checkpoint the master server?

A. Yes, p4 replicate continues to run during journal rotation on the master server, except when p4 replicate is started using the -x option. If p4 replicate is started with the -x option, replication will terminate when journal rotation is detected on the master server.

Can I checkpoint the replica server?

A. Yes. If using the replica server for offline checkpoints, checkpoint using the p4d -jd option. See the Offline Checkpoints Knowledge Base article for further details.

Q. How does p4 replicate extract journal records from the master server?

A. Behind the scenes, p4 replicate makes use of the p4 export command to extract journal records from the master server. In addition to providing journal records, p4 export adds fields to its output to indicate points of transactional consistency and the end of the journal file.

Q. How does p4 replicate locate journal files on the master server?

A. p4 replicate locates the live journal file on the master server based on the setting of P4JOURNAL or the -J option passed to p4d on startup. For rotated journals, p4 replicate looks by default in the P4ROOT directory on the master server and uses the default naming convention for rotated journals (journal.nnn). If using the prefix option when checkpointing or rotating the journal on the master server (prefix in this example is /data/backup/p4):

p4d -jc /data/backup/p4 ORp4 admin checkpoint /data/backup/p4p4d -jj /data/backup/p4 ORp4 admin journal /data/backup/p4

the name and possibly the location of rotated journals will not follow the default convention. In this case, the -J flag to p4 replicate must be used, specifying the same prefix used in the checkpoint and journal rotation commands on the master server:

p4 replicate -J /data/backup/p4 ...

Q. How does p4 replicate track what journal records have been processed?

A. p4 replicate uses a statefile to store a journal position token consisting of a journal number and position (byte) offset indicating what journal records from the master have been processed.

Q. Can I filter what gets replicated from the master server?

A. Yes. Filters can be used with p4 replicate to customize the journal records that are replicated. The command that p4 replicate runs on the replica to replay journal records could be, for example, a script that first applies some filter to the journal data stream and then passes the data to the command used to replay the journal records into the replica.

Warning: If you are using replicate to perform offline checkpoints, then do not filter the journal stream. By definition, filters remove content; therefore, a filtered journal replication will not provide sufficient data integrity for your checkpoint and backup process. The primary use of journal stream filtering is to support replication to a read-only Perforce Server used for build or reporting purposes. Depending on the specific use case, it might be desirable to filter out db.have or other db table entries.

Q. What is the upgrade process when doing replication?

A.  For detailed upgrade procedures, see the Upgrading replica servers section of the System Administrator's Guide.

View the original article here

Installer problems on Vista

Perforce Installer versions 2005.1 and earlier do not run by default on Windows Vista because they do not recognize the OS version. Running these older installers will generate the following error message:

Perforce is only supported on Windows NT/2000/XP/2003 and Windows 98/ME.Windows 95 and Windows 98 Retail Edition are not supported.This installation will not continue

To work around this installation problem, right-click on the Installer executable (perforce.exe) in Explorer, select Properties, and go to the "Compatibility" tab. Set the installer to run in XP compatibility mode with full administrator privileges.

An alternative is to simply use a later version of Perforce and the Perforce installer. As of the 2005.2 version of Perforce, there is no problem running the Perforce Installer on Windows Vista.

View the original article here

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

Changing File Case

Change the case of a file on a Perforce Server.

The solution to changing the case of files depends on the native case-handling behavior of your platform. For platforms with case-sensitive file systems (for example, Linux), the case change operation is a straightforward rename. On Windows, additional steps have to be taken to account for the fact that the NTFS file system largely ignores case differences; it is case-aware, but case-insensitive.

Because Windows uses a case-insensitive file system, references to files that differ only by case are ignored. In order to get the Perforce Server to change the case of a file on a Windows Server, the file must first be deleted and then re-added to Perforce using the correct case. Additionally, the internal Perforce "have list" references to the old case name must be eliminated by removing the file from case-insensitive workspaces and then re-syncing the file using the correct case.

Windows Example

In this example, file "foo" has three revisions and you want to change the file name to use all upper-case, from "foo" to "FOO".

Delete the existing file p4 delete foop4 submitRecreate the file in your local file system with the correct case. Then, use the p4 sync command to re-create the file in your workspace using the correct case. p4 sync FOO#3Remove the internal "have list" reference. The p4 flush command (sync -k, in recent versions) removes the have list reference without removing the file from your workspace. p4 flush FOO#noneRe-add the file in the correct case. As with the sync command, the p4 add command uses the case of the file argument provided at the command line, so it is important to provide the correct case. p4 add FOOp4 submit

Notes

To obtain the newly case-changed file, all users who use workspaces on case-insenstive file systems (such as Windows NTFS or MacOS X HFS) must remove the old file from their workspace and then re-sync the renamed file with the correct case to replace it in their workspace.

For the example above, this means:

p4 sync foo#none
p4 sync FOO#head

On Unix, simply integrate the file and delete the original file.

Unix example

Use p4 integrate to change the old name to the new name. $ p4 integrate kiwi.txt Kiwi.txt//depot/Kiwi.txt#1 - branch/sync from //depot/kiwi.txt#1,#9Delete the original name. $ p4 delete kiwi.txt//depot/kiwi.txt#9 - opened for deleteSubmit the changes. $ p4 submitChange 12681 created with 2 open file(s).Submitting change 12681.Locking 2 files ...branch //depot/Kiwi.txt#1delete //depot/kiwi.txt#10Change 12681 submitted.

Verify the results

Use the p4 files command to check that the Perforce metadata is in the proper case.

$ p4 files Kiwi.txt//depot/Kiwi.txt#1 - branch change 12681 (text)

Note that "Kiwi.txt" is now in the proper case.

11 users have rated this article 2.7 out of 5

View the original article here

How do I check in a different branch than I check out from in perforce.

According to the Perforce Blog, the p4 move -f command will move your edit from one branch to the other. From the blog

This can be a real lifesaver if (as I did a few weeks ago) you start working on a fix in your mainline, and then decide that it needs to go into your release branch instead. Previously you would have needed to save a copy of your work, revert it, open the files in the release branch, and copy your edits back in manually — now you just “p4 move -f main/… rel/…” and all your edits go where you need them.

This is a new feature added in version 2010.1 (this year I believe) so that's probably why tech support didn't know about it.

View the original article here

Perforce / Java Developer - Berkshire - Software and Build Engineer

Perforce / Java Developer - Berkshire - Software and Build Engineer

Huxley Associates are working with a market leading software house in Berkshire to recruit a Java Software Engineer with Systems Build / Build Engineer skills.

Your time will be split across the two different actitivities of software engineering and the software build process. This is going to be a great time to join as they are rapidly expanding based on the growth in their market and contracts they have won with an enviable list of global organisations.

Their software products are written in core Java with an Oracle backend and their build process is through Perforce source control systems (previously used Subversion). They expect you will have excellent knowledge of shell scripts on Linux, Ant, Oracle setup and admin and Tomcat (other apps servers also considered).

If this varied role would suit your skills and experience please apply now for immediate consideration.

View the original article here

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

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

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

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

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

codeswarm help: Anyone have experience setting up codeswarm for use with perforce activity log?

Hi,

I've been trying to setup codeswarm for kicks at work using the activity log generated by our perforce depot. I am however running into some troubles following the guide/wiki on the google-code site and was wondering if maybe anyone had experiences with setting it up for a perforce server they could share?

I am running into UTF-8 encoding issues as well as it's taking a bloody long time I believe. My activity log generated by the python script is 65k. I have seen videos of other seemingly large projects so I cannot tell if this is the cause.

Any help appreciated. Thanks

View the original article here

Hudson Perforce plugin - how can I automatically update versions without repeatedly triggering a build

I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)

One of the requirements is to automatically update POM snapshot version numbers following each successful build.

This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which continues ad infinitum.

Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.

This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,

Cheers,

Mark

View the original article here

Test Manager / Automated Testing

Welcome guest. To get the most out of our site, please sign up as a candidate or apply for a recruiter account. Registration is fast and simple and gives you access to the facilities available to make recruitment easier.Test Manager (Agile, Scrum, XP, Java, C++). Highly talented Test Manager sought by financial software house providing real-time web connectivity market data and trading services to investment banks and other financial institutions. As Test Manager you will take responsibility for all testing requirements (mostly automated) and lead of team of seven test engineers, you will have an influential role working closely with an exceptional development team in an agile development environment.

Requirements for Test Manager:
* Strong software testing experience with a thorough understanding of test automation techniques within an agile environment (Scrum, TDD or XP)
* Experience of driving quality assurance and test activities
* Experienced team leader with excellent interpersonal skills
* Excellent test planning and co-ordination skills
* Object orientated programming skills (ideally Java / C++)
* Excellent academic record, minimum 2.1
* Desirable: ISEB, JUnit, APIs, Maven, Cruise Control, Hudson, Jira, Perforce, Selenium, Linux, Solaris and Windows environments

As Automation Test Manager you can expect to earn a highly competitive salary (to £65k), bonus and benefits including free breakfast! Send your CV or call 020 8390 8390 for further information on this and other senior testing positions.

http://www.technojobs.co.uk/job.phtml/470787

View the original article here

perforce implementation of clearcase like "views"

Best approach to working with perforce is to work in a user/feature branch then you can avoid checking into the trunk whilst still pushing your changes into the depot.

When creating a branch, you don't have to branch the entire trunk or source branch - you only need to branch the files you're working on - you can map the rest of the files into your branch via your client spec.

TBH - just buy & read 'Practical Perforce', it has heaps of useful info on how to do this and is very much worth the money if you're using perforce on a daily basis.

Another very useful feature of perforce is 'jobs' - often described only for bug tracking - it's much flexible and allows you to store a changelist history attached to a tag so allowing you to create 'metatags' and attach revisions to it i.e 'NightlyBuild' or 'BreakingChanges or whatever you want.
HTH.

View the original article here

P4Web and External Authentication Triggers

In general, when P4Web needs to be configured to bypass Perforce server authentication (logging in), you can specify a password in the P4WEBSERVICEFLAGS registry variable before the P4Web service is started.

However, if the Perforce server is using an authentication trigger, the password field in the P4WEBSERVICEFLAGS variable is required to be a ticket value rather than a password.

To satisfy the requirement for a valid ticket value for your P4Web service:

Create a group: p4 -p server:port group groupnameAdd your background user to the "Users" field. Change the timeout from the default setting of 43200 seconds (12 hours). The new value depends on the server version: 2008.1 and later: Set this value to 320000000 (over ten year). 2005.1 to 2007.3: Set this value to zero. 2004.2 and earlier: Set this to a very large value that does NOT exceed the "Unix Epoch" limitation (January 19, 2038). A good value is 320000000 seconds (over 10 years).
Note: Setting this value to "unlimited" or 0 (zero) does not work as expected in server versions that support those values (2005.1 through 2008.1). As that value is 0, the technically larger amount of time set in any other group to which the background user belongs will limit that user's timeout to that value.

Note: Server versions 2008.2 and later will no longer allow the timeout to be set to 0 (zero). Setting to zero will generate an error when you attempt to save the group: Error in group specification.Error detected at line 31.Invalid maximum value '0'.Hit return to continue...Setting this value to "unlimited" will still work as an equivalent to the zero timeout value. Save the group. On the P4Web host machine, login the background user : p4 -p server:port -u backgrounduser login Get the ticket value for the background user: p4 -p server:port ticketsThe ticket value is a hexadecimal string similar to "E6DD4B01B38E94113EC51AE46C0664CD" Stop the P4Web service. Set the P4WEBSERVICEFLAGS variable for the background user with the -P flag, using the ticket value in place of a password: p4 set -S "Perforce Web" P4WEBSERVICEFLAGS="-b -P your-ticket-value-here" Set up the other variables for the Perforce Web Service (if necessary): p4 set -S "Perforce Web" P4PORT=server:portp4 set -S "Perforce Web" P4USER=user-namep4 set -S "Perforce Web" P4WEBPORT=port-to-listen-onp4 set -S "Perforce Web" P4CLIENT=client-nameRestart the P4Web service. The server now starts up in browse mode without authentication.
2 users have rated this article 4.5 out of 5

View the original article here

Practical Perforce [PB,2005]

This guide describes Perforce concepts that are essential to every Perforce user. If you are new to Perforce or need to start using features that are unfamiliar to you, read this guide before consulting the documentation for your Perforce client programs.

Price:

Click here to buy from Amazon

Perforce like client specs mappings with Mercurial

We recently moved from Perforce to Mercurial and love it!

One little problem: after much research we can't figure out how to map a special directory in the repository to some special place on the client. Here is an example of our hg repo:

/foo/source files/bar/source files/build /macosx/mac make files /win/windows make files

With Perforce, we were using client spec mappings to map //depot/build/macosx/... to just /build/... on the Mac client, and //depot/build/win/... to /build/... on the Windows dev box. Directories foo and bar are synced as is. Makefiles in /foo and /bar assume that our build makefiles are located in /build and we would like to keep them as is. The final client set of files should look like this:

/foo/source files/bar/source files/build/client specific make files

I've read about subrepos, but this solution does not seem to be client specific.

Any idea how to solve this problem will be very much appreciated!

View the original article here

How to get the last Perforce change list synced to a specific directory by non-local client spec (cmd line)?

I'm trying to return the last change list synced to a specific directory per client spec. I've researched this pretty heavily and am starting to think it's impossible. This is what I have so far:

p4 changes -m1 @

This will return the last change list synced to the passed in client spec, which I can then parse the CL out from. Example of output:

Change 798261 on 2010/11/08 by asdf@specname 'description...'

From that, I can easily parse out the change list: 798261.

What I'm trying to do is get similar output, but for a specific directory that's mapped in the client spec that's passed into the command. I know the -d flag usually lets you specify a directory in perforce commands, but p4 changes doesn't support the -d flag. This is what I'm going for if the -d flag was supported in p4 changes:

p4 changes -m1 -d /root/appname/bin/...@

In theory, if the -d flag was supported, this would return the last CL synced to /root/appname/bin through the passed in client spec. Is there any way to do this? Is there a p4 command I'm missing that would let me specify the directory and get the last CL synced to that directory? Any suggestions are greatly appreciated.

Thanks!

View the original article here

Junior Build and QA Engineer

Computer People are currently recruiting for a Junior Build & QA Engineer to work for a rapidly expanding eCommerce and IT solutions provider based in High Wycombe.

In this role you will build, test, deploy and support a wide range of website for external clients, using a wide range of exciting technologies.

Indeed, you will undertake builds via a build process, using Ant and Perforce and support automatic builds to the staging environment (Linux) and set up new projects/ release in Perforce. You will also Quality Assure other developer SQL scripts, as well as basic Testing work and also provide application support to live products.

To be suitable for this Junior QA and Build Engineer role, you will ideally be IT degree educated (or equivalent) and have the following essential skills:
* Ant build scripts
* Source Control Management and tools especially Perforce
* Java/ Web application development or support experience.

Desirable skills include:
* JBoss
* SQL
* Experience of Linux servers and shell scripting
* Continuous Integration especially CruiseControl
* JIRA
* Groovy

So if you are a graduate in an IT / Computer Science related field, with a desire to work for a fast growing company as a Build and QA Engineer role……please send your CV to me ASAP.

View the original article here

Passing Flags to the Perforce Proxy Service

How do I pass flags to the Perforce Proxy Service?

Starting with release 2005.2, the P4POPTIONS environment variable allows you to pass command line options to the Perforce Proxy Service. For details, see the section on P4POPTIONS in the Command Reference.

It is not possible to pass flags to the Perforce Proxy service in releases prior to 2005.2.

View the original article here

Perforce 2009.2 P4 User's Guide

Tells you how to use the P4 command line interface to perform SCM tasks.

Price:

Click here to buy from Amazon

Data Warehouse QA Engineer

A Global Online Betting Company is looking for an experienced Data Warehousing QA Engineer to join their team in London.

Candidates should have a strong hands-on knowledge of SQL and PL/ SQL along with an ability to read and understand PL-SQL code and provide review comments to developers and design, develop and execute test cases against the Oracle data warehouse. Extensive Oracle 9i/ 10g experience and experience of testing large-scale OLTP systems and/ or data warehouses is required to successfully fulfil the role. A working knowledge of data warehousing-related concepts (including replication, star schema design, OLAP) and proficiency in black box and white box testing techniques is also expected. Good knowledge of programming in Core Java, a solid understanding of source control systems (preferably Perforce) and a Bachelor's Degree in Computer Science is also required.

The chosen applicant will be responsible for preparing test scenarios based on requirements in JIRA and discussion with various stakeholders. He/ She will prepare and execute test cases in fast paced sprints, provide quality testing of Data Warehouse releases and revise and maintain regression test pack following all DW releases. The QA Analyst will also help with the generation of test data for developers when required and work with front-end automation QA engineers from other teams to help build a system that generates repeatable source data for the warehouse. He/ She will be expected to work with all members of the extended DW team to ensure timely delivery of quality code and continuously strive to expand test coverage within the DW.

Candidates should submit their CV in the first instance. The pay rate is negotiable but dependent entirely on experience.

View the original article here

git-p4 cloned repo contains mixed filename case -- how to fix?

I imported a large repo using git-p4, and discovered that I have some strangely mixed-case filenames, e.g.:

dirA/DIRb/file1.txt

and then other files like so:

DIRa/dirB/FILE2.txt

and so on. These get entered into the repo this way because git-p4 uses fast-import. This causes Git to mysteriously claim that there are untracked directories, which are definitely not untracked, and have no new files in them. I discovered from reading this question:

http://stackoverflow.com/questions/3446929/git-still-untracked-after-add

and specifically slayerIQ's answer, that this can be fixed by renaming the dirs in question to have the matching case. And indeed, in a few cases where files had only a single case format, this fixed it. But for the mixed up ones like I mentioned above, it does nothing. This sort of listing confirms my suspicions regarding the case:

git ls-tree --name-only -r branch

I've considered using history rewriting to try to fix it, but that seems awfully heavyweight and I'm a bit hesitant to go there unless I have to (the tree is ~25K files). On the other hand, I do "git status" on a clean tree and get a list of about 35 "untracked" paths. So it's sort of untenable.

I'm able to do a git-p4 clone from scratch if I need to, but I suspect the mixed case paths are coming from Perforce itself. SmartGit doesn't have this problem with the tree, and copying the exact tree to a new repo works fine (since it's added correctly).

Any ideas on how to proceed?

Thanks :)

View the original article here

error using perforce within emacs

hi - I've obtained p4.el and put the following in my .emacs, running under cygwin:

(setq p4-executable "p4")(load-library "p4")

p4.exe is the cygwin version.

On running M-x p4-info I get the following error:

/path/to/p4.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

Yet running M-! p4 info works fine. Probably I'm missing an env variable. Apologies if this is a basic question - I'm new to emacs.

View the original article here

Perforce CLI hangs indefinitely

The error message that is displayed when called from emacs points in the right direction, p4 can't find your perforce server (the default is perforce, that's where the perforce: host unknown comes from.

Make sure to either specify -p for your call to p4 or set the environment variable P4PORT. Beware, despite the name, P4PORT includes the hostname of the perforce server.

p4 -p serverhost:1666

I'm not sure why p4 would hang indefinitely on the CLI and return after some time when called from emacs.

View the original article here

Determining Which File Was Synced Using Overlay Mapping

Several overlay mappings are being used and updated in the client view, and I need to determine which depot file was actually synced to the local workspace.

When overlay mapping is used in the selected workspace client specification, it can become difficult to determine what depot file was synced to a workspace.

Using p4 fstat against a local path that has been overlaid produces information for both files in the depot.

The -Rh flag with p4 fstat limits the output to files actually synced to the client.

For example, assuming a client view of:

+//depot/a.txt //a_client/foo.txt +//depot/b.txt //a_client/foo.txt 

Syncing this client and entering the command produces:

p4 fstat -T "depotFile" -Rh //a_client/foo.txt... depotFile //depot/b.txt 

To confirm that the synced file is what is displayed, you can swap the views:

+//depot/b.txt //a_client/foo.txt  +//depot/a.txt //a_client/foo.txt 

And force sync the file:

p4 sync -f //a_client/foo.txt

The resulting fstat output is:

p4 fstat -T "depotFile" -Rh //a_client/foo.txt... depotFile //depot/a.txt

For more information on overlay mapping, refer to the P4 User's Guide section "Refining client views".

View the original article here

TeamCity: Error on VCS update

Hey Guys, I have some trouble getting the VCS of teamcity work. I'm using perforce and the TC-Server should be configured correct, but when running the project I'm getting the error:

[Updating sources: server side checkout...] Error while applying patch: Failed to change text file: C:\Projects\BuildSrv7... C:\Projects\BuildSrv7.. (Access denied)

I checked the Settings and everybody has full rights in the directory.

And idea, what to do, or how this could happen?

Thanks in advance - Thomas

View the original article here

Why The Spec Depot File Might Not Match The Specification

I was comparing an old group specification from my Perforce server spec depot against the specification itself, and it does not look the same. Is the spec depot not working properly?

The specification forms are a human readable means of displaying and editing underlying database values that are stored in Perforce meta-data. They should not be confused with the data itself. The spec depot stores the form as an archived file that is immutable -- future updates to Perforce cannot change those forms.

For example, a Perforce administrator creates a group using a 2007.3 Perforce server:

Group:dev_groupMaxResults:unlimitedMaxScanRows:unlimitedTimeout:0Subgroups:Users:brunoabigalroni

Perforce adds this to the spec depot as //spec/group/dev_group.p4s exactly as it appeared in the default editor.

Over time the Perforce server is updated to 2008.2, and the output from p4 group -o dev_group now appears as:

Group:dev_groupMaxResults:unsetMaxScanRows:unsetMaxLockTime:unsetTimeout:unsetSubgroups:Owners:Users:brunoabigal roni

Perforce server version 2008.2 added the MaxLockTime limit, changed the "unlimited" option to "unset", and eliminated the use of "0" to represent a maximum timeout value, replacing it with "unset" as well. Perforce converts the old values that now no longer work, and adds the MaxLockTime as unset as part of a new group specification format. While it does differ in appearance, the specification will have the same original functionality unless otherwise noted in the release notes. In this example, there is no current equivalent to the "0" Timeout value, so it switches to the default timeout value of 12 hours.

Note: This does present an issue if you use a shortcut to reset a specification using p4 print and -i flags. Using the same group example, this command would not work:

p4 print -q //spec/group/dev_group.p4s#3 | p4 group -iError in group specification.Error detected at line 24.Invalid maximum value '0'.While there is no built-in method in Perforce for updating those specifications you can safely change the versioned files themselves. One thing that helps this process is that each specification is stored as an individual compressed file, or file type "ctext". The basic process to "update" a specification, assuming that the spec depot is in the Perforce root directory: Navigate to the comma-d (,d) folder in the spec depot versioned files folder.

For example, for the group "dev_group" you would enter the command: cd $P4ROOT/spec/group/dev_group.p4s,d

Note: The ".p4s" suffix is the default for spec depots, as is the depot name "spec". Check the spec depot specification for the actual depot name, suffix (if used) and location of the versioned specification files.

Inside this directory you will see a list of gzipped (*.gz) files similar to: 1.1.gz1.2.gz1.3.gzThe highest numbered file is the head revision of that specification. In most cases, this is the only file you would need to decompress using the command: gunzip 1.3.gzOr, if you would like to change all the stored group specifications, you could use this command: gunzip -r $P4ROOT/spec/group

At this point, there are several options:

If this is a single file, open the the file and manually change the specification.For multiple files, you can use a text editor to do a bulk find and replace across multiple files. BBEdit on the Mac OS or SlickEdit under Windows have this capability, for example.You can create a script to do the find and replace.Once you have modified the files: Re-compress the files using gzip. For a single file: gzip 1.3For multiple files (using the above example): gzip -r $P4ROOT/spec/groupTo avoid errors when running "p4 verify", use this command to recalculate the digests for those files: p4 verify -v //spec/group/...Note: This is a good idea even if you do not normally verify the specification depot. This prevents any future misunderstanding if a new administrator were to run a broader verification, and see a large number of BAD errors in the specification depot.

While groups are being used in this example, this technique can be used to modify any specification file in the spec depot.

Note: As with any low level changes, test those steps against a duplicate of your Perforce server thoroughly before implementing in your production server. Contact Perforce Support if you have any questions.

View the original article here

How do I see if a branch contains a bug fix in Perforce?

Perforce tracks where revisions of a file have been integrated, but it doesn't automatically propagate check-in comments with your bug-tracking metadata.

Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I'm using "branch" in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let's say you've been working in //source/project/trunk/... and you have a changelist @1234 that you'd like to check whether it's been integrated into your release branch //source/project/rel/.... Create a client that maps //source/project/rel/... and execute:

$ p4 integrate -n //source/project/trunk/...@1234,1234 //source/project/rel/...

If Perforce tells you "All revision(s) already integrated.", changelist @1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It's also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)

This doesn't scale especially well -- you need to check each bugfix on each branch you care about, though it does lend itself to automation.

You can use the "unsupported" Perforce command interchanges to get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, "unsupported" means something like "might not work the same in the next revision, but we think it could be useful so we'll release it anyway".) To see what changelists haven't been integrated from our example trunk to release branches, execute:

$ p4 interchanges //source/project/trunk/... //source/project/rel/...Change 1236 on 2010/10/10 by user@client 'Fixed some bug you don't care about'Change 1235 on 2010/10/09 by user@other_client 'Fixed some other random bug'

In this example, I haven't listed changelist @1234 because it's already been integrated into the release branch. One problem I've experienced using interchanges is it'll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you're cherry-picking revisions for a release branch you may see changelists listed again. I use interchanges as a first pass to get a rough idea of what I need to integrate, then look at integrate to get a better idea of what's really missing.

(Perforce also supports a similar concept of "jobs", that let one attach particular fixes to particular changelists, but my organization doesn't use them so I don't know how well they work or whether they are propagated automatically on integration.)

View the original article here

Uninstalling the P4Eclipse Plug-In

How do I uninstall the P4Eclipse plug-in?

To uninstall P4Eclipse, follow the instructions for your version of Eclipse:

For more information on uninstalling P4Eclipse, please see the P4Eclipse Release Notes.

To uninstall P4Eclipse/P4WSAD from Eclipse 3.5:

Disconnect all projects in the IDE from Perforce (Team | Unmanage). Close the Perforce perspective by choosing Window | Open Perspective | Other... | Perforce
and, once the perspective is open, choose Window | Close Perspective. Choose Help | Install New Software...

The Available Software form is displayed.

Click on "What is already installed?"

The Eclipse SDK Installation Details window is displayed.

In the Installed Software tab, highlight P4WSAD, and click Uninstall.

The Uninstall Details window is displayed. Click Finish.

When prompted, click Yes to restart the IDE. In the IDE workspace (on the system where the IDE is used), recursively search the ".metadata/.plugins" directory for "perforce" and  remove any files or folders that are found.

This should include but is not limited to the following:

WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/*perforce*.prefsWORKSPACE/.metadata/.plugin/*perforce*/
Open the bundles.info file found in the following directory:

ECLIPSE_HOME/configuration/org.eclipse.equinox.simpleconfigurator

Search for "perforce" and verify that there are no occurrences. Restart Eclipse and verify that the Perforce perspective is no longer available from the
Window | Open Perspective | Other... dialog. To uninstall P4Eclipse/P4WSAD from Eclipse 3.4: Disconnect all projects in the IDE from Perforce (Team | Unmanage). Close the Perforce perspective by choosing Window | Open Perspective | Other... | Perforce
and, once the perspective is open, choose Window | Close Perspective. Choose Help | Software Updates...

The Software Updates dialog is displayed.

Click the Installed Software tab. Right-click the entry for the P4WSAD plugin and choose Uninstall....

Click Finish on the Uninstall dialog.

When prompted, click Yes to restart the IDE.

In the IDE workspace (on the system where the IDE is used), recursively search the ".metadata/.plugins" directory for "perforce" and  remove any files or folders that are found. This should include but is not limited to the following: WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/*perforce*.prefs WORKSPACE/.metadata/.plugin/*perforce*/
Open the bundles.info file found in the following directory:

ECLIPSE_HOME/configuration/org.eclipse.equinox.simpleconfigurator

Search for "perforce" and verify that there are no occurrences.

Restart Eclipse and verify that the Perforce perspective is no longer available from the
Window | Open Perspective | Other... dialog.

To uninstall P4WSAD from Eclipse 3.0 - 3.3 or Rational Application Developer 7:

Disconnect all projects in the IDE from Perforce (Team | Unmanage), and close the Perforce Perspective and any other Perforce views that are open. Choose Help | Software Updates | Manage Configuration.

The Manage Configuration dialog is displayed.

Open the entry for the installation, right-click the entry for the P4WSAD plug-in and choose Uninstall. When prompted "Do you want to disable and uninstall this feature?", click Yes. To uninstall other plugins that were replaced with the current one, click the Show Disabled Features button.

Right-click any P4WSAD entries and choose Uninstall.

Exit Eclipse.

In the ECLIPSE_HOME directory, search recursively for "perforce" and remove any files or folders that are found.

Note: the ECLIPSE_HOME directory is usually the Eclipse software directory.

In the IDE workspace (on the system where the IDE is used), recursively search the ".metadata/.plugins" directory for "perforce" and remove any files or folders that are found.

Restart Eclipse and verify that the Perforce perspective is no longer available.

View the original article here