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

How can I instruct Perforce to merge instead of overwrite or revert when unshelving a file?

How can I instruct Perforce to merge changes into an existing, open, and modified file in the workspace when unshelving a file shelved in the depot? The only options that Perforce appears to offer the user is to overwrite or revert the existing file in the workspace, but this does not allow, for example, to unshelve and integrate changes to the same file from multiple change lists. Is there a way around this limitation?

View the original article here

Zeroconf APIs

There does not appear to be any way to detect zeroconf-enabled Perforce servers with P4API.

At this time, P4API does not implement zeroconf detection of Perforce servers. However, that functionality is available through third-party packages and APIs.

The following is a list of such packages or APIs for various languages:

C:

http://developer.apple.com/documentation/networking/Reference/DNSService

Java:

http://developer.apple.com/documentation/Java/Reference/DNSServiceDiscov

Python:

http://o2s.csail.mit.edu/download/pybonjour/

Perl:

http://search.cpan.org/~chlige/Net-Bonjour-0.96/lib/Net/Bonjour.pm

Cocoa/Carbon:

http://developer.apple.com/documentation/Networking/Conceptual/NSNetServiceProgGuide/Introduction.html

Ruby:

http://rubyforge.org/projects/dnssd/

Linux C:

http://avahi.org/

Service Discovery Homepage: 

http://www.dns-sd.org/

View the original article here

Perforce : is there any better way to comment one line in client spec?

You can't.

The clientspec you see is just the output from the perforce database. It gets parsed when saved, so any comments would disappear the next time you load the clientspec.

View the original article here

Sequence error: local change vs remote

What does "Sequence error: local 'change' counter vs remote" mean? Why am I getting "Sequence error" when trying to submit a file to the server?

A "Sequence error" occurs when the change counter is altered before a submit of an existing pending numbered change.  Changelists should always appear in a sequential order, and this error means that the sequence is potentially out of order. If you see this error, contact Perforce Support immediately and shut down your Perforce Server.

Note: Carrying on with this error in place could cause further damage to the information stored in your Server.

The sequence of events that generates this error, is as follows:
Create a pending numbered changeForce the change counter to a number below the pending change numberAttempt to submit the pending numbered changeFrom the error reported, local refers to the current change counter value and remote the value of numbered pending change.  For example: p4 submit -c 221Submitting change 221.Locking 1 files ...edit //depot/main/jam.c#4Operation 'dm-CommitSubmit' failed.Sequence error: local 'change' counter '100' vs remote '221'!Here the change counter has been set to 100 whereas the pending numbered changelist created before the change counter was changed was change 221.

View the original article here

Is it possible to import all of the Perforce history into Kiln

First look here:

Mercurial Wiki entry for converting from Perforce

Since the conversion of VC systems with different paradigms is non trivial, you might want to tweak one of the methods considered there.

If this fails totally, you can also try to convert to a intermediate VC system like, SVN, CVS, git and then to mercurial.

Once you got it in mercurial locally you can always move it up to Kiln or one of the other hosted systems.

View the original article here

Getting Started with Eclipse and P4Eclipse

How do I set up Eclipse and Perforce workspaces on Windows, Linux, or Mac OS X operating systems?

Prior to downloading P4Eclipse, please check the latest release notes for platform and Eclipse version compatibility. You can find the release notes for the latest P4Eclipse here:

http://www.perforce.com/perforce/doc.current/user/p4eclipsenotes.txt

This article is divided into the following sections for your convenience:

1. Install Eclipse (if you do not have an existing instance of Eclipse)

Download the latest Eclipse version that is supported by P4Eclipse from: http://www.eclipse.orgUncompress the distribution and install. For example, on Linux, run: $ tar -zxvf eclipse-rcp-ganymede-SR1-linux-gtk-x86_64.tar.gz$ cd eclipse$ ./eclipse

Important: Your Eclipse workspace must be different than your Perforce workspace.

You want the files in your Eclipse projects to be under Perforce control, but you do not want the Eclipse metadata to fall under Perforce control, because it is particular to that installation of Eclipse. Therefore, Eclipse project files must NOT be under the Perforce client root.

Please see KB article #1048: Eclipse vs. Perforce Workspaces for a more detailed explanation.

2. Install the Perforce plug-in

The following instructions apply to Eclipse 3.5/3.6:

Uninstall any older versions of P4Eclipse/P4WSAD that might have been installed previously. Please see KB article #1049: Uninstalling the P4Eclipse Plug-In for more detailed instructions. Choose: Help | Install New Software in Eclipse. In the Available Software dialog, click Add... to add a new site. In the pop-up dialog, copy and paste the following URL into the Location box: http://www.perforce.com/downloads/http/p4-eclipse/install/3.5http://www.perforce.com/downloads/http/p4-eclipse/install/3.6Check the box for P4Eclipse and then click Next....

Note: If there is more than one version of Perforce in the list, select the latest one.

Complete the setup by selecting P4Eclipse and clicking Finish. When prompted, restart Eclipse.

Please see the Release Notes for more detailed installation instructions. See the Release Notes for P4WSAD 2009.2 for installation instructions for Websphere Studio and other versions of Eclipse.

3. Configure the Perforce plug-in

Mac Users: Please note that your Preferences window is found under Eclipse | Preferences, rather than the Window menu.

After restarting, verify that the Eclipse workspace is not the same as your Perforce workspace, and is not under the control of Perforce. If you are not prompted, choose: File | Switch Workspace | Other

Open a Perforce perspective by choosing: Window | Open Perspective | Other... | Perforce | OK

P4WSAD/P4Eclipse 2009.1 and later

You will see a "No servers are currently defined..." message under the P4 Connections tab. Create a ?New Connection? by clicking on the green plus icon ().

The Add a New Perforce Server Connection form is displayed.

In the Location section, fill in the fields for the "Host", "Port number", and "Charset" (if you have a Unicode server running).  In the Authentication section, fill in the "User", and "Password" fields. Click Next>.

The Choose a Perforce Client Workspace form is displayed.

Either choose an existing client workspace for your user ID from the list box, or create a new client workspace by entering the name of the client in the Workspace name field and the client root in the Location field. Click Finish>.

The P4 Connections pane shows a list of depots available to you in your Perforce server.

P4WSAD 2008.2

You will see a "No servers are currently defined..." message under the P4 Depots tab. Create a ?New Connection? by clicking on the green plus icon (), and filling in the values for the "Port", "User", and "Client Workspace" (and "Charset" if you have a Unicode server running).

Note: You cannot create a Perforce client workspace with the P4WSAD plug-in, so the client must already exist. Run p4 info from within your client workspace to get the correct P4PORT, P4USER, and P4CLIENT settings.

If you get an error message stating ?P4 command line application not found...?, you need to tell Eclipse where the P4 command-line executable is located. To do this, choose: Window | Preferences | Team (click arrow) | Perforce, and click on the radio button for the "Location:" field under the "Location of p4 executable" section. Specify the path to P4 (or p4.exe executable).

General Settings

Descriptions of each of the following settings can be found in Eclipse's Help: 

Help | Help Contents | Perforce SCM  | Setting Preferences

As of 2009.1, a pure Java NIO interface (P4Java) is the default method for interacting with the Perforce server.

Enabling Label Decorations

As of 2009.1 the decorations are configured by default, and are consistent with P4V.

Choose: Window | Preferences | General | Appearance | Label Decorations
Check the "Perforce" box, and click Apply.
Choose: Window | Preferences | Team | Perforce | Label Decorations
Check the box under Ignored Resource Decoration Text labeled "Decorate files/folders contained in .p4ignore".
Choose appropriate locations for File Decoration Icons such as Bottom Right, Top Left, Top Left, Top Right, Top Right, Bottom Left. Click the "OK" button to accept the changes.

Customize Perspectives

To customize perspectives, choose: Window | Customize Perspective | Command Groups Availability tab | check Perforce | OK

9 users have rated this article 4 out of 5

View the original article here

Switching the Perforce server from case insensitive mode (-C1) to case sensitive mode

How do I switch a Unix Perforce Server running in case insensitive mode (-C1) to case sensitive mode?

Switching a Unix Perforce Server running in case insensitive mode (-C1) to case sensitive mode is similar to migrating a Perforce server from the Windows platform (case insensitive server) to the Unix platform.

Verify the archive files.

To confirm that you do not have any missing or corrupted archive files prior to updating the server, run the following command: p4 verify -q //... > verify.errorsIf you encounter any errors, please contact Perforce support for assistance. Stop the server.

Run p4 admin stop to shut down the Perforce Server.

Take a checkpoint.

Run the following command on the server to take a checkpoint: p4d -r P4ROOT -C1 -jcIt is important to specify the correct path to the Perforce server's root directory (P4ROOT). For more information on how to take a checkpoint, consult the Perforce System Administrator's Guide. Backup the checkpoint and depot subdirectories.

The following steps permanently modify the metadata and archive files. Therefore it is critical that you backup the server's checkpoint and all of its depot subdirectories before proceeding.

Resolve case-related problems.

Inconsistent use of case is fine on a case-insensitive platform; it results in serious issues on a case-sensitive one. Conversely, filenames that differ only by case are allowed on case-sensitive platforms, but collide and cause corruption and data loss in case-insensitive environments. A Perforce tool called p4migrate can help you to find and resolve any case-related problems in your repository. You can download p4migrate from our ftp site:

Select the folder that corresponds with the platform of your original Perforce server.

You will also need to download the current p4migrate documentation. 

Move existing database.
Move the database files (db.*) to a temporary location that can be deleted when the Perforce server has been successfully switched to the case sensitive mode. Restore from checkpoint .

Run the following command to recreate the database (db.*) files from the server's checkpoint free of case-inconsistencies and conflicts: p4d -r P4ROOT -jr checkpoint.nFor more information on how to restore from a checkpoint, consult the Perforce System Administrator's Guide.

Re-verify the archive files.

Run p4 verify to check that depot filenames are still consistent with the restored database: p4 verify -q //... > verify.errorsIf you encounter any errors contact Perforce support for assistance. Update the script starting the Perforce server.
Remove from your Perforce server startup script any occurrence of the "-C1" flag associated with the "p4d" command. Restart the Perforce server.

You can now restart the Perforce server using your Perforce server startup script.

View the original article here

Lock Source file in Perforce while using Maven release plugin

Hi,

I got an error in Hudson console out saying the build fail because Maven release plugin cannot update POM.xml version while there are still unresolved files. The problem is caused by other people updating the POM during the build.

Can any guru teach me how to solve the problem? I am think about a P4 lock, anyone can give me more details of using P4 lock with Maven and hudson?

View the original article here

Data Warehouse QA Manager

A Global Online Betting Company is looking for an experienced Data Warehouse QA Manager 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 Manager 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

Perforce: Find source changelist for a branch

Short version:

After branching in P4, how can I find out the "source" changelist of the branch?

Long version:

Let's say I have a main branch of my project at

//project/main/...

The latest changelist submitted here is @123, when I decide to create a branch for release 1.0 in

//project/1.0/...

From P4V, a new changelist is created (say @130), resolved and submitted.

From the CLI, it would look something like this:

p4 integrate -c 123 -o //project/main/... //project/1.0/...p4 submit

Later, I look at the changelists under //project/1.0, and see the @130 changelist containing a lot of branched files. How can I find out the changelist no. that this was originally branched from (that is, @123) ?

View the original article here

P4Eclipse

Refactoring in Eclipse (2008.2 and earlier) SUMMARY: To support refactoring in Eclipse, P4WSAD performs a series of edits (check-outs), integrates, adds, and deletes, as needed, to make the repository reflect the changes to your project. Eclip...

View the original article here

Perforce Get Latest Revision doesn't get checked-out files?

This is an elemental thing. Syncing on one computer is in no way influenced by what you have open for edit on another. Syncing retrieves all those files regardless of who has them checked out, unless you have confused the server by messing with files outside the Perforce client. However, you said you used the -f option, which would solve that problem.

Are you sure you don't have those missing files open for add and not for edit?

View the original article here