<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (X11; U; OSF1 V4.0 alpha) [Netscape]">
<TITLE>FAQ for System Administators supporting basic Perforce issues</TITLE>
<x-html>
</HEAD>
<BODY>
<DL>
<H1>
Perforce FAQ for System Administrators</H1>
<p>
Contributed by Jeff Bowles
<H3>
Note - the intended audience for this FAQ is a system administrator who
knows some Perforce commands as a user, but needs more information to be
able to do some Perforce administration tasks such as setting up a new
Perforce user or dealing with restarting the Perforce server after a recovery
from a catastrophic disk crash.</H3>
<I>This FAQ assumes that there is a Perforce Administrator who knows some
of the more complex parts of Perforce, who can provide help, counseling,
and deal with policy-specific issues....</I>
<BR>
<BR>
<H5>
<B>Client Stuff</B></H5>
</DL>
<UL>
<LI>
<FONT COLOR="#000000"><A HREF="#What's a client? What's a client spec?">What's
a client? What's a client spec? How do I tell what this client spec does
and doesn't do? How do I add a new client?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#How do I tell what some else's client spec...">How
do I tell what some else's client spec looks like? How do I change the
e-mail address for a user is, if it's not the same as their P4 user name?</A></FONT></LI>
</UL>
<H5>
<FONT COLOR="#000000">Non-admin Usage Stuff</FONT></H5>
<UL>
<LI>
<FONT COLOR="#000000"><A HREF="#How do you add/delete files?">How do you
add/delete files? Can you retrieve a deleted file? How?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how can I look at internal variables ...">On
Windows/NT, how can I look at internal variables that the Perforce client
uses to connect?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#what's p4 revert?">What is/How do I do
a p4 revert?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#What's an integration?">What is/How do
I do an integration?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#who has this checked out?">How can I find
out who has a particular file checked out?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how do I do a p4 resolve?">How do I do
a p4 resolve</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how to unsubmit a changelist?">How do I
"unsubmit" a changelist</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how to unstick files in a changelist?">How
do I "unsubmit" files stuck in a *pending* changelist</A></FONT></LI>
</UL>
<H5>
<FONT COLOR="#000000">Policy Stuff</FONT></H5>
<UL>
<LI>
<FONT COLOR="#000000"><A HREF="#How does Perforce deal with CR/LF issues?">How
does Perforce deal with CR/LF issues? Can this be overridden?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#Should we store binaries in Perforce?">Should
we store binaries in Perforce? Why, or why not?</A></FONT></LI>
</UL>
<H5>
<FONT COLOR="#000000">Admin Issues (backups et al)</FONT></H5>
<UL>
<LI><A HREF="#checkpoint_journal">Checkpoint/Journal Questions</A>
<OL>
<LI>
<FONT COLOR="#000000"><A HREF="#what is a checkpoint">
What is a checkpoint?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#when do I make a checkpoint">
When do I make a checkpoint? How often should I checkpoint my database?</A></FONT></LI>
<LI><FONT COLOR="#000000"><A HREF="#what's a journal file">
What's a journal file? What's it good for?</A></FONT></LI>
<LI><FONT COLOR="#000000"><A HREF="#what do I do if the checkpoint of the database fails">
What do I do if the checkpoint of the database fails?</A></FONT></LI>
<LI><FONT COLOR="#000000"><A HREF="#do I have a good backup strategy">
So if I make checkpoints and have journaling enabled, do I have a good backup strategy?</A></FONT></LI>
</OL>
<LI>
<FONT COLOR="#000000"><A HREF="#If the machine dies...">If the machine
on which the Perforce depot dies, what do we do? If it runs out of space
on the depot filesystem, what do we do?</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how do I handle security?">How do I handle
security? (i.e. adding new IP address using p4 protect)</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how do I add a new user?">How do I add
a new user?</A></FONT></LI>
<LI>
<A HREF="#What, exactly, does p4 protect do?">What, exactly, does p4 protect
do?</A></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#how do I bring an offline worker back">How
do I bring an off-line worker back online</A></FONT></LI>
<LI>
<FONT COLOR="#000000"><A HREF="#should we back up clients?">Should I back
up clients? If so, what files should I back up and what files should I
keep? How long should I keep backups of clients?</A></FONT></LI>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="What's a client? What's a client spec?"></A><B><FONT COLOR="#000000">What's
a client? What's a client spec? How do I tell what this client spec does
and doesn't do? How do I add a new client?</FONT></B></LI>
</UL>
<UL><I>Glossary</I>
<UL>
<LI>
<B>depot</B> - the term usually applied to the Perforce repository, which
lives on the other end of the network connection specified with $P4PORT.
There's also a syntax used to specify the path names of files in th<FONT COLOR="#000000">e
depot:</FONT><TT><FONT COLOR="#990000"> //depot/x/y/z/file.java</FONT>.</TT></LI>
<LI>
<B>client</B> - the [local] disk area on a developer's machine, onto which
read-only copies of the source files are copied. Usually there's one client
per user and one client per machine, but that's completely up to the user
and to the people who set it up. (The command p4 client allows you to change
the mapping so that a file is stored, locally, to the directory/file you
specify. See the next item for details.)</LI>
<LI>
<B>client specification</B> - documented <A HREF="http://www.perforce.com/perforce/doc.982/cmdguide/quickstart.html">here</A>,
the internal information specific to a Perforce client, that specifies
the following:</LI>
<OL>
<LI>
The date/time the client was created.</LI>
<LI>
The local directory name that's the top of the local copy of the file set
retrieved from the depot.</LI>
<OL>
<PRE><TT><FONT COLOR="#990000">Root: D:/weblogic</FONT></TT></PRE>
</OL>
<LI>
An owner, which isn't that useful.</LI>
<LI>
Lines at the end that look like</LI>
<OL>
<PRE><TT><FONT COLOR="#990000">//depot/x/y/... //<I>clientname</I>/x/y/...
//depot/x/z/%1 //<I>clientname</I>/x/old-z/%1</FONT></TT></PRE>
</OL>
<LI>
The way to read this is "<I>left is the depot pathname and right is the
local disk pathname"</I>. These lines are the meat of the client specification
and can be a little tricky.</LI>
<UL>
<LI>
The first line says <I><FONT COLOR="#000000">"all files in depot directory
/x/y on the depot should be installed in D:/weblogic/x/y, preserving the
path names below x/y" </FONT></I> (for this example). <U>Every "..."
is a wild card meaning "everything from here down".</U></LI>
<LI>
the second lines says "<FONT COLOR="#000000">the files in depot directory
/x/z (but no subdirectories in it) should be put into D:/weblogic/x/old-z"</FONT>.</LI>
</UL>
<LI>
The default client spec maps all depot files to the local disk, using:</LI>
<OL>
<PRE><TT><FONT COLOR="#990000">//depot/... //<I>clientname</I>/...</FONT></TT></PRE>
</OL>
<LI>
Usually we'll make a client with the "default client specification" and
use that to create new clients. For example, if the a client named XXX
exists and has the perfect client spec for a new client to imitate, then</LI>
<OL>
<PRE><TT><FONT COLOR="#990000">P4CLIENT=newclientname
p4 client -t XXX</FONT></TT></PRE>
</OL>
<TT><FONT COLOR="#990000"> </FONT></TT><FONT COLOR="#000000">will
create the new client using the existing "XXX" client as a template. (Hint:
</FONT><TT><FONT COLOR="#990000">p4 client</FONT></TT><FONT COLOR="#000000">
uses the current directory as the default for the Root: of the local file
set it'll retrieve, so you can save keystrokes by </FONT><FONT COLOR="#990000">chdir</FONT><FONT COLOR="#000000">'ing
there before running </FONT><TT><FONT COLOR="#990000">p4 client</FONT></TT><FONT COLOR="#000000">.)</FONT></OL>
<LI>
<B>client software</B> - the copy of <FONT COLOR="#990000">p4.exe</FONT>
or <FONT COLOR="#990000">p4</FONT> ("client") that someone's downloaded
from <A HREF="http://www.perforce.com">Perforce, Inc</A>. that connects
to a database process ("server") that administers the depot.
There are many platforms supported, which means there are many different
machines for which you can download a new <FONT COLOR="#990000">p4</FONT>
client executable. [Aside: <U>there are no legal restrictions at all w.r.t.
Perforce client software</U> - the licenses are based on the number of
legal users, and we can download client software for as many different
platform types as we choose.]</LI>
</UL>
<I><FONT COLOR="#000000">How do I tell what this client spec does and doesn't
do?</FONT></I>
<BR>
<UL>
<LI>
<TT><FONT COLOR="#990000">p4 client -o <I>clientname</I></FONT></TT><FONT COLOR="#000000">
will tell you a lot about a remote client. The two items to stare at are
"</FONT><FONT COLOR="#990000">Root:</FONT><FONT COLOR="#000000">" (where
the local files are loaded) and "</FONT><FONT COLOR="#990000">View:</FONT><FONT COLOR="#000000">"
(the mapping from depot-name to local-name).</FONT></LI>
<LI>
<FONT COLOR="#000000"><U>Most client-spec headaches have to do with the
view not including a new branch/codeline recently installed</U> - your
build engineers can usually alert you these problems - and problems with
wild cards in a "View:" line. ("..." and "%1", above, are both such wild
cards and are documented <A HREF="http://www.perforce.com/perforce/doc.982/cmdguide/details.html">here</A>.
In general, your build engineers and/or your local Perforce administrators
should have a handle on this.)</FONT></LI>
</UL>
<I><FONT COLOR="#000000">How do I add a new client?</FONT></I>
<BR>
<UL>
<LI>
<FONT COLOR="#000000">See the item, above, that talks about </FONT><FONT COLOR="#990000">p4
client -t XXX</FONT><FONT COLOR="#000000">.</FONT></LI>
</UL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="How do you add/delete files?"></A><B><FONT COLOR="#000000">How
do you add/delete files? Can you retrieve a deleted file? How?</FONT></B></LI>
<BR>
<UL>
<LI>
To <U>add</U> a file, run <FONT COLOR="#990000">p4 add filename</FONT>;
to <U>delete</U> a file, run <FONT COLOR="#990000">p4 delete filename</FONT>.</LI>
<BR>In both cases, you've really just opened the file for add/delete and
need to run <FONT COLOR="#990000">p4 submit</FONT> afterwards to get it
checked into the depot.
<LI>
To retrieve a deleted file:</LI>
<UL>
<LI>
You need to know the filename in the form:</LI>
<UL>
<PRE><TT><FONT COLOR="#990000">//depot/dev/src/sandbox/jab/GNUdepends.def</FONT></TT></PRE>
</UL>
<LI>
<FONT COLOR="#000000">You'll need some history information, so run the
following command:</FONT></LI>
<UL>
<PRE><TT><FONT COLOR="#990000">D:\weblogic\dev\src><U>p4 filelog //depot/dev/src/sandbox/jab/GNUdepends.def
</U>//depot/dev/src/sandbox/jab/GNUdepends.def
... #4 change 19737 delete on 1998/05/05 by jab@jab.greenwich 'Change to move jab's erro'
... ... delete into //depot/dev/src030100b01/sandbox/jab/GNUdepends.def#2
... #3 change 19611 edit on 1998/05/04 by jab@jab.sol 'Bits of hacking to support stag'
... ... branch into //depot/dev/sandbox/jab/GNUdepends.def#1
... ... branch into //depot/dev/src030100b01/sandbox/jab/GNUdepends.def#1</FONT></TT></PRE>
</UL>
<FONT COLOR="#000000">In this case, <U>revision #4 deleted the file</U>,
and <U>revision #3 was the last revision that had "real" contents</U>.</FONT>
<LI>
<FONT COLOR="#000000">A fast way to look at the contents of revision #3
of this file:</FONT></LI>
<UL>
<PRE><TT><FONT COLOR="#990000">p4 print //depot/dev/src/sandbox/jab/GNUdepends.def#3</FONT></TT></PRE>
</UL>
<FONT COLOR="#000000">Note that the first line of output is a line of the
form "</FONT><FONT COLOR="#990000"> <TT>//depot/dev/src/sandbox/jab/GNUdepends.def#3</TT></FONT><FONT COLOR="#000000">".</FONT>
<BR><FONT COLOR="#000000">If you don't want that, run </FONT><TT><FONT COLOR="#990000">p4
print -q</FONT><FONT COLOR="#000000"> </FONT></TT><FONT COLOR="#000000">instead
of </FONT><TT><FONT COLOR="#990000">p4 print</FONT></TT><FONT COLOR="#000000">.</FONT>
<LI>
<FONT COLOR="#000000">To retrieve the contents and check 'em in again,
you need to "re-add" the file:</FONT></LI>
<DL>
<DL>
<PRE><TT><FONT COLOR="#990000">p4 print -q GNUdepends.def#3 > newfile
p4 add GNUdepends.def
cp newfile GNUdepends.def
p4 submit</FONT></TT></PRE>
</DL>
</DL>
<FONT COLOR="#000000">(There's two other ways to do this: one is to branch
revision #3 of the GNUdepends.def, creating a new version, but unfortunately
it would need a different name; another would be to "p4 sync -f GNUdepends.def#3"
and then move that copy to the side, then do the "p4 add" shown above.)</FONT></UL>
<LI>
<FONT COLOR="#000000">The unasked question is <I>Can I expunge a file that
I checked into the wrong place?</I> <U>That question is answered in the
Perforce documentation, under "p4 obliterate", but this shouldn't be done
without your Perforce administrator standing over you.</U> (That operation
is completely irreversible.)</FONT></LI>
</UL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="How does Perforce deal with CR/LF issues?"></A><B><FONT COLOR="#000000">How
does Perforce deal with CR/LF issues? Can this be overridden?</FONT></B></LI>
</UL>
<OL><I>Background</I>
<OL>
<OL>The machine on which the "p4" client software is run dictates the CR/LF
behavior. If you extract the files from the Perforce depot using the Windows
version of "p4" it'll have CR+LF as line separators <U>for text files</U>,
even if you physically wrote the files to a Unix disk that was remotely
mounted using NFS or Samba. (This means that the Macintosh version of the
"p4" client uses CR for end-of-line, always, and the Unix client uses LF
for end-of-line.)
<BR> </OL>
</OL>
<I>How do you tell if a file is "text" or not?</I>
<OL>
<DL>If a file's checked in, run <FONT COLOR="#990000">p4 file XXX</FONT>
where XXX is the name of the file. You'll get output of the form:
<DL>
<DL>
<PRE><TT><FONT COLOR="#990000">//depot/dev/src/GNUdepends.def#3 - edit change 20027 (ktext)
//depot/dev/src/GNUmakefile#188 - edit change 21753 (text)
//depot/native/events/EventsGenCtl.bmp#3 - delete change 1103 (binary)</FONT></TT></PRE>
</DL>
</DL>
<FONT COLOR="#000000">Unless it was specified when the user ran p4 add,
the local Perforce client guessed based on the first few bytes of the file.
(NUL characters and non-ASCII are dead giveaways - if they're present,
the file <U>has</U> to be binary.)</FONT>
<BR> </DL>
</OL>
<I><FONT COLOR="#000000">What if you it guessed wrong, and you need to
change the type of a file so that it does end-of-line processing?</FONT></I>
<OL>
<OL><FONT COLOR="#000000">You'll need to open the existing file for editing,
change its type, and submit the change:</FONT>
<OL>
<PRE><TT><FONT COLOR="#990000">p4 edit -t text //depot/native/events/EventsGenCtl.bmp
p4 submit</FONT></TT></PRE>
</OL>
<FONT COLOR="#000000">In this case, you'll probably be treating a .bmp
file like it's text, which is pretty silly, but this gets the point across.
You can go back and forth with a file, if you choose - change the type
of a file from text to binary, or binary to text. (The </FONT><U><FONT COLOR="#990000">k</FONT></U><FONT COLOR="#000000">
in </FONT><U><FONT COLOR="#990000">ktext</FONT></U>, above, means "expand
keywords like $Id: //depot/internal/staff/jab/P4AdminFAQ.html#18$ in the
contents when it's fetched from the depot. There are other types, also:
<TT><FONT COLOR="#990000">p4 help reopen</FONT></TT> lists 'em. There's
a type for "long text files that are computer-generated such as PDF files"
- be sure to note that one.)
<BR> </OL>
</OL>
<I>Ways to force it to not interpret end-of-line, to leave the file contents
alone:</I>
<OL>
<OL>Change the file type from text to binary, and make sure that it's byte-for-byte
the exact contents you want.
<BR> </OL>
</OL>
<I>How do I get Unix end-of-line processing behavior on my Windows Perforce
client?</I>
<OL>
<OL>Short answer: I don't know. Certainly, you can edit the files on Unix,
store what you want there, and change the file type to "binary" to guarantee
that the contents aren't munged when you fetch 'em with the Windows client.
that's probably the fastest, but ugliest way.</OL>
</OL>
<HR WIDTH="100%"></OL>
<UL>
<LI>
<A NAME="How do I tell what some else's client spec..."></A><B><FONT COLOR="#000000">How
do I tell what some else's client spec looks like? How do I change the
e-mail address for a user is, if it's not the same as their P4 user name?</FONT></B></LI>
</UL>
<UL><I><FONT COLOR="#000000">Looking at someone else's client...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">To look at your client, you run:</FONT>
<UL><TT><FONT COLOR="#990000">p4 client</FONT><FONT COLOR="#000000"> </FONT></TT><FONT COLOR="#000000">
(dumps you into an editor)</FONT></UL>
<FONT COLOR="#000000">or</FONT>
<UL><FONT COLOR="#990000"><TT>p4 client -o</TT> </FONT><FONT COLOR="#000000">
(dumps information to standard output)</FONT></UL>
<FONT COLOR="#000000">To look at someone else's client, run:</FONT>
<UL>
<PRE><TT><FONT COLOR="#990000">p4 -c <I>client-name</I> client</FONT></TT></PRE>
</UL>
or
<UL>
<PRE><TT><FONT COLOR="#990000">p4 -c <I>client-name</I> client -o</FONT></TT></PRE>
</UL>
<FONT COLOR="#000000">(Don't change this information (inside the editor)
without eventually informing the user who uses it the most - they could
get cranky about it!)</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">Looking at someone else's user information...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">To look at your user information, you run:</FONT>
<UL><TT><FONT COLOR="#990000">p4 user</FONT></TT><FONT COLOR="#000000">
(dumps you into an editor)</FONT></UL>
<FONT COLOR="#000000">or</FONT>
<UL><FONT COLOR="#990000"><TT>p4 user -o</TT> </FONT><FONT COLOR="#000000">
(dumps information to standard output)</FONT></UL>
<FONT COLOR="#000000">To look at someone else's user information, you run:</FONT>
<UL><TT><FONT COLOR="#990000">p4 <I> </I>user</FONT></TT><FONT COLOR="#000000">
</FONT><I><FONT COLOR="#990000">their-name</FONT><FONT COLOR="#000000">
</FONT></I><FONT COLOR="#000000">(dumps you into an editor)</FONT></UL>
<FONT COLOR="#000000">or</FONT>
<UL><TT><FONT COLOR="#990000">p4 -u <I>their-name</I> user -o</FONT></TT><FONT COLOR="#990000"> </FONT><FONT COLOR="#000000">
(dumps information to standard output)</FONT></UL>
<FONT COLOR="#000000">(Note that, if it dumped you into an editor, the
file's readonly. To modify another user's information, you will need to
utter a couple of extra commands not included in this FAQ - see your local
Perforce Administrator for those. )</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">How would I change someone's e-mail address in
the Perforce user database?</FONT></I>
<BR>
<UL><FONT COLOR="#000000">Run </FONT><TT><FONT COLOR="#990000">p4 user
<I>user-name</I></FONT></TT><FONT COLOR="#990000"> </FONT><FONT COLOR="#000000">(which
dumps you into an editor) and change it.</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">Note - if you're trying to automate this...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">Most commands that use the option </FONT><FONT COLOR="#990000">-o</FONT><FONT COLOR="#000000">
to write to standard output have a </FONT><FONT COLOR="#990000">-i</FONT><FONT COLOR="#000000">
option to read from standard input. By doing this, you could write a script
that appends "@weblogic.com" to the e-mail user with the commands:</FONT>
<UL>
<PRE><TT><FONT COLOR="#990000">p4 user -o ><I> tmp-file
</I>sed '/^Email:/s/$/@weblogic.com/' < <I>tmp-file</I> | <U>p4 user -i</U></FONT></TT></PRE>
</UL>
<FONT COLOR="#000000">The underlined part will need a modification to succeed
- it's deliberately omitted from this FAQ for security reasons. See
your Perforce Adminstrators for details.</FONT>
<P><FONT COLOR="#000000">(If you do this sorta thing, put a lot more error
checking into the script that you see here!)</FONT></UL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="Should we store binaries in Perforce?"></A><B><FONT COLOR="#000000">Should
we store binaries in Perforce? Why, or why not?</FONT></B></LI>
</UL>
<UL><FONT COLOR="#000000"><I>Sure, but they can take up some space.</I>
There are several things you need to do when you store a binary in Perforce:</FONT>
<UL>
<LI>
<FONT COLOR="#000000">Make sure its file type is "</FONT><FONT COLOR="#990000">binary</FONT><FONT COLOR="#000000">"
(or "</FONT><FONT COLOR="#990000">xbinary</FONT><FONT COLOR="#000000">")
when you check it in. Binary files are stored in a different manner than
text files, because with text files it makes sense to store a simple delta
between two revisions. For certain generated text files (PostScript, Adobe
Acrobat PDF files) and binaries it doesn't make sense, so pick the file
type appropriately.</FONT></LI>
<LI>
<FONT COLOR="#000000"><U>Perforce stores enough information to recreate
each revision of the binary</U>, so if the binary is 100 Mb and you keep
checking in new versions every day, you might run out of disk very quickly.</FONT></LI>
<LI>
<FONT COLOR="#000000">A binary file stored in a branch doesn't immediately
take up more space, but <U>has the potential to fill up each user's client
area</U> by having multiple copies of [potentially] big files. [This can
happen because a user might have multiple branches mapped to their disk,
and they'd get a separate copy of the file for each branch.]</FONT></LI>
</UL>
<FONT COLOR="#000000">The main headache with storing binaries is that it's
tempting to check in the complete release you developed using Perforce,
so that "x.c" and "x.h" and "x.o" and "x.out" all appear in Perforce. That
might not be the strategy you want, partly because it introduces an ambiguity:
someone might update "x.c" or "x.h" but not realize that "x.out" is getting
shipped, but wasn't updated. (That's dangerous.)</FONT>
<P>Addendum: a recent version of Perforce supports "compressed files" and
can save a lot of space on the depot when used. If you need to store binaries
in Perforce, it's handy to research this new feature.
<P>Also, there's a new file type called "tempobj" which stores "temporary
object" files. It's a good way to check in the most recent revision of
some object file, obsoleting all prior revisions, so that developers will
be able to use this object (or library or executable) without recompiling
it.</UL>
<HR WIDTH="100%">
<UL>
<LI>
<B><FONT COLOR="#000000">On Windows/NT, <A NAME="how can I look at internal variables ..."></A>how
can I look at internal variables that the Perforce client uses to connect?</FONT></B></LI>
<P><I><FONT COLOR="#000000">Environment</FONT></I>
<BR>
<UL><FONT COLOR="#000000">There are the environment variables described
here, but the most frequently used are <I>$P4PORT</I> and <I>$P4CLIENT</I>.</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">Internal variables</FONT></I>
<BR>
<UL><FONT COLOR="#000000">In addition, p4 set shows some entries hidden
[in the Windows registry, I believe] that can be set using</FONT>
<UL>
<PRE><FONT COLOR="#990000">p4 set P4PORT=<I>p4server:6999</I></FONT></PRE>
</UL>
<FONT COLOR="#000000">or</FONT>
<UL>
<PRE><FONT COLOR="#990000">p4 set -s P4CLIENT=<I>jab.newclientname</I></FONT></PRE>
</UL>
<FONT COLOR="#000000">To view this internal registry, type </FONT><TT><FONT COLOR="#990000">p4
set</FONT></TT><FONT COLOR="#000000"> (with no arguments).</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">Debugging this...</FONT></I>
<BR>
<OL>
<LI>
<FONT COLOR="#000000">If </FONT><FONT COLOR="#990000">p4 help</FONT><FONT COLOR="#000000">
works, then </FONT><FONT COLOR="#990000">$P4PORT</FONT><FONT COLOR="#000000">
is set correctly.</FONT></LI>
<LI>
<FONT COLOR="#000000">If </FONT><FONT COLOR="#990000">p4 client -o</FONT><FONT COLOR="#000000">
works, then </FONT><FONT COLOR="#990000">$P4CLIENT</FONT><FONT COLOR="#000000">
is <U>probably</U> set correctly; read the output closely to make sure.</FONT></LI>
<LI>
<FONT COLOR="#000000">If </FONT><FONT COLOR="#990000">p4 user -o</FONT><FONT COLOR="#000000">
works, then it's getting the username out of the environment (good).</FONT></LI>
</OL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="what's p4 revert?"></A><B><FONT COLOR="#000000">What is/How do
I do a p4 revert?</FONT></B></LI>
</UL>
<UL><FONT COLOR="#000000">A file can be opened for add/delete/edit/integrate/branch,
which flags the Perforce database with enough info to know who's changing
what. These "markers" are cleared when you do run</FONT><FONT COLOR="#990000">
p4 submit </FONT><FONT COLOR="#000000">or </FONT><FONT COLOR="#990000">p4
revert </FONT><FONT COLOR="#000000">on those files.</FONT>
<P><FONT COLOR="#000000">To revert a file you've opened, run</FONT>
<UL>
<PRE><FONT COLOR="#990000">p4 revert file1 [file2 ...]</FONT></PRE>
</UL>
<FONT COLOR="#000000">This causes several things to happen:</FONT>
<OL>
<LI>
<FONT COLOR="#000000">It's no longer marked as "open" in the Perforce database;</FONT></LI>
<LI>
<FONT COLOR="#000000">A fresh copy of the revision of the <I>reverted</I>
files that you started hacking on is copied back to your client area, since
you might've made modifications that need to be obsoleted;</FONT></LI>
<LI>
<FONT COLOR="#000000">The <I>reverted</I> files are marked read-only, as
if you'd just run "p4 sync" on those files.</FONT></LI>
</OL>
<FONT COLOR="#000000">Note that you weren't given fresh copies of the top-level
revision of the reverted files - they're left in exactly the state they
were in before you ran "p4 add/delete/edit/integrate/branch".</FONT></UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="What's an integration?"></A><B><FONT COLOR="#000000">What is/How
do I do an integration? <A NAME="how do I do a p4 resolve?"></A>How
do I do a p4 resolve?</FONT></B></LI>
<P><FONT COLOR="#000000">In short, an integration is a command to merge
changes from another codeline or a later revision of a file into a target
revision managed by Perforce.</FONT>
<OL>
<LI>
<FONT COLOR="#000000">For example, if you're editing revision #14 of a
file and someone checks in revision #15, you'll need to <I>resolve</I>
the new code into your working copy prior to submitting it to the depot.</FONT></LI>
<LI>
<FONT COLOR="#000000">Another example is if you make a change to file.c
in a branch and want to propogate the modified version to a parent/child
branch of that file.</FONT></LI>
</OL>
<FONT COLOR="#000000">The detailed walk-through of an integration isn't
included in this FAQ. To do this, look <A HREF="http://www.perforce.com/perforce/doc.973/cmdguide/html/conflict.htm">here</A>
for the Perforce documentation on dealing with conflicts/integrations.</FONT>
<P><B><FONT COLOR="#000000">The most important thing to remember, when
you're running "p4 resolve", is that <I>the file you're modifying is <U>your</U>
file; any other files are <U>their</U> files</I>. </FONT></B><FONT COLOR="#000000">Why
bother with this note? Well, much of the confusion doing the integrations
comes from questions that "p4 resolve" asked you. You're expected to respond
with things like "accept yours" or "accept theirs" or the like, and
it's easiest to remember that <U>yours</U> always refers to the file that
the "p4 integrate/p4 resolve/p4 submit" cycle will be modifying. It doesn't
matter whether it's the parent or the child in the branch.</FONT></UL>
<UL> [Aside: you must always remember to <TT><FONT COLOR="#990000">p4
submit</FONT></TT> the merge to complete the operation. Until that's done,
you can <TT><FONT COLOR="#990000">p4 revert</FONT></TT> the changes (to
deal with them <I>tomorrow</I>) or<TT><FONT COLOR="#990000"> p4 resolve
-f </FONT></TT> the changes if you want a second chance at it.]</UL>
<HR WIDTH="100%">
<UL>
<LI><A NAME="checkpoint_journal"></A>Checkpoint/Journal questions
<p>
<OL>
<LI>
<A name="what is a checkpoint"></A><B>What is a checkpoint?</B>
<P>
A checkpoint is an human-readable file that contains all information
necessary to recreate the Perforce databases but not the individual
file revision contents. It's created by running the following
command, replacing <i>P4ROOT</i> with the name of the Perforce server's
root directory. (The <i>P4ROOT</i> directory is the one that the "db.*"
files live in.) </P>
<DL>
<PRE> <FONT COLOR="#990000">p4d -r <I>P4ROOT</I> -jc</FONT></PRE>
</DL>
<u>The administrator should always check the output of the command that
created the checkpoint to make sure that there were no errors.</u>
<p>
<li>
<A NAME="when do I make a checkpoint"></A><B>When do I make a checkpoint? How often should I checkpoint my database? </B>
<p>
This is your backup of the Perforce metadata, so it should be done
"regularly". (Probably every night or every other night is best - <U>at
least once a week</U> unless you've analyzed the number of changes you
make and believe that "less often" is appropriate.)
<BR>
<DL><I>Put the checkpoint and journal files and the backup of P4ROOT/depot
on a different disk from the database! </I>
<BR> </DL>
Checkpoints are not created automatically: you must make checkpoints yourself,
using "at" (on Windows/NT) or "cron" (on Unix).
<p>
<li>
<A NAME="what's a journal file"></A><B>What's a journal file? What's it good for? </B>
<p>
In database parlance, the journal is the running transaction log that
keeps track of all database modifications since the last checkpoint. It's the bridge between two checkpoints, and if you have Monday's
checkpoint and the journal that was collected from then until Wednesday,
those two files (as a unit) contain the same information as a checkpoint
made Wednesday would contain. This is what makes it possible to restore
the database to the most recently run transaction, instead of to
the time of the last checkpoint operation.
<P><U>The journal is automatically enabled if you installed onto Windows/NT
using the InstallShield installer, but not automatically enabled on any
other platform.</U>
<P>If journalling is not enabled on your platform, or if you've
disabled it at some point in the past, you can enable it easily.
To enable journaling, run
<BR><TT> <FONT COLOR="#990000">p4
set P4JOURNAL=fullpathname</FONT></TT>
(on Windows/NT)
<BR>or, on Unix, set the environment variable "P4JOURNAL" to a journal
pathname prior to starting "p4d". (There's a command-line argument, "-J
<I>journal</I>", that will set this, also. If you use the command-line
way of setting the journal, you'll need to add that argument when you
make a checkpoint.) In either case, you'll need
to restart the Perforce server to enable this.
<P>The instructions to do this are in the Perforce manuals, but for reference,
they are included here.
<UL>
<LI>
to restore from a checkpoint, rename the db.* files and then run:</LI>
<BR><TT> <FONT COLOR="#990000">p4d -r <I>P4ROOT</I>
-jr checkpoint-file</FONT></TT>
<LI>
to restore from the journal (immediately after restoring from a checkpoint): </LI>
<BR><TT> <FONT COLOR="#990000">p4d -r <I>P4ROOT</I>
-jr journal-file</FONT></TT>
<LI>
to restore from both, rename the db.* files and then run:</LI>
<BR><TT> <FONT COLOR="#990000">p4d -r <I>P4ROOT</I>
-jr checkpoint-file journal-file</FONT></TT></UL>
(This operation can take several minutes to complete, depending on the
size of the checkpoint/journal files.)
<P>Both the checkpoint-file and journal-file are made to be restored from
exactly once, that is, you cannot restore from a checkpoint file and then
try to restore <U>again</U> to the same "db.*" database files from that
checkpoint - you'd have to move the db.* files out of the way first.
<p>
<A NAME="what do I do if the checkpoint of the database fails"></A>
<li><B>What do I do if the checkpoint of the database fails? </B>
<p>
It's probably best to stop the server, and contact
<A HREF="mailto:support@perforce.com">Perforce Technical Support</A>.
<p>
That said, there could be several reasons that the
checkpoint operation failed. Three possible cases follow:
<ol>
<li>
You ran out of space on the device onto which the checkpoint data
was written. This is an easy case: clean up the space issues and try
the checkpoint operation again.
<li>
There was/is data corruption in the Perforce database itself. In this
case, you'll need to talk with the Perforce Support folks. <u>If you
have the most recent successful checkpoint and the journal that was made
since then, you'll be able to restore the database easily.</u>
<li>
The disk on which the db.* files live died. In this case, you'll
also want to talk to Perforce Support. The procedure to recover from
that, they'll probably tell you, is to fix the disk errors and then
restore from a checkpoint and the journal that's been kept since then.
</ol>
<p>
<A NAME="do I have a good backup strategy"></A>
<li><B>So if I make checkpoints and have journaling enabled, do I have a
good backup strategy? </B>
<p>
Almost. The checkpoint+journal mechanism will protect your metadata,
but the contents of each file's revisions are stored in subdirectories
of the P4ROOT directory. Those should be backed up regularly, on the same
schedule as the checkpoint file.
</OL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="If the machine dies..."></A><B><FONT COLOR="#000000">If the machine
on which the Perforce depot dies, what do we do? If it runs out of space
on the depot filesystem, what do we do?</FONT></B></LI>
<P><I><FONT COLOR="#000000">If the machine croaks...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">If the machine croaks and you need to move the
Perforce server to another machine, you'll need to take several easy steps
(and one hard one):</FONT>
<OL>
<LI>
<FONT COLOR="#000000"><B>Immediately send mail</B><I> </I>to <TT><A HREF="mailto:support@perforce.com">support@perforce.com</A></TT>
asking for a license file for the replacement machine, unless it'll use
the <U>same</U> IP address as the one that died. Include the IP address
of the new machine, and be sure to stuff a $10 bill into the e-mail envelope.</FONT></LI>
<LI>
<FONT COLOR="#000000">If you can get to the disk that has the depot files,
copy them to the new machine. If not, read the section [below] about "what
if the disk croaks?".</FONT></LI>
<LI>
<FONT COLOR="#000000">Copy the new license file to the same directory as
all the "db.*" files in the depot [on the new machine].</FONT></LI>
<LI>
<FONT COLOR="#000000">Retrieve /etc/init.d/p4 from the old depot disk,
if possible, and run </FONT><TT><FONT COLOR="#990000">/etc/init.d/p4 start</FONT></TT><FONT COLOR="#000000">.
If that's not possible, set the variable P4ROOT and then run</FONT></LI>
<OL>
<PRE><FONT COLOR="#990000">$P4ROOT/p4d -r $P4ROOT -p <U>6999</U></FONT></PRE>
</OL>
<FONT COLOR="#000000">This reflects some Weblogic-isms: <U>6999</U> is
our Perforce port number, and /etc/init.d/p4 is the script we use to start/stop
the server. (This script was available at Perforce.com, but....)</FONT>
<LI>
<FONT COLOR="#000000">Send mail to your developers and make sure that they
change $P4PORT in their environment (to point to a new machine) prior to
using the client software.</FONT></LI>
</OL>
</UL>
<I><FONT COLOR="#000000">If the disk croaks...</FONT></I>
<BR>
<UL>
<OL>
<LI>
<FONT COLOR="#000000">Replace the disk, and restore the database from a
backup using the checkpoint and journal files. (That's covered <A HREF="#when do I need to take checkpoints?">above</A>,
in the previous item.)</FONT></LI>
<LI>
<FONT COLOR="#000000">Copy in a new license file, either obtained from
<TT><A HREF="mailto:support@perforce.com">support@perforce.com</A></TT>
or from an old backup.</FONT></LI>
<LI>
<FONT COLOR="#000000">Restore the $P4ROOT/depot subdirectory from your
backups.</FONT></LI>
<LI>
<FONT COLOR="#000000">Start up the server with </FONT><TT><FONT COLOR="#990000">/etc/init.d/p4
start</FONT></TT><FONT COLOR="#000000"> and stand back.</FONT></LI>
</OL>
</UL>
<I><FONT COLOR="#000000">If the disk runs out of space...</FONT></I>
<BR>
<UL>
<OL>
<LI>
If there wasn't database corruption, think seriously about moving $P4ROOT/depot
to another disk and symlink'ing it or mounting it back.</LI>
<LI>
If there was, call in your local Perforce admin-types. They'll want to
restore from a checkpoint+journal combination. In this case, no data will
be lost.</LI>
</OL>
</UL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="who has this checked out?"></A><B><FONT COLOR="#000000">How can
I find out who has a particular file checked out?</FONT></B></LI>
<OL><FONT COLOR="#000000">The command </FONT><FONT COLOR="#990000">p4 opened</FONT><FONT COLOR="#000000">
tells you what is opened on the current client.</FONT><FONT COLOR="#990000">
p4 opened -a</FONT><FONT COLOR="#000000"> tells you what's opened on every
client, so</FONT>
<OL>
<PRE><TT><FONT COLOR="#990000">p4 opened -a | grep <I>xxxxx</I></FONT></TT></PRE>
</OL>
<FONT COLOR="#000000">tells you every file that user <I><TT>xxxxx</TT></I>
has checked out (along with all files named xxxxx that are opened.) In
addition,</FONT>
<OL>
<PRE><TT><FONT COLOR="#990000">p4 opened -a <I>filename</I></FONT></TT></PRE>
</OL>
<FONT COLOR="#000000">tells you every client that has filename opened.</FONT></OL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="how do I add a new user?"></A><B><FONT COLOR="#000000">How do
I add a new user?</FONT></B></LI>
<BR>
<UL>
<LI>
To add a new user, just run a Perforce command as that user. It will attempt
to add them to the list of Perforce users. However...</LI>
<LI>
... many sites use <FONT COLOR="#990000"><TT>p4 protect</TT>
</FONT>to turn on/off access to codelines. It's important to run this command
(as a perforce adminstrator) to grant permissions to the user.</LI>
</UL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="What, exactly, does p4 protect do?"></A><B>What, exactly, does
p4 protect do?</B></LI>
</UL>
<UL>
<OL>In short, it restricts what users can see what, and what IP addresses
can access what codelines. Most of this should be left to the Perforce
administrators, but a quite briefing on how to decode the <TT><FONT COLOR="#990000">p4
protect</FONT></TT> output is:
<OL><TT><FONT COLOR="#990000">d:\weblogic\dev> p4 protect</FONT></TT>
<BR><FONT COLOR="#990000"><TT># </TT><I>comments
deleted</I></FONT>
<BR><TT><FONT COLOR="#990000">Protections:</FONT></TT>
<OL><TT><FONT COLOR="#990000">super user root 207.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user pambrose 207.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user pambrose 206.14.136.34 //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user rbp 207.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user rbp 206.14.136.65 //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user rbp 209.185.70.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user kevin 207.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super user jab 206.14.136.58 //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write user laurie 207.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write user carl 207.82.17.* //depot/dev/src/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">read user carl 206.14.136.44 //depot/dev/src030100b01/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write user joe 207.82.17.* //depot/...</FONT></TT></OL>
</OL>
<FONT COLOR="#000000">The way to read this is:</FONT>
<OL><TT><FONT COLOR="#990000"><I>permission </I>user<I> username
IP-Address depot-pathname</I></FONT></TT></OL>
<FONT COLOR="#000000">This means "this username, at this IP-Address,
has the given permissions on files that match this "depot" pathname." So,
for example:</FONT>
<UL>
<LI>
<FONT COLOR="#000000">User "root" can do protected operations on the entire
depot, but only from the internal company IP addresses. (Line 1)</FONT></LI>
<LI>
<FONT COLOR="#000000">User "pambrose" can do protected operations from
the internal net and from his home IP address. (Lines 2-3)</FONT></LI>
<LI>
<FONT COLOR="#000000">Carl can modify things in //depot/dev/src but can
only read files in /depot/dev/src030100b01, and in that case, only from
home.</FONT></LI>
</UL>
<FONT COLOR="#000000">By default, if the permission isn't explicitly granted
in the "p4 protect" spec, it's denied completely to that user.</FONT>
<P>Note that this doesn't cover the mechanism added, in release 98.2, for
"groups". That's covered in the manual.<</OL>
/OL></UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="how do I handle security?"></A><B><FONT COLOR="#000000">how do
I handle security? (i.e. adding new IP address using p4 protect)</FONT></B></LI>
<P><I><FONT COLOR="#000000">At WebLogic...</FONT></I>
<BR>
<OL><FONT COLOR="#000000">Some places use </FONT><TT><FONT COLOR="#990000">p4
protect</FONT></TT><FONT COLOR="#000000"> to limit what branches are visible
to what IP addresses. For example, the main codeline is restricted to engineers
who are on the internal network or dialing in from home on dedicated IP
addresses - the output of</FONT>
<UL>
<PRE><FONT COLOR="#990000">p4 protect</FONT></PRE>
</UL>
<FONT COLOR="#000000">at this company is something like this:</FONT>
<UL><TT><FONT COLOR="#990000">super pambrose 209.14.136.34 //depot/dev/src030100b01/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">super rbp 209.82.17.* //depot/dev/src030100b01/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write jab 209.82.17.* //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write jab 203.14.136.58 //depot/...</FONT></TT>
<BR><TT><FONT COLOR="#990000">write * * -//depot/dev/src/tutorial/...</FONT></TT></UL>
In this case, "jab" has write permission from internal IP addresses (209.82.17.*)
and from the one IP address he uses to connect to, from home (203.14.136.58).
In any case, write permission is disabled from all IP addresses ("*") for
the directory "//depot/dev/src/tutorial".
<P>The model is that we completely restrict access to anyone not explicitly
granted access via "<FONT COLOR="#990000">p4 protect</FONT>". (Normally,
Perforce doesn't require this - it was a decision made based on having
people connect to Perforce from outside the internal net.)
<BR>
<BR>(The above IP addresses aren't the real IP addresses used at WebLogic,
so anyone editing this FAQ should avoid "fixing" this.)
<P>If you cannot "<FONT COLOR="#990000">p4 sync</FONT>" some files to the
top revision, it could be that permissions haven't been granted for that
user.
<BR> </OL>
<I><FONT COLOR="#000000">Anywhere else...</FONT></I>
<BR>
<OL>Read <A HREF="http://www.perforce.com/perforce/doc.973/cmdguide/html/protecti.htm">here</A>
carefully. The most important details are:
<UL>
<LI>
There's no easy way to include comments in the "p4 protect" maps.
We've used the following syntax to include comments:</LI>
<OL>
<PRE>write * * -//depot/comment/***
write * * -//depot/comment/***_1a_remove_the_permissions_for_frozen_branches_here
write * * -//depot/comment/***</PRE>
</OL>
<LI>
<U>Order in the <FONT COLOR="#990000">p4 protect </FONT>specification is
significant</U>. The first permissions granted can be overridden by later
specs, so "less is more".</LI>
<BR>If you need real security, since it's far to easy to masquerade as
another user (but far harder to masquerade as another IP address!) try
to run one of the SSL mechanisms for Perforce work.</UL>
</OL>
</UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="how do I bring an offline worker back"></A><B><FONT COLOR="#000000">How
do I bring an off-line worker back online</FONT></B></LI>
</UL>
<UL><FONT COLOR="#000000">Run </FONT><TT><FONT COLOR="#990000">p4 help
diff</FONT></TT><FONT COLOR="#000000"> to see what commands there are to
compare someone's local disk area to what Perforce thinks was originally
there. In particular, the following commands can be really helpful for
finding what files the developer's modified while disconnected:</FONT>
<BR>
<UL>
<PRE><FONT COLOR="#990000">cd [workspace root]
find . -type f -print | p4 -x - add
p4 diff -se ... | p4 -x - edit
p4 diff -sd ... | p4 -x - delete</FONT></PRE>
</UL>
<I><FONT COLOR="#000000">Note that the "</FONT><FONT COLOR="#990000">p4
-x - add</FONT><FONT COLOR="#000000">" will generate errors for files that
are already in Perforce - that's okay.</FONT></I>
<P><FONT COLOR="#000000">[Aside: users should be told to "never run 'chmod'
or 'rm' on a file that Perforce gave you unless you're disconnected".]</FONT></UL>
<HR WIDTH="100%">
<UL>
<LI>
<A NAME="how to unsubmit a changelist?"></A><B><FONT COLOR="#000000">How
do I "unsubmit" a changelist? <A NAME="how to unstick files in a changelist?"></A>How
do I "unsubmit" files stuck in a *pending* changelist?</FONT></B></LI>
<P><FONT COLOR="#000000">If you have a file associated with <U>pending</U>
change #12345, you have several options:</FONT>
<UL>
<LI>
<FONT COLOR="#000000">Run the resolve command (or whatever the operation
was that prevented the submission from completing) and then run</FONT></LI>
<UL>
<PRE><FONT COLOR="#990000">p4 submit -c 12345</FONT></PRE>
</UL>
<LI>
<FONT COLOR="#000000">Revert the individual files if you want to discard
the changes, then delete the change. One such example is...</FONT></LI>
<UL>
<PRE><FONT COLOR="#000000">D:\weblogic></FONT><B><FONT COLOR="#990000">p4 describe -s 12345</FONT></B></PRE>
<PRE><FONT COLOR="#000000">Change 12345 by karena@karena.ave5 on 1998/04/16 14:44:05 *pending*</FONT></PRE>
<UL>
<PRE><FONT COLOR="#000000">fixed links</FONT></PRE>
</UL>
<PRE><FONT COLOR="#000000">Affected files ...</FONT></PRE>
<PRE><FONT COLOR="#000000">... //depot/internal/support/baystone/glossary.html#7 edit</FONT></PRE>
<PRE><FONT COLOR="#000000">D:\weblogic></FONT><B><FONT COLOR="#990000">p4 revert //depot/internal/support/baystone/glossary.html</FONT></B></PRE>
<PRE><FONT COLOR="#000000">D:\weblogic></FONT><B><FONT COLOR="#990000">p4 change -d 12345</FONT></B></PRE>
</UL>
<FONT COLOR="#000000">(The output above is somewhat contrived, and might
not be exactly what "</FONT><FONT COLOR="#990000">p4 describe</FONT><FONT COLOR="#000000">"
might've produced in this situation. The important parts - the "pending"
state, the change number, and the file list, should be close enough to
use this as an example.)</FONT>
<LI>
<FONT COLOR="#000000">Assign the files to another new change using</FONT><FONT COLOR="#990000">
p4 change </FONT><FONT COLOR="#000000">and </FONT><FONT COLOR="#990000">p4
reopen</FONT><FONT COLOR="#000000">:</FONT></LI>
<UL>
<PRE><FONT COLOR="#000000">D:\weblogic></FONT><FONT COLOR="#990000">p4 change</FONT></PRE>
<I><FONT COLOR="#000000">(lots of edits of the change description, saving
the output in the editor. Let's assume that the change number that it created
was change #34346.)</FONT></I>
<PRE><FONT COLOR="#000000">D:\weblogic></FONT><FONT COLOR="#990000">p4 reopen -c 34343 <B>//depot/internal/support/baystone/glossary.html</B></FONT></PRE>
</UL>
<PRE><FONT COLOR="#000000">Of course, you'll still want to delete that pending change at some point.</FONT></PRE>
</UL>
</UL>
<PRE>
<HR WIDTH="100%"></PRE>
<UL>
<LI>
<A NAME="should we back up clients?"></A><B><FONT COLOR="#000000">Should
I back up clients? If so, what files should I back up and what files should
I keep? How long should I keep backups of clients?</FONT></B></LI>
<P><U><FONT COLOR="#000000">This is specific to each company that implements
Perforce.</FONT></U>
<P><I><FONT COLOR="#000000">Back up the depot itself...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">The most important thing to back up is the Perforce
depot, which is a set of three things: the checkpointed database,
the subdirectory (called "depot") that stores each revision of each file
that Perforce is managing, and the license file.</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">If your Perforce Adminstrators are on the ball...</FONT></I>
<BR>
<UL><FONT COLOR="#000000">The information to recreate products should be
stored as files in Perforce, and the release <U>should</U> be recreateable
using only the files in Perforce. The "label" information is stored in
the Perforce databases (and hence, is in the backed-up checkpoint file),
so releases <U>should</U> be safe.</FONT>
<BR> </UL>
<I><FONT COLOR="#000000">But should I back up a Perforce client?</FONT></I>
<BR>
<OL>
<LI>
<FONT COLOR="#000000">Strictly speaking, it should not be necessary if
developers check in work frequently.</FONT></LI>
<LI>
<FONT COLOR="#000000">That said, it probably makes sense to archive the
Perforce client area that generates a release that's sent to customers,
so that when a patch needs to be made it can be built from <B>exactly the
same source and object files</B> that created the original release. (You
don't want to <U>have</U> to recompile everything to send out a patch,
unless you're regressing everything in sight. Compilers might've changed,
machine environments might've changed. Why borrow trouble?)</FONT></LI>
</OL>
<I><FONT COLOR="#000000">So I don't need to back up any Perforce clients
except my build clients?</FONT></I>
<BR>
<UL><FONT COLOR="#000000">Talk to your local Perforce Administrator-types.
They'll have an opinion on this, we can assure you.</FONT></UL>
</UL>
<BR><I>Last modified on 21 September 1998.</I>
</BODY>
</HTML>
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #1 | 1424 | Michael Roach | Creating initial guest branch of perforce\faq\... | ||
| //public/perforce/faq/admin.html | |||||
| #4 | 112 | Laura Wingerd |
Publish "Branching FAQ" (pull in changes from //guest/laura_wingerd/perforce/faq/... ) |
||
| #3 | 68 | Jeff Bowles | Updating to pull out some Weblogic-isms | ||
| #2 | 21 | Jeff Bowles | Moving a lot of checkpoint/journal questions into here. | ||
| #1 | 1 | laura |
Add FAQs. (Still needs index page.) |
||