<HTML>
<HEAD>
<TITLE>
Tutorial - Perforce Public Depot
</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<CENTER>
<A NAME=toc></a>
<h2>
The Perforce Public Depot Tutorial
<br>
</H2>
<P>
<TABLE BORDER=0><TR>
<TD VALIGN=TOP COLSPAN=2 ALIGN=CENTER>
<TR>
<TD VALIGN=TOP>
<B>
<UL>
<LI><A HREF="#about">About This Tutorial</A></LI>
<LI><A HREF="#setup">Setting Up Your Environment</A></LI>
<LI><A HREF="#createcl">Creating Your Client Workspace</A></LI>
<LI><A HREF="#createbr">Creating Your Guest Branch</A></LI>
<LI><A HREF="#filling">Filling Your Workspace</A></LI>
<LI><A HREF="#working">Working on Files</A></LI>
</UL>
<TD VALIGN=TOP>
<B>
<UL>
<LI><A HREF="#pulling">Pulling Changes into Your Branch</A></LI>
<LI><A HREF="#publishing">Publishing Your Changes</A></LI>
<LI><A HREF="#sharing">Sharing Development</A></LI>
<LI><A HREF="#curating">Being A Project Curator</A></LI>
<LI><A HREF="#submitting">Submitting A Changelist</A></LI>
<LI><A HREF="#resolving">Resolving Files</A></LI>
</A>
<TD>
</UL>
<B>
</TABLE>
</CENTER>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="about">
</A>
<H2>About This Tutorial
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
The instructions in this tutorial
are for registered Public Depot contributors only.
See the Public Depot
<a href="index.html">home page</a>
for more information.
<p>
Because the bulk of the Public Depot is populated
by Perforce-related content,
we expect the typical contributor to be an experienced Perforce
user.
However, Jam/MR contributors may not necessarily be familiar
wth Perforce,
so this tutorial was written to be useful to new Perforce users
as well as experienced users.
<p>
<table align=left>
<tr><td>
<a href="http://www.perforce.com/perforce/doc.991/cmdref">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a>
</td></tr></table>
The tutorial examples use <b>p4</b>, Perforce's command line interface.
You can click on the book icon next to each command
to go to the command reference
section that describes it.
<P>
Complete documentation for all Perforce commands and programs
is available on our
<a href="http://www.perforce.com/perforce/technical.html">
technical documentation</a> page.
</P>
<P>
If you're using <b>P4Win</b>, our Windows GUI, you'll want to have
a copy of our
<i><b>p4</b> to <b>P4Win</b> Translation Guide</i>
handy so you can look up the GUI equivalents of the commands shown
here. The
<i>Translation Guide</i> can be downloaded from our
<a href="http://www.perforce.com/perforce/technical.html">
technical documentation</a> page.
</p>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="setup">
</A>
<H2>Setting Up Your Environment
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
Before you can use
Perforce with the Public Depot you'll need to set
these environment variables:
<p>
<table>
<tr><td valign=top>
<b>P4PORT</b>
</td><td>
To use the Public Depot, set this to
<b>public.perforce.com:1666</b>
<tr>
</td><td valign=top>
<b>P4USER</b>
</td><td>
Set this to your registered Public Depot user name.
For example, Cary Grant's registered user name is <b>cary_grant</b>.
<tr>
</td><td valign=top>
<b>P4PASSWD</b>
</td><td>
Set this to your Public Depot password.
<tr>
</td><td valign=top>
<b>P4CLIENT</b>
</td><td>
Set this to your client workspace name. You can use your
Public Depot username for your workspace name as well.
E.g., Cary Grant could name his client workspace <b>cary_grant</b>.
</td></tr>
</table>
<p>
There are many ways to set environment variables.
Two of those ways are shown here, as examples:
<p>
<ol>
<li>Unix users running <b>csh</b> can use <b>setenv</b>:
<br>
<code><b>
<br>% setenv P4PORT public.perforce.com:1666
<br>% setenv P4USER cary_grant
<br>% setenv P4PASSWD thornhill
<br>% setenv P4CLIENT cary_grant
</b></code>
<br>
<br>
<li>Windows users can use
<b>p4 set</b>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/set.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a>
to set Perforce environment
variables in the Windows registry:
<br>
<code><b>
<br>C:\> p4 set P4PORT=public.perforce.com:1666
<br>C:\> p4 set P4USER=cary_grant
<br>C:\> p4 set P4PASSWD=thornhill
<br>C:\> p4 set P4CLIENT=cary_grant
</b></code>
</ol>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="createcl">
</A>
<H2>Creating Your Client Workspace
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
The first thing you do when you use Perforce is set up a client
workspace on your local machine. This setup is only done once.
Bring up the client specification form editor, using:
<P>
<TABLE>
<TR>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/client.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 client </PRE>
</TABLE>
In the editor, you'll see something like the form shown below.
The text shown in <font color=red>red</font> is what you <i>must</i> edit
to set up your client workspace. The text in <font color=green>green</font>
may be edited if you wish:
<P>
<CENTER>
<TABLE BORDER=1 CELLPADDING=15% BGCOLOR=#DDDDDD WIDTH=75%>
<TR><TD><PRE>
Client: cary_grant
Description:
<font color=green>Created by cary_grant.</font>
Root: <font color=red>C:\</font>
Options: <font color=red>nomodtime noclobber</font>
View:
<font color=red>//public/... //cary_grant/...
<font color=red>//guest/... //cary_grant/...</font> </pre>
</TABLE>
</CENTER>
<p>
<UL type=square>
<LI>In the <i>Root</I> field, put the root of the directory you will
be using as a workspace on your local filesystem.
(The directory doesn't have to exist yet;
Perforce will create it for you.) For the sake of this tutorial,
we'll Cary Grant's workspace root is <b>c:\ws</b>.
</p>
<LI>In the <i>Options</i> field, add the word <b>locked</b>
to prevent other users from modifying your workspace specification.
</p>
<LI>The <i>View</i> field is a list of "view mapping" lines.
The left side of each line is a depot directory path, and the
right side shows how that path will be mapped into your workspace.
The
client name on the right side of each mapping stands for the workspace
root.
For working in the Public Depot you most likely need only map to your guest
branch as shown below. (If you are sharing development with another
Public Depot contributor, and wish to work in his or her guest
branch, see <a href="#sharing">"Sharing Development"</a>.)
</UL>
<P>
When you have modified your client spec, save it and exit the editor.
Here's an example of a completed client workspace specification:
<p>
<CENTER>
<TABLE BORDER=1 CELLPADDING=15% BGCOLOR=#DDDDDD WIDTH=75%>
<TR><TD><PRE>
Client: cary_grant
Description:
<font color=green>Cary Grant's workspace.
</font>
Root: <font color=red>C:\ws</font>
Options: <font color=red>nomodtime noclobber locked</font>
View:
<font color=red>//guest/cary_grant/... //cary_grant/...</font>
</TABLE>
</CENTER>
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="createbr">
</A>
<H2>Creating Your Guest Branch
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
When you register as a Public Depot contributor, you are given
write access to your guest branch, but your guest branch is not
actually created for you (because we don't know which projects you
want to work on).
So you must create your own guest branch. It will start out as a clone
of one of the projects in the <b>//public</b> path, and you will
submit additions or changes to it.
<p>
For example, if Cary Grant wanted
to contribute enhancements to some of the Perforce utilities,
he'd start out by branching the
<b>//public/perforce/utils</b>
project into his
<b>//guest/cary_grant</b> branch. Here's how he'd do it:
<p>
First, open the files for branching:
<P>
<TABLE>
<TR>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/integrate.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 integ -v //public/perforce/utils/... //guest/cary_grant/perforce/utils/... </PRE>
</TABLE>
(The "<b>-v</b>" flag speeds up the operation by opening "virtual" files --
that is, these files are opened, but will not be copied to and from your
workspace.)
<p>
Next, <a href="#submitting">submit</a> the opened files:
<P>
<TABLE>
<TR>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/submit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 submit</PRE>
</TABLE>
Note that these two commands haven't moved any files in or out of Cary
Grant's workspace. All they've done is created a set of files in the
Public Depot's <b>//guest/cary_grant/perforce/utils</b> path that
exactly mirror the files in <b>//public/perforce/utils</b>.
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="filling">
</A>
<H2>Filling Your Workspace
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
Once you have <a href="#setup">set up your workspace</A>
and
<a href="#createbr">created your guest branch</a>,
you can fill your workspace with files from the depot using:
<p>
<table><tr><td>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/sync.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<td><b><PRE>p4 sync</PRE></td>
</table>
This copies depot files to your workspace.
For example, when Gary Grant
runs <b>p4 sync</b>, files from the <b>//guest/gary_grant</b> branch
are copied into his local <b>c:\ws</b> directory.
When it's done, his
workspace is "in sync" with the depot.
<p>
<i>Note:</i>
<p>
<ul type=square>
<li>
Synced files have read-only permission in your workspace (until you start
<A HREF="#working">working on them</A>).
<p>
<li>
Perforce will sync to the head revisions of depot files,
by default.
<p>
<li>
If you run <b>p4 sync</b> more than once, nothing will happen
the second time unless there are newer versions in the depot that are not
yet in your workspace.
<p>
<li>
If you are running <b>p4 sync</b> and you get disconnected,
you can run it again to continue filling your workspace. Files that have
already been copied to your workspace will not be copied a second time.
</ul>
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="working">
</A>
<H2>Working on Files
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
Once you have <A HREF="#filling">filled your workspace</A>,
you can work on files. You can edit files, add files, delete files,
and revert files to their original state.
<p>
<i>Note:</i>
<ul type=square>
<li>None of the commands described here affect the files in the
depot. All they do is allow you to work on files.
Perforce tracks the files you're working on in a <i>changelist</i>.
As you open files, they go on your changelist.
You have to <a href="#submitting">submit your changelist</A>
to get your changes into the depot.
</ul>
<DL>
<P>
<DT><h3>Editing files</h3>
<dd>To edit files, use the
<b>p4 edit</b> command on them.
For example, here Cary Grant opens two P4DB source files for editing:
<P>
<TABLE>
<TD>
<TD><b><PRE>cd c:\ws\perforce\utils\p4db</PRE>
<TR>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/edit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 edit index.cgi chb.cgi</PRE>
</TABLE>
<DD>
Now these files are "opened for edit". Once opened for
edit, files become writeable,
so you can edit them, or modify them by any other means.
<P>
<DT><H3>Adding new files</h3>
<DD>To add new files, create them first, with an editor or other tool.
You must create them in a directory under your workspace root.
Then use the
<b>p4 add</b> command on them.
<p>
For example, Cary Grant is adding a new file to the P4DB suite.
First he creates the file with <b>vi</b>, then adds it:
<P>
<TABLE>
<TD>
<TD><b><PRE>cd c:\ws\perforce\utils\p4db</PRE>
<TR>
<TD>
<TD><b><PRE>vi jbv.cgi </PRE>
<TR>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/add.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 add jbv.cgi</PRE>
</TABLE>
<DD>
<b>p4 add</b> "opens files for add", which tells
Perforce you plan to add them to the depot.
<P>
<DT><H3>Deleting files</H3>
<DD>To delete files:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/delete.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 delete fdv.cgi fv.cgi flv.cgi
</TABLE>
<DD>
This removes the files from your workspace, and makes them "open for
delete", which tells Perforce you plan to delete them from
the depot.
<b>p4 delete</b> only works on files put in your
workspace by <b>p4 sync</b>.
<p>
<DT><H3>Reverting files</H3>
<DD>
If you ever want to undo changes you've made to any of your
opened files, use <b>p4 revert</b>. For example:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/revert.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 revert fdv.cgi flv.cgi
</TABLE>
<DD>
This restores files to
their original states and takes them off your changelist.
<p>
<font color=red><i>Warning: <b>p4 revert</b> is IRREVERSIBLE!</i></font>
When you revert a
file that was opened for edit, Perforce replaces the
file in your workspace with a fresh, read-only version
directly from the depot. Any
edits you've made to the file will be lost!
<p>
<i>Note:</i>
<p>
<ul type=square>
<li>
When you revert files opened for delete, Perforce restores them to your
workspace.
<p>
<li>
When you revert files opened for add, Perforce doesn't do
anything to the files; it simply takes them off your changelist.
The new files you created in your workspace will still be there.
</ul>
<p>
<DT><H3>Submitting files</H3>
<DD>
When you are satisfied with the changes in your workspace,
you can <a href="#submitting">submit</a>
them to the depot with:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/submit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 submit</PRE>
</TABLE>
</DD>
</DL>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="pulling">
</A>
<H2>Pulling Changes into Your Branch
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
The files in your guest branch are insulated from the
files in the <b>//public</b> path they were branched from.
From time to time, files in <b>//public</b> will be added as
Public Depot project curators integrate changes from guest
branches.
If the project you made your branch from gets updated, you will
need to pull those updates into your own guest branch.
<p>
So Cary Grant, for example, has been working on his P4DB enhancement.
As you recall, his guest branch files were originally branched from
the <b>//public/perforce/utils</b> path.
To find out if any changes need to be pulled from that path into
his own guest branch, Cary uses:
<UL>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/integrate.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 integ -n //public/perforce/utils/... //guest/cary_grant/perforce/utils/... </PRE>
</TABLE>
</UL>
If he sees files listed, he knows he'll have to pull changes into his
guest branch. Here's how he does it:
<p>
<ol>
<li> He submits (or reverts) any opened files in his workspace.
<p>
<li> He opens files for integration in his workspace using:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/integrate.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 integ //public/perforce/utils/... //guest/cary_grant/perforce/utils/... </PRE>
</TABLE>
(This is the same as the command above, without the <b>-n</b>.
It's also exactly the same as the command that created his branch, without
the <b>-v</b>.)
<p>
<li> He
<a href="#resolving">resolves</a>
the opened files using:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/resolve.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 resolve </PRE></b>
</TABLE>
<li> He submits the opened, resolved files with:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/submit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 submit </PRE></b>
</TABLE>
</ol>
At this point, Cary Grant's guest branch is fully integrated. That is,
all changes in <b>//public/perforce/utils</b> have been pulled into
<b>//guest/cary_grant/perforce/utils</b>.
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="submitting">
</A>
<H2>Submitting A Changelist
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
As you open files with <b>p4 edit, p4 add,</b> and <b>p4 delete</b>,
you are building up a <i>changelist</i>.
A changelist is also created when you open files with <b>p4 integ</b>.
However, until you <i>submit</i> your changelist, files in the
depot are unaffected by your intended changes.
"Submitting" sends modified file content from your workspace to the depot,
and updates depot versions of the files.
<p>
To submit your changelist, use:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/submit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 submit
</TABLE>
This puts you in an editor form,
where you must replace the
string "<b><enter description here></b>" with a valid description
of the changes you are submitting.
Cary Grant's changelist form looks like:
<P>
<CENTER>
<TABLE BORDER=1 CELLPADDING=15% BGCOLOR=#DDDDDD WIDTH=75%>
<TR><TD><PRE>
Change: new
Client: cary_grant
User: cary_grant
Status: new
Description:
<font color=red>Added job searching to the P4DB browser.</font>
Files:
//guest/cary_grant/perforce/utils/p4db/index.cgi # edit
//guest/cary_grant/perforce/utils/p4db/chb.cgi # edit
//guest/cary_grant/perforce/utils/p4db/jbv.cgi # add
//guest/cary_grant/perforce/utils/p4db/fv.cgi # delete
</TABLE>
</CENTER>
<p>
When you are done typing the description, save the file and exit the editor.
Your changelist will be submitted and the depot files updated.
<P>
Note that all files in all guest branches are readable to everyone,
so as soon as you submit your changelist, other contributors can
see and review your changes.
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="resolving">
</A>
<H2>Resolving Files
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
Resolving is how you merge specific changes from one file to another.
For each file, you'll see stats like:
<pre>
c:\ws\perforce\utils\p4db\index.cgi - merging //public/perforce/utils/p4db/index.cgi#7
Diff chunks: 0 yours + 2 theirs + 0 both + 0 conflicting
</pre>
...and a prompt like:
<pre>
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) [at]:
</pre>
Follow the prompt's advised action by hitting return.
The prompt shows <code>[</code>in square brackets<code>]</code>
which action it advises you to take.
<p>
<i>Note:</i>
<p>
<ul type=square>
<li>For each file resolved, Perforce does a 3-way merge between
files it refers to as "yours", "theirs", and "the base".
The merged result is written to your workspace file.
<p>
<ul>
<li>
If you are integrating new changes from one branch to another,
"yours" is the target file in your workspace,
"theirs" is the newer file in the originating branch, and
"the base" is the version of the file in the
originating branch that was last integrated from.
<p>
<li>
If you are syncing opened workspace files with newer depot files,
"yours" is the target file in your workspace,
"theirs" is the newer file in the depot, and
"the base" is the version of the file you had when you
opened it for edit.
</ul>
<p>
<li>If there are no conflicting diffs, the merged result will be saved
in your workspace file, and the <b>resolve</b> program will go on to
the next file.
<p>
<li>If there <i>are</i> conflicting diffs, you will be put into an editor
to resolve the conflicts. The conflicts will be marked by lines
beginning with <code>>>>></code>, <code>====</code>,
or <code><<<<</code>.
For example:
<pre>
<font color=red> >>>> ORIGINAL
</font> i = i + j
<font color=red> ==== THEIRS
</font> if ( i < n ) then i = i + j
<font color=red> ==== YOURS
</font> if ( i <= n ) then i = i + j
<font color=red> <<<< </font></pre>
While in the editor, your job is to look for the conflicts,
remove the conflict markers
(shown here in <font color=red>red</font>), and modify the remaining
text in a way that makes sense.
When you exit the editor, the prompt will advise you to accept the
merged result.
<p>
<li>You can diff files while you're in the <b>resolve</b> program. At
the prompt, type <b>?</b> and you will be shown the diff commands.
<p>
<li>You can choose to skip any
file and re-run <b>resolve</b> on it later. Your workspace
file will be untouched if you do this.
</ul>
</P>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="publishing">
</A>
<H2>Publishing Your Changes
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
As a contributor, you may only submit changes to your own
branch in the <b>//guest</b> depot.
To have your changes "published", you must ask a
project curator to integrate them from your branch to
the <b>//public</b> depot.
<p>
To request publication:
<ul>
<li> Make sure your guest branch is fully up to date with
the project it was integrated from.
(See <a href="#pulling">Pulling Changes into Your Branch</a>.)
<p>
<li> Send email to the project curator asking to have your changes
published.
The curator's name and email address can be found in the
<b>index.html</b> page for the project.
</ul>
</p>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="sharing">
</A>
<H2>Sharing Development
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
If you and other registered Public Depot contributors would like
to share development on a project, you can designate one of your
guest branches as a shared branch.
The owner of the shared branch should email
<a href="mailto:opensource@perforce.com">opensource@perforce.com</a>
requesting that his or her branch be opened for shared development, and
naming the other contributors who should be granted write access
to that branch.
<p>
For contributors working in a shared branch,
all of the above instructions apply, with these caveats:
<ul>
<li> Each contributor should use <b>p4 client</b> to set his or
her client view to the shared guest branch instead of to his/her
own guest branch.
<p>
<li> Although you are all working in the same shared guest branch,
each of you still has your own client workspace.
Your changes aren't actually shared until you submit
your changelist into the depot.
<p>
<li> When someone else submits a changelist, you'll need to
re-sync your workspace (as described in
<a href="#filling">Filling Your Workspace</a>) and, if
necessary, <a href="#resolving">resolve</a> opened files.
<p>
<li> If you try to submit a changelist without having
re-synced and resolved, your submit will fail.
This isn't a problem, it just does this to give you a chance
to resolve files first.
The failed submit assigns a number to the pending changelist.
After you resolve your opened files,
you must give the changelist's number on the submit
command, e.g:
<P>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/submit.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 submit -c 1453
</TABLE>
</ul>
</p>
<!------------------------------------------------------------------>
<BR><BR>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%><TR><TD BGCOLOR=FFCC66>
<A NAME="curating">
</A>
<H2>Being A Project Curator
</H2>
<TD WIDTH=5% BGCOLOR=FFCC66 ALIGN=RIGHT><FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</TABLE>
<!------------------------------------------------------------------>
<p>
If you are a curator of a project in the Public Depot (and you know
who you are) your first responsibility is to
maintain an <b>index.html</b> file at the top level of the project
subdirectory in the <b>//public</b> path.
This document should at least describe the purpose of the project,
and list your name and email address. (Or, for spam-proofing,
your decodable email address.)
<p>
Your second responsibility is to "publish" contributions to
the project by integrating changes from guest branches into
the <b>//public</b> project path.
You'll receive email requests to publish contributions.
When you receive a request:
<ol>
<li> Make sure the contributor's guest branch is up to date with
the public project path.
<p>
<li> Review the changes in question for functionality
and appropriateness for your project.
<p>
<li> Integrate the changes from the guest branch into the
public project path.
</ol>
<p>
For example, say you
are the curator of the <b>//public/perforce/utils</b> project and you
get email from Cary Grant requesting that
you publish his enhancements to the P4DB browser. Here are some tips
for reviewing and integrating his contribution:
<ul>
<li> Note that to integrate any contributor's changes into
<b>//public/perforce/utils</b>,
you'll need to have that path mapped in your client workspace view.
<p>
<li> Never integrate more than one contribution at a time. (E.g.,
don't combine Cary Grant's P4DB contribution with James Mason's
FAQ contribution.)
<p>
<li> Start by taking a look at Cary's changelist descriptions.
You can list them with:
<pre><b> p4 changes //guest/cary_grant/...</b></pre>
<p>
<li> To make sure Cary has integrated all published changes into
his guest path, add <b>//guest/cary_grant/...</b> to your
client view and try this:
<pre><b> p4 flush //guest/cary_grant/perforce/utils/...
p4 integ -n //public/perforce/utils/... //guest/cary_grant/perforce/utils/...</b></pre>
If this shows unintegrated files,
send Cary mail telling him he needs to
<a href="#pulling">pull</a> the latest
<b>//public/perforce/utils</b> changes into his
guest branch before you can publish his contribution.
(<b>p4 flush</b> simulates a sync without copying files to your
workspace.)
<p>
<li> Before opening the <b>//public/perforce/utils</b> files for
integration, remember to sync first:
<pre><b> p4 sync //public/perforce/utils/...
p4 integ //guest/cary_grant/perforce/utils/... //public/perforce/utils/... </b></pre>
<p>
<li> Do a "safe" resolve, and make sure all merges could be done
without conflicts:
<pre><b> p4 resolve -as //public/perforce/utils/...
p4 resolve -n //public/perforce/utils/...</b></pre>
The second resolve should show that everything is already resolved.
If this is not the case, either Cary did something wrong
pulling in the latest changes into his branch, or you aren't
synced to the latest <b>//public/perforce/utils</b> files.
<p>
<li> Diff the opened files in your workspace after they've been
resolved and before you submit them. You can use:
<UL>
<TABLE>
<TD>
<a href="http://www.perforce.com/perforce/doc.991/cmdref/diff.html">
<img border=0 src="http://www.perforce.com/images/openbook.gif"></a><p>
<TD><b><PRE>p4 diff</PRE></b></TD>
</TABLE>
</UL>
to see exactly what you'd be changing if you submitted this
contribution.
</ul>
<br><br><br>
<!------------------------------------------------------------------>
<P>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=100%>
<TR>
<TD WIDTH=15% BGCOLOR=FFCC66 ALIGN=LEFT VALIGN=CENTER>
<FONT SIZE="-2">
Copyright ©<br>
1998, 1999<br>
<a href="http://www.perforce.com">Perforce Software</a><br>
</FONT>
</TD>
<TD WIDTH=70% BGCOLOR=FFCC66 ALIGN=CENTER>
<FONT SIZE="-2">
You're browsing a file stored as<br>
<code>$Id: //guest/michael/tutorial.html#1 $</code><br>
in the
<A HREF=http://public.perforce.com/public/index.html>Perforce Public Depot</A>.
</FONT>
</TD>
<TD WIDTH=15% BGCOLOR=FFCC66 ALIGN=RIGHT>
<FONT SIZE="-2"><A HREF="#toc">
Back to<BR>Table of<BR>Contents</A></TD></TR>
</FONT>
</TD>
</TR>
</TABLE>
<!------------------------------------------------------------------>
</BODY>
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #1 | 4282 | michael | Branch index and curator pages for facelift. | ||
| //public/tutorial.html | |||||
| #11 | 968 | rmg |
Change mail addresses from "info@perforce.com" to "opensource@perforce.com" (now that the "opensource" address exists). |
||
| #10 | 282 | james |
update public depot tutorial to remove reference to "locked" option being in beta test - it's been a supported feature since 99.1 ! |
||
| #9 | 147 | Laura Wingerd | Fix missing HTML anchor. | ||
| #8 | 126 | Laura Wingerd | Update doc links to point to current Perforce command reference pages. | ||
| #7 | 53 | Laura Wingerd | Added user name and password setup instructions to tutorial. | ||
| #6 | 52 | Laura Wingerd | Minor web page format changes. | ||
| #5 | 51 | Laura Wingerd | Update copyright year. | ||
| #4 | 50 | Laura Wingerd | Minor PD doc changes. | ||
| #3 | 31 | Perforce maintenance | PD tutorial done. | ||
| #2 | 30 | Perforce maintenance | PD tutorial, 90% done. | ||
| #1 | 29 | Perforce maintenance | PD Tutorial, about half done. | ||