<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="#clientspec">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="#viewotherclientspecs">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="#add_deletefiles">How do you add/delete files? Can you retrieve a deleted file? How?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#internalvars">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="#p4revert">What is/How do I do a p4 revert?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#p4integ">What is/How do I do an integration?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#who_has_opened">How can I find out who has a particular file checked out?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#p4resolve">How do I do a p4 resolve</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#p4unsubmit">How do I "unsubmit" a changelist</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#p4modifychangelist">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="#crlf">How does Perforce deal with CR/LF issues? Can this be overridden?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#binaries">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="#backups">Checkpoint/Journal Questions</A> <OL> <LI> <FONT COLOR="#000000"><A HREF="#whatischeckpoint"> What is a checkpoint?</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#checkpointfrequency"> When do I make a checkpoint? How often should I checkpoint my database?</A></FONT></LI> <LI><FONT COLOR="#000000"><A HREF="#journals"> What's a journal file? What's it good for?</A></FONT></LI> <LI><FONT COLOR="#000000"><A HREF="#checkpointfails"> What do I do if the checkpoint of the database fails?</A></FONT></LI> <LI><FONT COLOR="#000000"><A HREF="#backupstrategy"> 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="#machinedead">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="#security">How do I handle security? (i.e. adding new IP address using p4 protect)</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#newuser">How do I add a new user?</A></FONT></LI> <LI> <A HREF="#p4protect">What, exactly, does p4 protect do?</A></LI> <LI> <FONT COLOR="#000000"><A HREF="#offlineback">How do I bring an off-line worker back online</A></FONT></LI> <LI> <FONT COLOR="#000000"><A HREF="#backupworkspace">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="clientspec"></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:/src</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:/src/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:/src/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="add_deletefiles"></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/stella/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:\src\dev\src><U>p4 filelog //depot/dev/src/sandbox/stella/GNUdepends.def </U>//depot/dev/src/sandbox/stella/GNUdepends.def ... #4 change 19737 delete on 1998/05/05 by stella@stella.greenwich 'Change to move stella's erro' ... ... delete into //depot/dev/src030100b01/sandbox/stella/GNUdepends.def#2 ... #3 change 19611 edit on 1998/05/04 by stella@stella.sol 'Bits of hacking to support stag' ... ... branch into //depot/dev/sandbox/stella/GNUdepends.def#1 ... ... branch into //depot/dev/src030100b01/sandbox/stella/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/stella/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/stella/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="crlf"></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/stella/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="viewotherclientspecs"></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 "@myplace.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/$/@myplace.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="binaries"></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="internalvars"></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:1666</I></FONT></PRE> </UL> <FONT COLOR="#000000">or</FONT> <UL> <PRE><FONT COLOR="#990000">p4 set -s P4CLIENT=<I>stella.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="p4revert"></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="p4integ"></A><B><FONT COLOR="#000000">What is/How do I do an integration? <A NAME="p4resolve"></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="backups"></A>Checkpoint/Journal questions <p> <OL> <LI> <A name="whatischeckpoint"></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">p4 admin checkpoint</FONT></PRE> </DL> In older versions of Perforce that don't have the <tt>p4 admin</tt> subcommand: <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="checkpointfrequency"></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="journals"></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="checkpointfails"></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="backupstrategy"></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="machinedead"></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>1666</U></FONT></PRE> </OL> <FONT COLOR="#000000">Your site might use some other port number, like maybe 6999, and that'll go after the `-p' parameter.</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="#whentobackup">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_opened"></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="newuser"></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="p4protect"></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:\src\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 maggie 207.82.17.* //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">super user maggie 206.14.136.34 //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">super user brick 207.82.17.* //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">super user brick 206.14.136.65 //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">super user brick 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 stella 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 bigdaddy 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 "maggie" 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> </UL> <HR WIDTH="100%"> <UL> <LI> <A NAME="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 maggie 209.14.136.34 //depot/dev/src030100b01/...</FONT></TT> <BR><TT><FONT COLOR="#990000">super brick 209.82.17.* //depot/dev/src030100b01/...</FONT></TT> <BR><TT><FONT COLOR="#990000">write stella 209.82.17.* //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">write stella 203.14.136.58 //depot/...</FONT></TT> <BR><TT><FONT COLOR="#990000">write * * -//depot/dev/src/tutorial/...</FONT></TT></UL> In this case, "stella" 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="offlineback"></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="p4unsubmit"></A><B><FONT COLOR="#000000">How do I "unsubmit" a changelist? <A NAME="p4modifychangelist"></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:\src></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:\src></FONT><B><FONT COLOR="#990000">p4 revert //depot/internal/support/baystone/glossary.html</FONT></B></PRE> <PRE><FONT COLOR="#000000">D:\src></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:\src></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:\src></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="backupworkspace"></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 | 5415 | michael |
Move user FAQ to //guest branch and provide pointers. Remove old branching FAQ. Update page to reference Perforce Software documentation. |
||
//public/perforce/faq/admin.html | |||||
#6 | 3865 | Jeff Bowles | Minor changes to include comments on 'p4 admin' | ||
#5 | 1959 | Jeff Bowles | Minor hacks to clean up links. | ||
#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.) |