|
Function
|
Commands
|
Create a new workspace…
1. That’s modeled after the
“1.0dev” workspace – same
mappings
2. That’s the Perforce defaults, |
Set the workspace name using “p4 set” or in the environment. Then run:
1. p4 client –t 1.0dev
2. p4 client |
Retrieve a file as of
1. Now (head revision)
2. April 15, 2000
3. Label “xyz”
4. Changelist 123456
5. the revision that client
“jab.work” has retrieved
6. The revision you had before
accidently bashing your disk |
Use “p4 sync” as follows:
1. p4 sync file.java
p4 sync file.java#head
p4 sync file.java@now
2. p4 sync file.java@2000/04/15
3. p4 sync file.java@xyz
4. p4 sync file.java@123456
5. p4 sync file.java@jab.work
6. p4 sync –f file.java#have
See “p4 help revisions” for more examples. Note that anywhere that “file.java” is used in these
examples, a full pathname (“c:\work\projects\file.java”) or depot name
(“//depot/rel_218/base/projects/file.java”) could be used. |
Open a file for:
1. add
2. edit
3. delete
And then publish the change to others
. |
Use “p4” with the appropriate verb:
• p4 add file.java
• p4 edit file.java
• p4 delete file.java
Then “p4 submit” to publish it |
What have I changed in the files I
have opened for edit? |
• p4 diff (for all opened files)
• p4 diff file1 file2 (for specific files) |
| Undo a checkout. |
If the file hasn’t been submitted yet:
• Use “p4 revert –a” to find all opened files that have no modifications – it’ll revert those.
• Use “p4 revert file.java” to revert an individual file.
• Use “p4 revert //…” to revert all files.
Remember that “p4 revert” is irreversible.
If the file has been submitted, you’ll need to open the file for edit and check in a prior revision.
Use very good change descriptions to say what you did and why. |
Interrupt your work to edit a single
file and check it in, without any other
disruptions. (You’re hacking Java and
someone needs a “relnotes.txt”
updated ASAP to issue a release.) |
Two ways:
1. Edit the file and submit only that file.
• p4 edit relnotes.txt
• do the modifications
• p4 submit relnotes.txt
2. Make a new changelist to manage just that change.
• p4 change
remove all the files in this change from the Files: section, it’ll create an empty
change.
• p4 edit –c XXX relnotes.txt
where XXX is the change number in the previous step
• p4 submit –c XXX |
| Publish your work to others |
“p4 submit” |
Compress the data on the net
because you have a slow modem line
between your workspace and the
server. |
Run “p4 client” for your workspace, and change the options from “nocompress” to “compress”.
(Read “p4 help client” for details.) |
Get the list of…
1. All changelists applied to the
base codeline
2. … to the prodxyz codeline
3. … to the prodxyz codeline,
including those applied
originally to another codeline
and integrated into prodxyz
4. All revisions of file.java |
Use “p4 changes” or “p4 filelog” as follows:
1. p4 changes //depot/eng/…
2. p4 changes //depot/eng/prodxyz/…
3. p4 changes –i //depot/eng/prodxyz/…
4. p4 filelog file.java |
Push … from the base codeline
(“prodxyz”) to the 1.0.1 codeline
(“prodxyz-1.0.1”):
1. Push change #1232
2. From change #129 to #134
3. all changes in the base
codeline |
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 //…@=1232
2. p4 integ –b prodxyz-1.0.1 //…@129,@134
3. p4 integ –b prodxyz-1.0.1 (no additional args)
Note that this assumes that the named branch specification “prodxyz-1.0.1” has been created
by your project lead or administrator using “p4 branch”. |
Push … from the prodxyz-1.0.1
codeline to the base (“prodxyz”)
codeline:
1. Push change #1235
2. From change #127 to #128
3. all changes in the base |
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 –r @=1235
2. p4 integ –b prodxyz-1.0.1 –r //…@127,@128
3. p4 integ –b prodxyz-1.0.1 –r (no additional args)
The “-r” reverses the order of source/target in that named branch specification.
Note that for the ‘selective integration’ cases, you’ll want to be VERY CAUTIOUS of ‘accept
theirs’. |
Show the ‘diff’ between the
prodxyz-1.0.1 codeline and its
parent |
“p4 diff2 –b prodxyz-1.0.1” (This works because “prodxyz” is the name of the branch
specification, not because “prodxyz” is part of “//depot/prodxyz/…”) |
| What branches do I have? |
If you use “p4 branch” to create branch specifications and use them consistently, then “p4
branches” provides this info. |
How do I make a new codeline
named prodxyz-2.0? |
There are several steps:
1. Make a named branch specification. Save it.
• “p4 prodxyz-2.0”
• if you want to exactly imitate another branch (e.g. prodxyz), use
“p4 branch –o prodxyz-1.0.1 > tmp” to capture the output, edit this temporary file
and replace the “1.0.1” references with “2.0”, then run “p4 branch –i < tmp”.
2. Run the “p4 integrate” command to populate this new codeline. Submit the change.
• p4 integrate –b prodxyz-2.0
or, if you want to push content as of a certain label (e.g. “xyz”) from the parent,
p4 integrate –b prodxyz-2.0 //…@xyz
• p4 submit
3. Send e-mail telling everyone about this codeline and what it’s used for. |
Put everything onto a laptop, you’re
going to the beach and want to hack.
(This assumes that you won’t be
connected to a net while away.) |
There are several steps:
1. Connect the laptop to the net.
2. Run “p4 sync” to populate the source onto the laptop.
3. Leave for the beach.
4. While editing, use “chmod” or “attrib” to make the files writeable. Make your changes.
5. Get back to work, reconnect to the net.
6. Run the following commands to tell you what’s updated and open them for
add/edit/delete:
• p4 diff –se | p4 –x – edit
• p4 diff –sd | p4 –x – delete
• find . –type f –print | p4 –x – add
Then inspect what’s opened (“p4 opened”) and what you’ve changed (“p4 diff”). Submit or
revert as appropriate. |
| Run a checkpoint |
“p4 admin checkpoint” – only an administrator can run this. (An administrator has “super”
permissions in the “p4 protect” data.)
Be sure to back up the checkpoint, the current journal, and each of the “depot” directories on
the server machine! |
| Change the security/permissions |
“p4 protect” – only an administrator can run this.
Also…
“p4 protects” – used in 2006.1 and later to TELL you your permissions . |
| Make a label |
It’s a two-step process:
1. Make the label using “p4 label xxx”
2. Populate it using “p4 labelsync –l xxx”
or if you have a specific list of files,
“p4 labelsync –l xxx file1 file2 …”. |
Copy a label’s contents to another
label. Assume that the existing label
is “xxx” and the new label is to be
“abc”. |
Again, a two-step process:
1. Make the label using “p4 label –t xxx abc”
2. Populate it using
“p4 labelsync –l abc //…@xxx”
Note that the second step is really identical to the second step in the previous question – we’re
just specifying a very specific list of revisions [of files] to include in the new label.
(Also…
In 2005.1 and later, “p4 tag” will make the label and apply it to a set of files.) |
|
|
