It's probably best to create a small workspace (the term is "client")
to play in, so that you can experiment with a few files and not necessarily
the 16,000 files that you're planning to manage with source control.
The "S.C.M." translates to "Source Code Management" or perhaps "Software Code Management" or "Software Control Management" - the better systems let you manage large sets of files, have multiple people working with the same body of files (a development team of 1 person isn't much fun), and work on different platforms (such as Windows/NT and Unix) transparently.
There are a lot of S.C.M. products around - this FAQ won't try to spend a lot of time enumerating them or contrasting them.
p4 sync
That will get you a read-only copy of the "head "revision of every file that your client can see.
cd directoryname
p4 sync ...
That will get you a read-only copy of the "head" revision of every file in that directory and its subdirectories that your client can see.
Some examples:
p4 sync @BUILD_28 | Update the local copies of files on the current client to be the exact revision specified in label "BUILD_28". The local copy of files not included in the label, but managed by Perforce, are removed from the client. |
cd directoryname
p4 sync ...@BUILD_28 |
Update the local copies of files in directoryname (and underneath
that tree) on the current client to be the exact revision specified
in label "BUILD_28".
The local copy in directoryname (and underneath that tree) of files not included in the label, but managed by Perforce, are removed from the client. Files not under directoryname aren't touched. |
p4 sync directoryname/...@BUILD_28 | Should do exactly the same thing as the previous example. (Neat, huh?) |
In Perforce, the 'working' copy of the file is a local copy stored in the "client area". The modified contents are sent back to the server only when you do a 'p4 submit'.
When you run...
p4 submit
...you'll be dumped into the editor, to write a description of why
you made these changes. See the manual for more details.
cd directoryname
p4 add
filename
or,
p4 add directoryname/filename1 directoryname/filename2 (and so on)
The final step, which is to run p4 submit , will make these new files available to other Perforce clients.
Perforce infers the existence of new directories whenever it sees a new directory it hasn't seen before.
You don't need to remove a directory, explicitly. You simply
remove files in that directory, using
cd directoryname
p4 delete
filename
or,
p4 delete
directoryname/filename1 directoryname/filename2
(and so on)
and occasionally,
p4 delete
directoryname/... (remove
all files in `directoryname' and its subdirectories)
The penultimate step, which is to run p4 submit , will these deletions to other Perforce clients.
The final step is to remove the empty directories on your client: "p4 delete / p4 submit" removed the files, but not the directories.
For example, if you want to edit revision #12 of xyz.java, you'll need
to type:
p4 sync
xyz.java#12
p4 edit
xyz.java
The first command, of course, isn't needed if you already have revision #12 of xyz.java. (You can tell which revision you have by typing p4 files xyz.java .
You'll be told, when you run p4
edit xyz.java, that you're not editing
the most recent revision and that you'll need to resolve later revisions
prior to submitting your changes. (If
you think about it, that makes sense.)
Now the file's opened for "edit", and you can do whatever you want
to the file. Submitting it, however, is going to be a problem: you don't
want to inadvertently overwrite the contents of later revisions of the
files.
Case #1: you really do want to overwrite the later revisions
for some reason.
p4 submit
you'll be told that the your changes need to be resolved against more
recent revisions prior to submitting. Write down the change number
it gives in the error message (e.g. "submit -c 12345"), although you
can always find it again by running the command p4
changes -s pending .
Wherever revision specifications are supported, @date and "@datetime" can now be used in addition to @change and @label. The format for date is YYYY/MM/DD, and the format for datetime is YYYY/MM/DD:HH:MM:SS. If no time is given, midnight is assumed. |
In general, you'll need to have a piece of data from your build person: the label name used for that build. (You can always hunt for it, using the command p4 labels .)
If the label is release3.2label, you can update your client area to this by typing:
p4 sync @release3.2label
This will update your client to this label, removing
local copies of files that aren't in the label.
If you want subdirectory xyz to be updated, but no other directories
on your client, you would type:
p4 sync
xyz/...@release3.2label
For example, say you've opened xyz.java using the command:
p4 edit
xyz.java
To see your modifications, type:
p4 diff
xyz.java
Note that this is not comparing your local copy of the file against
the most recent changes that other people have checked in - it's comparing
against the revision you were working against. (That's p4
diff filename#head .)
For example, say you've opened xyz.java and z.java
in directory dir1 using the command:
p4 edit
dir1/xyz.java dir1/z.java
To see your modifications, type:
p4 diff
dir1/...
Note that this is not comparing your local copy of the file against
the most recent changes that other people have checked in - it's comparing
against the revision you were working against. (That's p4
diff dir1/...#head .)
p4 diff file1 file2
If, for example, the command "diff -c" produces "context output format", then the sequence:
DIFF="diff
-c"
export
DIFF
p4 diff
file1 file2
will produce that type of output for the differences between the two files.
Note that p4
diff2 file1 file2 doesn't
honor this variable, because the "diff" operation is run on the server
and only the formatted output is returned to the user.
will product output that looks something like:
xxx - file(s) not in client
view.
if the directory's not included in your client
view. (You'll want to see the documentation for help on this, but you'll
know where to start: client specification.)
For example, say you've opened xyz.java using the command:
p4 edit
xyz.java
Various "diff" commands follow:
p4 diff xyz.java | Compares your working copy against the revision your edits are on - if you are editing revision #4 of a file, this will compare your working copy against revision #4. |
p4 diff xyz.java#2 | Compares your working copy against the revision #2. |
p4 diff xyz.java#head | Compares your working copy against the most recent revision in the depot. |
p4 opened -a | grep joe
If you don't have "grep" (i.e. you're on Windows) you'll need to search
the output of p4 opened
for this.
Use p4 changes -i directory/... to get the list of change numbers since a file stored originally in Perforce.
You'll recall that the difference between a revision
and a change number is that the revision is specific to a file...
x.c#1
(revision #1 of file x.c)
x.c#2
(revision #2 of file x.c)
y.java#1
(revision #1 of file y.java)
y.java#2
(revision #2 of file y.java)
y.java#3
(revision #3 of file y.java)
The change number is a list of revisions that
got changed as part of one atomic change to the Perforce depot. For example,
change #12345 might be a change to add comments to x.c and y.java, and
this change might've created revision #2 of x.c and #3 of y.java.
Use p4 revert directory/... to discard all the modifications you've made to any file in directory (or its subdirectories).
Let's say you have a main codeline, and a child codeline ("branch") called methusalah.
If you wanted to propogate change number 900 from the main codeline to methusalah,
you'd type:
Of course, if you wanted to propogate change number 902 from methusalah to
the main codeline, you'd type:
It's a good idea to include the original change
number in the change description for the integration.
Let's say that the name of the file is "-filename".
Run "p4 delete dummy -filename" to delete the file - ignore the comment about the dummy filename, its purpose is to stop the option/argument processing and let everything else on the command line be interpreted as filenames.
Or, you could run "p4 delete ./-filename", which uses the Unix directory separator ('/') to construct a filename that refers to the same file, but doesn't begin with a dash. (NT uses might use '\'.)
p4 -c
workspacename cmd
p4 revert filelist
... to revert them.
p4 client
-d workspacename
It's easy, but requires a little planning.
Let's say that you can retrieve all the files in the directory (using the depot name syntax) //bas/BIN/src/krn/rsec/ except the file //bas/BIN/src/krn/rsec/rsecstoc.c.
It could be several things:
Last modified on 11 November 1998.