The intent of this page is to provide the LBS group with a how-to guide on daily Perforce use. Note: p4 help command will display more thorough information and options than fit the scope of this wiki.
Maintaining code on tip and branch, or on multiple branches -> P4ManageMultipleCodelines. This will be aimed at a process for submitting code to the appropriate maintenance branches and to tip. This page touches on most of what will be done, but perhaps it will be more straight-forward.
For Supl_252 to supl instructions, see PerforceSuplMove.
Proxy Server Available: You may use brm-p4proxy.openwave.com:1672 instead of crownjewels.openwave.com:1672 to mitigate connection outages. All the clients/workspaces used on crownjewels.openwave.com:1672 are readily available on brm-proxy.openwave.com:1672.
By now you may already run through the in-house tutorials on using Perforce (aka p4). If not, and if you are interested, see the Related Links at the bottom of the page. It might not be clear what's actually happening when you use Perforce. I'm hoping to help alleviate that. Before we get too far, you might want to see the following links:
To use the Location depot, you will first need to make a user account.
The LBS P4PORT is crownjewels.openwave.com:1672
The P4PORT defines where the p4 depot resides. Numerous depots can reside on the same server and what separates them is their port number.
With a user account and the P4PORT, you can easily get started. First, we will get setup to work in a command line environment. Second, we will work through getting setup on P4V.
Getting Started: Command line
Most of the commands used below will work regardless of O/S. However, the examples below will assume a Solaris/Unix environment. Adjust accordingly if you are on Windows.
When using p4, you will find it is handy to have your environment variables set to avoid excess typing or even mistakes. P4 uses the variable P4CONFIG to point to a file with p4 related variable definitions.
P4CONFIG=path to .p4config
Create a file with a name like .p4config. .p4config can contain numerous variables, but we will just use P4PORT, P4CLIENT, and P4EDITOR variables for this example. Edit the file and add the following lines:
P4PORT=crownjewels.openwave.com:1672 P4CLIENT=<username>-* | define as jdoe-main or just jdoe for example P4EDITOR=/bin/vi | this can point to any editor you would like
You may also want to add P4USER to your config file, set to your p4 user account name. This way when you want to start working on p4 in a terminal, you will only need to login.
Alternately, you can also use this command for setting any p4 variable:
p4 set P4PORT=crownjewels.openwave.com:1672
It is best not to put your P4PASSWD in your config file and not to use p4 set for your P4PASSWD.
Now just set P4CONFIG once, and you can just make changes to the .p4config file as necessary (if you get tired of your editor, want to use a new/different client, etc).
With that done, now it is time to configure your client.
p4 client clientname
What you will get looks like this (for user cholbroo, clientname cholbroo):
# A Perforce Client Specification. # # Client: The client name. # Update: The date this specification was last modified. # Access: The date this client was last used in any way. # Owner: The user who created this client. # Host: If set, restricts access to the named host. # Description: A short description of the client (optional). # Root: The base directory of the client workspace. # AltRoots: Up to two alternate client workspace roots. # Options: Client options: # [no]allwrite [no]clobber [no]compress # [un]locked [no]modtime [no]rmdir # LineEnd: Text file line endings on client: local/unix/mac/win/share. # View: Lines to map depot files into the client workspace. # # Use 'p4 help client' to see more about client views and options. Client: cholbroo Update: 2006/10/30 13:34:34 Access: 2007/01/02 10:59:25 Owner: cholbroo Host: opwv-cholbroo Description: Created by cholbroo. Root: C:/workspace/perforce Options: noallwrite noclobber nocompress unlocked nomodtime normdir LineEnd: local View: //depot/location/trunk/... //cholbroo/trunk/... //depot/location/3rdparty/... //cholbroo/3rdparty/... -//depot/location/trunk/custom/... //cholbroo/trunk/custom/...
The only line that is completely necessary to change is the first line after View:. This should contain all the modules you want. You can also delete the Host: line if you will be using the view on multiple machines, however AltRoots will be necessary if you will be using both Windows and Solaris/Unix environments and the same P4CLIENT.
This client setup is pretty standard. Notice the 1-to-1 mappings from depot to local workspace. The //cholbroo resolves to the defined Root from the client/workspace definition. The third line keeps the custom codeline out of my local workspace. Use the minus (-) sign to remove any directory level or file from your workspace. Make sure to do a 1-to-1 mapping to avoid issues.
//foo/... //clientname/... //bar/... //clientname/... (Will result in inconsistent behavior and is considered incorrect)
//foo/... //clientname/foo/... //bar/... //clientname/bar/... (This is recommended and will completely avoid confusing syncing scenarios)
Take time to set up the View as you would most like to have it. When you are done, save and quit in your editor.
Now that the client View has been properly defined, you can run the following:
This will put into your Root: or AltRoot: all the files you asked for in your View.
You can also issue specific sync commands. The view defined above has 3rdparty and perhaps that's all we want:
p4 sync //depot/location/3rdparty/...
This will put the contents of 3rdparty into the root directory I've defined in my client in the directory I specified (//cholbroo/3rdparty is equivalent to c:/workspace/perforce/3rdparty).
You can also use tags/labels, dates and revisions:
p4 sync //depot/location/3rdparty/...@labelname p4 sync //depot/location/trunk/common-build/...@YYYY/MM/DD:HH:MM:SS p4 sync //depot/location/trunk/core/modules/build.xml#1
The pound sign indicates you want a specific revision. You can do all these on a per file basis.
Command line: How to edit files
In the CVS convention, you checkout files right to your local disk. As you make changes to the file, CVS is unaware of your activities until you issue a commit. P4 is a bit more picky but not painfully so. When you synced the depot to your local disk, you have obtained read-only copies of the files. However, that does not mean that these files are read-locked. There is a difference. Anyone and everyone with access to the depot could checkout the same file at the same time. No one will be kept from editing. When it comes to submitting changes, p4 will want to know how the new changes should be merged. You will find there are more merging options with p4 than there are with CVS. But before you can do any submitting, you will first need to start opening files for edit. This basically tells p4 what you are editing and at what revision.
To edit a file or files, use:
p4 edit filename -or - p4 edit filename1 filename docs/docfile *.txt
The first command makes filename writeable and notifies P4 the file is open for edit. The example on the right shows that they edit can be used to open numerous files for edit all at once. The files filename1, filename, docs/docfile and all *.txt files within the client mapping will be marked for edit and thus writable on the local workspace.
Once the edit command is issued for a specific file, you won't have to issue the command again unless you've used commands like p4 revert or p4 submit which changes your edit status.
Now that you have files open for edit, you can start making changes. Based on your P4EDITOR setting, your chosen editor will spawn.
If you've made changes and you want to get back to what you started with from your last sync, use:
p4 revert filename -or- directory path
Command line: How to submit files
In CVS you commit a file, in p4 you submit a file. The submit command is pretty basic. It recognizes the changes you've made (all of them) and submits them to the depot accordingly. Should a conflict arise, a merge must take place. Let's go step-by-step.
p4 submit -n
This command will show you what would happen if you had issued a p4 submit command. The "-n" flag works on almost every p4 command. If you are happy with the listed changes, do a p4 submit.
Sometimes a submit won't work right away. It is possible to submit individual files if you need to if you don't have time to resolve the problem right away. If you want to resolve now, issue the following:
p4 resolve -n
This will tell you want needs to be resolved. Now issue the real thing.
You will see an interactive dialog. You will be able to see where the differences are and choose to keep your changes, revert to the old, or some mix of the two. When you are done, you will want to accept the merged version.
Now that all the resolving is complete, submit your changes. See the Changes/Changelist section for information on how to submit specific filesets.
Command line: Clear a file from local disk
The occasion may arise that you no longer want or need to have files from various codelines on your local disk. There are two different scenarios of file removal to cover: individual files and entire codelines. The big caveat is that empty folders are left behind unless the rmdir option is used in your P4 client.
Beside using the commands below, you can always remove lines from your client view. Whatever files those lines represent will be removed during the next p4 sync. If a file lingers, use p4 sync -f with caution. It is better to specify what you want to force a sync against. For example, you remove a line in your client view for //depot/lbs/main/product/... . You specifically want the respective files to be removed from your local disk. You sync but not all the files are removed (likely from the file undergoing changes that p4 was not made aware of). Use the following command to clean up:
p4 sync //depot/lbs/main/product/... -f
Note, the //depot/lbs/main/product/... line in your client view must be gone for this to work.
Individual and multiple files can be removed by syncing to the #0 revision. Some examples are shown below:
p4 sync //depot/lbs/main/...#0
This command sync to the #0 revision, which is nothing. This will safely delete the files from your disk.
p4 sync //depot/lbs/main/product/file.txt#0
This command will remove the file.txt file from the product folder from your disk.
Command line: Creating changelists
There will be times when you want to submit on a specific set of files or omit some files from a submit. This is achieved by maintaining changelists. These two commands are the same:
p4 change p4 changelist
When files are opened with p4 add, p4 delete, p4 edit or p4 integrate, those files are listed in a changelist. Those changes remain local until a p4 submit is issued. When you use the commands above, you will get a editor with a list of changes. Here you can alter what would be submitted. The changelist number assigned will always be associated to your set of changes. The number cannot be reused or destroyed. However, the changes that went in for a specific changelist can be reverted or even removed by an admin. It is possible to maintain multiple changelists, but do be careful to note what each changelist is for.
Command line: Branching
There are two primary methods of branching. Perforce uses a somewhat confusing integrate term where you might expect branch. Let's first look at these two commands.
p4 branch branchname
What you really get when you create a p4 branch is a mapping of files from one place to another. You will see that the file generated when creating a branch looks a lot like the View you made before. Add the mapping lines, save, and exit the editor. No files are moved or copied at this point. It's not really a branch, it's more of a definition of what the branch will be. To actually create the branch, we use integrate to execute the branch definition. In p4, integ is short for integrate.
p4 integ -b branchname
p4 integ will put the branch definitions from branchname into action. Using these two commands in order is the first method of branching, most useful if you have numerous mappings to do. If you are just interested in taking an entire directory and branching, there is a one step branching process.
p4 integ fromfile[dir] tofile[dir]
So that might not be very explicit about what it's doing, so let's look at this example:
p4 integ //depot/location/trunk/core/modules/something/... //depot/location/custom/sprint/core/modules/something/...
What this will do is take all the content in //depot/location/trunk/core/modules/something and copy it into the newly created //depot/location/custom/sprint/core/modules/something. If the second path had already existed and the command was executed, p4 would try to merge the first path into the second path. The integ command can be used for branching and merging.
Run p4 submit to complete the branch creation process and merge if necessary.
Command line: Branching from a tag
p4 integ //depot/location/trunk/...@tagname //depot/location/branches/someProduct/...
This will create a new branch called someProduct from the mainline(trunk/tip/head) code as it was when it was tagged with tagname. Also //depot/location/branches/someProduct/ will start its own revision history starting at version #1 of every file.
Command line: Merging
As discussed in the preceding section, merging and branching use the same command, p4 integ, to do their work. Here are two common ways to merge two codelines.
p4 integ -b branchname //depot/location/trunk/...
This first example will take a previously created branch definition and merge new content into //depot/location/trunk.
p4 integ //depot/path/branch/... //depot/path/main/...
This commmand looks familiar because it is almost exactly the same as when you populate a branch. P4 commands that use two paths have a fromfile tofile relationship. So in this example the branch is on the left, meaning it will merge back into the main codeline.
Run p4 submit to complete the merge process. If the submit fails:
Command line: Navigating Through the Depot
If you are strictly a command line user or you just don't have time or the access to use the GUI, it will be important to know how to traverse the depot to find out directory and file information. To find out what directories are contained in a level of the depot, you will need to know at least a little about your depot path. If you are ever absolutely stuck, //depot is a very safe bet.
Here's how you lists directories in a given path:
p4 dirs //depot/location/*
This will list every directory inside the location directory that are just at that level. For example, //depot/location/trunk will be listed, but //depot/location/trunk/core will not. You may add multiple directory paths to the command.
Here is an example command:
p4 dirs //depot/location/trunk/* //depot/location/trunk/core/*
And the output:
//depot/location/trunk/common-build //depot/location/trunk/core //depot/location/trunk/custom //depot/location/trunk/other //depot/location/trunk/core/components //depot/location/trunk/core/docs //depot/location/trunk/core/modules //depot/location/trunk/core/products
To see files, you must use a different command.
p4 files //depot/location/trunk/core/modules/*
Just like p4 dirs, p4 files will only display what is at the level you specify. Furthermore, it will not show you directories because p4 does not treat directories as it does files. You may append as many directories to the command as you wish.
If these commands don't work for you, try to put double quotes around the depot path, like "//depot/location/trunk/*".
Command line: How to View Changes
Sometimes you will want to know what changes have occurred, who submitted them, and why. The quickest way to do this is to run the following:
p4 changes //depot/location/trunk/core/...@2008/12/29,@now
In this example, the changes in core directory level that occurred from Dec 29th, 2008 to the present will be displayed. The results can be as broad or narrow as necessary, from the top level all the way down to a specific file. If a date range is unnecessary, do not append one.
The results of the changes may not be immediately useful to you. You may be interested in the files in the changelists displayed. To get this information:
p4 -ztag describe changelistNumber
The -ztag is useful in making the information more human readable. Each changelist will have a user, date, description, and files effected (add, delete, and/or edit).
Command line: How to find files that need to be added
I am looking into a way to script this, but the command you need to find out what files need to be added is this:
p4 filelog pathToDir
You may specify a client with p4 -c clientname. This will only report from the level you specify (or currently in if you use *). I'm currently looking into how to do this recursively. The p4 filelog command accepts wildcards.
Command line: Reverting a change
To revert a change in P4V, the steps are as follows: sync to the correct revision (likely the revision that is just before the commit you want to revert), edit, sync, resolve (accept your changes), and submit. Here's the more exhaustive details:
1) Get the good revision. If you submitted file rev #10 but want to revert to #9:
p4 sync -f //depot/path/module/file.txt#9
2) Mark for edit
p4 edit //depot/path/module/file.txt
3) Sync, this should invoke a resolve message. If not, follow up with a submit to invoke the resolve message.
p4 sync //depot/path/module/file.txt
4) Resolve -> Accept your changes
p4 resolve -ay //depot/path/module/file.txt
p4 submit //depot/path/module/file.txt
The file.txt will be at revision #11. You can verify the change worked by diffing the two revisions.
p4 diff2 //depot/path/module/file.txt#9 //depot/path/module/file.txt#11
The two files should be identical.
Command line: Reverting a changelist
Much like the above section, but instead, sync the affected codeline to the changelist number just before the bad changelist. If the bad submit is 1000, you sync to 999. It doesn't matter whether or not changes in changelist 999 affected your codeline or not, it just important that it came before the bad changelist.
To sync to a changelist:
p4 sync //depot/path/module/...@999
Note that you must not have any of the files to be reverted marked for edit. If you do, you will see a message that will say the file(s) could not be synced as requested. After you sync to the previous changelist, mark the codeline for edit, sync, revert unchanged files, resolve, and submit.
p4 edit //depot/path/module/... # All files in path marked for edit p4 sync //depot/path/module/... # Server becomes aware of differences from client p4 revert -a //depot/path/module/... # Revert all files that are not different from server versions
At this point, verify that the expect files to be reverted are listed in your pending changelist.
p4 resolve -ay //depot/path/module/... # Accept your version of the file(s) p4 submit //depot/path/module/... # Files from changelist 999 become the tip revisions
If there were adds or deletes, there is still more to do. If you submitted a deletion by mistake, you must sync to the previous revision of the file, and mark the file for add.
p4 sync //depot/path/module/file.txt@999 p4 add //depot/path/module/file.txt p4 submit
If you submitted a file addition by mistake, mark for delete and submit.
p4 delete //depot/path/module/file.txt p4 submit
Unfortunately, there isn't a single step process to just roll back an entire changelist.
Command line: Subscribe to P4 Reviews
For those that are interested, you may subscribe to a notification service that will alert you via email of changes to any codelines or files of interest. This can only be done via command line.
From command line, run p4 user. An editor will spawn and you can add a Reviews section.
Reviews: //depot/location/trunk/core/modules/jwaf/… //depot/lbs/lmce2.6/jwaf/build.xml
In the example, I will now monitor all changes to mainline jwaf as well as single out jwaf/build.xml on the lmce2.6 branch.
This is not a required change for anyone, but rather available for those that would like to use it. If you have any questions or issues, please let me know.
Getting Started: P4V
Let me first say, please do not use P4Win. It is no longer a supported p4 product. Instead, use P4V.
P4V is a Perforce provided and supported tool. It is a GUI interface to p4 depots. P4V is very handy, but you will find the nomenclature to be a bit lacking. Commands sometime are not named the way they are on command line. I asked a longtime employee of Perforce why they do this, and they said when it all started, they hadn't expected people would use both command line and GUI tools in parallel. While true for some, most tend to use both. After you've logged some time on both, you'll hardly notice, but it is still a strange way to build a tool.
Anyway... logging in is pretty simple. You'll need to have a user account and the depot location.
Server: crownjewels.openwave.com Port: 1672
Enter your username and password and click OK.
When you start a new session, P4V will give you a Depot panel on the left. This is populating with all the contents of the depot, but not downloading anything to your local disk. There is probably a lot more than you need in this view, so in the drop down menu above the Depot panel, select New Workspace.
Give a name for you workspace. This is the same as creating a client on the command line. Please use a convention that people will recognize. I suggest using your username and append something you will recognize later. If you want to be more specific, append more text after you username. Please do not use spaces. A name like username-trunk or username-lmce27-branch is recommended.
Now you will see a Workspace window. There is a tab for Form and View. You use Form to map the paths you want and View to see the list of paths available for mapping. There is also a View section in the Form tab. It might look something like this:
View: //depot/location/trunk/... //cholbroo-trunk/trunk/... //depot/location/3rdparty/... //cholbroo-trunk/3rdparty/... -//depot/location/trunk/custom/... //cholbroo-trunk/trunk/custom/...
This would be if you wanted trunk and 3rdparty in your workspace but did not want to include trunk/custom. The workspace in this example is cholbroo-trunk. Also, cholbroo-trunk on the right resolves to the Root: as defined in the workspace. The Root: is the path on disk where the files will sync to. The forward slashes are absolutely critical.
//depot/location/trunk... != //depot/location/trunk/...
P4V: How to edit files
With your workspace adequately defined, you will have the option of working out of the Depot or Workspace view (on the left and below the middle of and unadjusted screen there are two tabs). The Depot view shows only what is in the depot levels that you defined in your workspace View definition (understand, I don't mean to overuse the words depot and workspace, but this interface is forcing my hand). The Workspace view is based on the Root you defined in your workspace and will show ALL directories and files on your local disk relative to the workspace path. It is possible that there are no depot files here because we haven't actually gotten any files yet.
To get files, go to the directory or file(s) you want to have, right click and "Get Latest Revision". This will get you the latest depot version of the files in the directory or directories or files you selected. At this point, you have a read-only version of the file. DO NOT change that by hand. If you wish to edit the file, simply right-click and "Check Out". You can do this on a per file basis or at the top of a directory. If you will be taking everything from the top of the directory, I will have special instructions on how to submit your changes into the depot.
Once a file is checked out, it is on your local disk and you may edit the file in any editor you wish to use. If you want to spawn the editor out of P4V, you can double-click the file, add the path to the application you want to use, and from then on, files that have the same extension will open with that application. If you wish to change your editor, you must change your preferences (Tools -> Preferences).
P4V: How to submit files & using changelists
P4V has a unique way of handling your changes. Every time you checkout a file, P4V assumes you mean to make a change to it. Each file is displayed on the right in a Changelist window (the red triangle tab marked Pending or click the red triangle icon in the tool bar). If you are working on only a handful of files, this is probably manageable, but if you will be working on several files it is possible you will just checkout everything from a top level. Let's look at how to work in both examples.
Anytime you check out a file, the default changelist will populate with that file, whether you make a change to it or not. A safe way to clean up your default changelist is to use the Depot view, right click on the file or directory where you have files you've checkout, any mix of changed or unchanged is fine, and select "Revert if Unchanged". This will tell the changelist that you don't need to submit those files. At this moment, P4V will release those files from their checkout status.
It would be a good idea to maintain at least two changelists. You get the default changelist without any prompting, but having an extra changelist or two will come in handy. Chances are good that you will be working on several files but won't necessarily need to check all your changes in at once. This is where changelists come in really handy.
To get a new changelist, right click on your default changelist and select "New Pending Changelist". This will assign to you the next changelist number available. This number is a little arbitrary because it is possible people after you will create pending changelists and submit before you. Don't worry, Perforce will keep everything linear. Another way to get a new pending changelist is File -> New -> New Pending Changelist.
Now that you have two changelists, use the default changelist to hold all the changes you aren't ready to submit, and use the new list to put changes you do wish to submit. You can simply drag and drop files from one list to the next. When you are ready to submit, simply right click the changelist and submit. You will be prompted for more information. If the submit fails, P4V should ask if you would like to resolve the conflicts. Choose yes and continue through the resolution process (pretty straight-forward).
All pending changelists not named default will disappear after a successful commit.
P4V: Clear a file from local disk
P4V again proves it's not like it's command line counterpart. To remove files or entire folder trees from your hard drive (indicated by a green light on the bottom right corner of the file icon), it is easiest to do the following. Right click -> Get Revision... -> choose Specific Revision and set to 0 (zero). This will remove the file from your local disk. Make sure rmdir is checked in your Workspace definition to ensure empty dirs are also removed.
This is also a good technique if ever the View gets altered inadvertently. For example, if you started a view with //depot/location/trunk/... and changed this to //depot/location/... without giving a new destination mapping, like this:
And change this to:
P4 doesn't handle this well. Your files might not be in the correct state after doing this. This is a bug in my opinion. Often times, you will see a status that indicates you have the file locally, but you might find you can access or even find the file. To get back to good, get the #0 revision as described above. After that, get the latest revision and you should be good to go.
P4V: Adding Files
Adding files for submission is a bit different. From the Workspace tab, mark a file or directory for addition by right clicking on it and select "Mark for Add". The same process applies for delete ("Mark for Delete").
If you added a lot of files and you aren't sure where they are in your directory tree or you don't want to go through the pain of marking them all, go to the top most directory that would contain your additions and do a Diff. Choose to diff against the latest revision and your workspace. The output will give a list of files and directories that differ from each. At the top right, you will see a color legend for the diff. Yellow is the color for Unique files. Find a directory of file marked in yellow, right click, and select "Mark for Add". This will add all the Unique files to the default changelist.
P4V: Branching & Integration
P4V: Quick Branch Creation via Integration
The following is great for new maintenance branch creation.
Quick and clean branch creation from existing content. The easiest way to create a branch is by way of P4V integration. Your View must be at a level that encompasses the source codeline and the target codeline. With that in place, simply right-click on the source directory -> Integrate.
Fill in the details in the Source and Target lines. Execute a Preview to ensure that the source to target relationships are correct. Then Integrate. This will cause all the files to appropriately populate your local disk. All the files will be marked for add to the new branch. Just submit the file additions and you are done. Repeat for additional modules.
Somethings to keep in mind, you will likely want the modules to be separate if creating a maintenance branch. To do this, watch the preview. If you are adding LSt and WLI for instance to such a branch, you would want //depot/lbs/newbranch/lst/... and //depot/lbs/newbranch/WLI/... to be created rather than having the contents of lst and WLI dropped right into //depot/lbs/newbranch/... . That may be clear as mud, but try the Preview and I think you'll get my point. If it doesn't look right adjust your source and target lines.
P4V: More specific branching
Creating a branch (or a more specific branch) in P4V starts with creating a branch spec. There are two ways to get started. Either File -> New -> Branch Specification or click the green double arrow icon in the tool bar that resembles a mirrored number 4, right click and select "New Branch...".
A branch is simply a mapping of some files to a new location. So pick a relevant branchname, something like product-version or customer-product. Then map the directories you need. Here are example of a jrrlp branch mapping (defined in View section):
And on and on... there are many ways to do this. For what we are doing this time, the first of the three matches what we are doing now, but it is possible we will reorganize the structure of our depot. To branch a branch is no different than branching from the tip:
If the spec directory on the left doesn't exist, the new branch will be empty.
To make a branch spec take effect, you must right click the branch, and select "Integrate Using Branch branchname". The depot will recognize the branch and it will be available for other users.
Merging in P4V uses the same methodology as branching. To merge one codeline to the next, create a branch spec, with the fromfiles going to the tofiles. So if you wanted to merge a branch into a mainline, you would have something like this in your branch spec View:
When the branch is integrated, it will attempt to auto-merge, and spawn resolve windows and tools as necessary. This is useful when diverging solutions need to be brought together and reconciled.
P4V: Finding files that need to be added
In P4V, the navigation panel allows you to choose Depot or Workspace. If you choose the Workspace perspective, navigate to an area where you have been adding new files that are not yet on the p4 server. You will be able to determine which files have not been added as they will be represented by a white page icon. Simply right-click and "Mark for Add...".
P4V: Reverting a change in the depot
Note: P4V now has "Rollback" and "Back Out Submitted Changelist" features that can be used to rollback/revert a submitted changelist. Just context-click the appropriate changelist and find either "Rollback" or "Back Out Submitted Changelist". P4 should generate a new custom changelist to revert the previously submitted change. If the changelist contains adds/deletes/branches/integrations, I recommend using the "Back Out" tool. Or, as was done formerly...
To revert a change in P4V, the steps are as follows: sync to the correct revision (likely the revision that is just before the commit you want to revert), check out, sync, resolve (accept your changes), and submit. Here's the more exhaustive details:
1) Get Revision... -> Get file by its revision number, which should be the file revision of what you want to go back to. 2) Check Out 3) Get Latest Revision -> Do this right on the file you have just checked out. A question mark icon dressing will appear. 4) Resolve -> Accept your changes 5) Submit -> The rev number will be bumped up. This is basically unavoidable. There are ways to completely remove bad commits, but it requires an administrator and is most likely not worth the trouble.
P4V: Reverting a changelist in the depot
To revert a full set of files in a changelist, do the following:
1) Sync to the changelist you wish to roll back to from the proper place in the codeline. If the bad changelist was 1000, sync to changelist 999. Get Revision..., select Changelist, enter the proper number and then click Get Revision.
2) Check out all the files in the codeline or individually if there are an easily managed set of changes. If done individually, you may skip the revert step coming up.
3) Get Latest Revision... -> This will result in question mark icon decorations on the affected files.
4) Revert if Unchanged
A new changelist will be created. If a changelist must be removed from history, an administrator must make the change. However, it is likely not worth the effort.
The file additions and deletions from a given changeset will need to be accounted for separately. Using the unwanted changelist as a reference, make sure all files that were deleted get added back and any added files get deleted. I've seen file deletions reverted properly using the steps described, but additions remain. It is best to verify for yourself that there are no extraneous or missing files.
Getting the tip of LMCE
Currently, the main line in p4 is pretty crowded with projects that are not relevant to the development of LMCE. This list will require maintenance, but should be considered a good starting point for defining a client/workspace view when you need to get everything required for a LMCE tip sandbox.
//depot/location/trunk/... //CLIENTNAME/trunk/... //depot/location/3rdparty/... //CLIENTNAME/3rdparty/...
I recommend reading //depot/location/trunk/README.txt for full details on preparing your local environment. In this example, please replace CLIENTNAME with the workspace name you are using.
There have been issues with certain files having the wrong permissions when packaged. I'll make changes to specific files when requested, but if you'd like to do it yourself, there are two ways.
In commandline, if you wish to give a file keyword expansion (default on each file already), make it writable, and make it executable, do the following:
p4 edit -t text+kwx myfile
or if you have several:
p4 edit -t text+kwx path/*.fileExtension
When you are done, issue a 'p4 submit.
In P4V, just right-click the file, "Check out". Then right-click again, "Change Attributes". Make the necessary change. Submit your change.
In addition, the +m allows a file to retain it's original modtime. The way to get files that have this flag into your workspace is to change "nomodtime" to "modtime" in your client view.
Beware: Case Insensitivity
It is important to note that FOO.file and foo.file are treated as two different files in p4, but not on Windows. This is important to know because if you primarily work in Windows and someone on a Unix system submits the following change:
delete foo.file add FOO.file
you will find things don't resolve properly. P4 users using Windows will not incur this change on an update and p4 will become confused. The constant server:client relationship gives p4 the idea that you don't need the change because FOO.file is equal to foo.file on a Windows machine.
To correct the issue:
- Sync to Revision 0. Do this via commandline (p4 sync -f //depot/lbs/main/foo/...#0) or p4v (right-click -> Get Revision... -> Revision 0). Then get latest (p4 sync //depot/lbs/main/foo/... or right-click -> Get Latest Revision).
- Force sync to latest (not suggested, not 100% reliable). p4 sync //depot/lbs/main/foo/... or right-click -> Get Revision... -> check Force Operation box.
P4 Eclipse Plugin
Start Eclipse (3.2 or newer). In the menu bar, click Help -> Software Updates. Choose the second tab, Available Software and add click Add Site.... Put the following in the location: http://www.perforce.com/downloads/http/p4-wsad/install
The Available Software list will update and the added URL will be included. Expand the list to reveal P4WSAD and click the empty box to select it. Click Install... on the right. You will go through the legal agreement and the installation will begin. After it completes, Eclipse will need to be restarted. After restart, go to Window -> Open Perspective and find Perforce in the list. In the P4 Depot window of the Perforce perspective (Window -> Show View -> P4 Depot if you don't see it), right click and select New Connection or just click the green plus icon.
It is recommended that you have a client/workspace setup on the machine running Eclipse so it can reference that client/workspace.
The rest is really pretty simple and similar to P4V. In order of fullest command set, p4 command line has more functionality than P4V which has more functionality than P4 in Eclipse. There are a few excepts to those comparisons.
From "Practical Perforce"...
Reconciling offline changes is simply a matter of opening files after the fact. The formula is:
Find the files that were changed and open them for editing:
p4 diff -se | p4 -x- edit
Find the files that were removed and open them for deleting:
p4 diff -sd | p4 -x- delete
Find the files that are new and open them for adding. Assuming that you're in the top-level directory of your workspace, the Windows command to find files and add them is:
dir /s/b/a-d | p4 -x- add -f
On Unix that's:
find . -type f | p4 -x- add -f
(These dir and find commands list all the files in your local workspace tree and pipe them to P4's add command. The files that are truly new are opened for adding; the rest generate warnings but are ignored by add.)
Having done this, you can either submit your pending changelist or continue working on your opened files
An online depot browser is available here: P4DB
You may find that some of the links on the left nav don't do anything. This is usually because the search conditions are too broad. For instance, if you wanted to see changes by a particular user, you would click the link "Changes by User or Group" and then make sure to enter as deep a depot path as you can. Using "//depot/lbs/main/..." will probably yield no results because this low powered tool gives up. However, if you enter "//depot/location/trunk/core/modules/v2/...", select the appropriate name and choose the all_users group, you will see results.
The url is pretty easy to decipher and you can manipulate the search by making changes to it.
LbsInstall LBSinstall instructions/information