head	1.9;
access;
symbols
	TIGRIS_1_1_0RC2:1.4.6.1
	TIGRIS_1_1_0RC1:1.4.6.1
	TIGRIS_1_1:1.4.6.1.0.2
	TIGRIS_1_0_8:1.4.6.1
	TIGRIS_1_0_8RC3:1.4.6.1
	TIGRIS_1_0_8RC2:1.4.6.1
	TIGRIS_1_0_8RC1:1.4.6.1
	TIGRIS_1_0_7:1.4.6.1
	TIGRIS_1_0_7RC3:1.4.6.1
	TIGRIS_1_0_7RC2:1.4.6.1
	TIGRIS_1_0_7RC1:1.4.6.1
	TIGRIS_1_0_6:1.4
	TIGRIS_1_0_6RC5:1.4
	TIGRIS_1_0_6RC4:1.4
	TIGRIS_1_0_6RC3:1.4
	TIGRIS_1_0_6RC2:1.4
	TIGRIS_1_0_6RC1:1.4
	TIGRIS_1_0_5:1.4
	TIGRIS_1_0_5RC6:1.4
	TIGRIS_1_0_5RC5:1.4
	TIGRIS_1_0_5RC4:1.4
	TIGRIS_1_0_5RC3:1.4
	TIGRIS_1_0_5RC2:1.4
	TIGRIS_1_0_5RC1:1.4
	TIGRIS_1_0_4:1.4
	TIGRIS_1_0_3:1.4
	TIGRIS_1_0_2:1.4
	TIGRIS_1_0_1:1.4
	TIGRIS_1_0:1.4.0.6
	TIGRIS_1_0_0:1.4
	TIGRIS_1_0_0_RC1:1.4.0.2;
locks; strict;
comment	@# @;


1.9
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.8;

1.8
date	2001.06.20.23.21.25;	author lori;	state Exp;
branches;
next	1.7;

1.7
date	2001.06.20.22.26.05;	author lori;	state Exp;
branches;
next	1.6;

1.6
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.5;

1.5
date	2001.05.21.23.38.05;	author lori;	state Exp;
branches;
next	1.4;

1.4
date	2001.02.22.01.02.52;	author lori;	state Exp;
branches
	1.4.6.1;
next	1.3;

1.3
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.09.00.59.20;	author susank;	state Exp;
branches;
next	1.1;

1.1
date	2001.01.29.19.46.27;	author lori;	state Exp;
branches;
next	;

1.4.6.1
date	2001.06.20.23.52.32;	author lori;	state Exp;
branches
	1.4.6.1.2.1;
next	;

1.4.6.1.2.1
date	2001.08.27.18.45.03;	author tberry;	state Exp;
branches;
next	;


desc
@@


1.9
log
@html usage revision
@
text
@  <div class="docs" id="ddcvscvscontributing">
<h2>Contributing source code changes with command-line CVS</h2>

   <div class="toc">
    <h4>CVS tool documents: Index</h4>

    <ul>
     <li>
      <a href="ddCVS.html">About source code version control with CVS</a> 

      <ul>
       <li><a href="ddCVS_cvsglossary.html">A version control glossary</a></li>

       <li><a href="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a></li>

       <li>
        <strong>You are here:</strong> Contributing source code changes with CVS 

        <ul>
         <li><a href="#cvscommit">Committing files and directories</a></li>

         <li><a href="#cvsadd">Adding new files and directories</a></li>

         <li><a href="#work">Working with files</a></li>

         <li><a href="#filetypes">About file types</a></li>

         <li><a href="#cvsupdate">Keeping your working copy up to date (cvs update)</a></li>

         <li><a href="#cvstatus">Comparing your working files to the CVS repository</a></li>

         <li><a href="#otherdiff">Comparing files before you commit</a></li>

         <li><a href="#cvsmerging">Merging your changes</a></li>

         <li><a href="#cvsresolving">Resolving merge conflicts</a></li>

         <li><a href="#reverting">Revision history and reverting</a></li>
        </ul>
       </li>

       <li><a href="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a></li>
      </ul>
     </li>
    </ul>
   </div>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to main Help index</a></p>
  </div>

  <h3><a id="contributing" name="contributing">Contributing your changes into CVS</a></h3>

  <p><a id="cvscommit" name="cvscommit"></a>To <i>commit</i> your changes to a file into the shared repository, type:</p>

   <p><code>cvs commit -m "Type your changes message here" filename</code></p>

  <p>If you do not include a description of your change to the file, you will be prompted to add it by invoking your file editor before CVS can complete the commit action.</p>

  <p>To commit your changes to all files in a directory and any subdirectories:</p>
<pre>
<code>cd top_directory_to_commit
cvs commit -m "Type your change message here"
</code>
</pre>

  <p>All commits are logged automatically and posted to the project's cvs mailing list.</p>

  <h3><a id="cvsadd" name="cvsadd">Adding files/directories</a></h3>

  <p>To <i>add</i> a new file to the CVS repository after you have first created and edited it in your working directory, type:</p>

   <p><code>cvs add filename</code></p>

  <p>Then follow up with the "cvs commit filename" command. If you do not first add the file, CVS does not recognize it.</p>

  <p>If you have cvs write permissions, you can add subdirectories to your project's source tree using the "<b>cvs add</b>" command. You can then move existing files into new subdirectories with the "<b>cvs move</b>" command.</p>

   <div class="courtesylinks">
  <p><a href="http://cvsbook.red-bean.com/cvsbook.html#Committing">More about committing changes</a><br />
   <a href="http://cvshome.org/docs/manual/cvs_7.html#SEC66">More about adding files and directories</a></p>
   </div>

  <h3><a id="work" name="work">Working with files</a></h3>

  <p>Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project.</p>

  <p>When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <i>cvs commit</i>) your modified versions of files.</p>

  <p>More about "<a href="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1">What CVS is not</a>."</p>

  <h3><a id="filetypes" name="filetypes">About file types</a></h3>

  <p>The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues.</p>

  <p>More about <a href="http://cvshome.org/docs/manual/cvs_9.html#SEC80">Handling binary files</a> in CVS.</p>

  <h3><a id="cvsupdate" name="cvsupdate">Keeping your working files up to date with the repository</a></h3>

  <p>If you want to look before you leap, you can get a list of all files in your local directory not up to date with the project repository by using the following command:</p>

   <p><code>cvs -qn update</code></p>

  <p>Files in the affected directory or directories are listed with their current status indicated as follows:</p>

  <ul>
   <li>? = File is unrecognized by CVS (needs to be added and committed).</li>

   <li>A = File is added; file is recognized by CVS but still needs to be committed to the repository.</li>

   <li>M = File has been modified by another developer since you checked out your working copy. This means that you need to update.</li>

   <li>U = File is updated.</li>

   <li>C = File has merge conflicts that must be resolved by hand.</li>
  </ul>

  <p>To go ahead and actually perform an update to make your working directory up to sync with the repository, the command is:</p>

   <p><code>cvs update</code></p>

  <p>You can also update individual files by adding the filename to the command.</p>

  <p>Or, to include any new directories when updating, do:</p>

   <p><code>cvs update -d</code></p>

   <div class="courtesylinks">
  <p><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC132">More about the cvs update command</a><br />
   <a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC134">More about CVS update output</a></p>
   </div>

  <h3><a id="cvstatus" name="cvstatus">Comparing your working files to the repository</a></h3>

  <p>Another way to determine whether all of your working files are in sync with the latest versions in the repository is with the command:</p>

   <p><code>cvstatus</code></p>

  <p>or for status on individual files:</p>

   <p><code>cvs status filename</code></p>

  <p>This comparison may return one of the following messages:</p>

  <dl>
   <dt>Locally modified</dt>

   <dd>You have edited the file, and not yet committed your changes.</dd>

	<dt>Locally Added</dt>
     <dd>You have added the file with `add', and not yet committed your
     changes.</dd>

	<dt>Locally Removed</dt>
     <dd>You have removed the file with `remove', and not yet committed
     your changes.</dd>

	<dt>Needs Checkout</dt>
     <dd>Someone else has committed a newer revision to the repository.
     The name is slightly misleading; you will ordinarily use `update'
     rather than `checkout' to get that newer revision.</dd>

   <dt>Needs Patch</dt>

   <dd>Like Needs Checkout, but the CVS server will send a patch rather
     than the entire file. Sending a patch or sending an entire file
     accomplishes the same thing.</dd>

   <dt>Needs Merge</dt>
     <dd>Someone else has committed a newer revision to the repository, and
     you have also made modifications to the file.</dd>

   <dt>File had conflicts on merge</dt>

   <dd>This is like Locally Modified, except that a previous `update'
     command gave a conflict and CVS could not resolve the changes made.  If you have not already done so, you need to <a href="#cvsresolving">resolve the conflict</a>.</dd>

   <dt>Unknown</dt>
     <dd>CVS doesn't know anything about this file.  For example, you have
     created a new file and have not run `cvs add'.</dd>
  </dl>


  <p>In general, a good rule of thumb is to make sure your working files are up to date with the repository <i>just before you commit your changes to a file</i>. The reason for this is that sometimes your commit may be unsuccessful, for example, you may be trying to commit from the wrong directory or perhaps another developer has committed changes to that same file after you checked it out of the repository or last updated it. Trying to commit your changes to an older version of the same file often causes conflicts when CVS tries to merge these. The result of your commit attempt under such circumstances is a somewhat daunting failure message about "dying gasps" from CVS. (Unfortunately, you don't find this out until <i>after</i> you've gone through the process of mentally composing and entering a pithy change log message.)</p>

  <p>To see the differences between your copy of a file and the latest version in the repository:</p>

   <p><code>cvs diff filename</code></p>

  <p><a href="http://cvsbook.red-bean.com/cvsbook.html#Finding_Out_What_You__And_Others__Did_--_update_And_diff">More about comparing your work with the project repository</a></p>

  <h3><a id="otherdiff" name="otherdiff">Comparing versions of files <i>before</i> you commit (diff)</a></h3>

  <p>Perhaps you want to see the changes another developer has made to the same file <i>before</i> you commit your own changes. For example, suppose you are committing some very complex changes which you anticipate may conflict with another developer's work.</p>

  <p>In this case, a workable solution is to save off your working file under a different name (something like: "filename-new"). Then you can run the "<b>cvs update</b>" command and compare the latest version from the repository with your file before committing your changes. You can even compare the two files side-by-side using the following diff command:</p>

   <p><code>diff -y filename filename-new</code></p>

  <h3><a id="cvsmerging" name="cvsmerging">Merging your changes with other developers' changes</a></h3>

  <p>By giving the "<b>cvs update</b>" command, you are essentially telling CVS to merge the latest versions of files from the repository into your working copies.</p>

  <p>Sometimes, however, other modifications made to a file since you last updated do not mesh well with your version. Or, you've made changes that conflict with the repository version. CVS makes every attempt to resolve such conflicts automatically when you update and commit, but sometimes it cannot resolve everything. Conflicts within the file must be resolved by hand.</p>

  <h3><a id="cvsresolving" name="cvsresolving">Resolving merge conflicts</a></h3>

   <p>To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <b>&gt;&gt;&gt;&gt;&gt;&gt;</b> and <b>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;/B&gt;. When CVS cannot resolve a conflict, it includes both verions of the affected line or sections inthe file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again.</b></p>

   <div class="courtesylinks">
    <p><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40">An example of a conflict</a><br />
   <a href="http://cvsbook.red-bean.com/cvsbook.html#Detecting_And_Resolving_Conflicts">More about resolving conflicts</a></p>
   </div>

  <h3><a id="reverting" name="reverting">Revision history and reverting</a></h3>

  <p>Beyond the usefulness of being able to review a file's modification history using the "<b>cvs log</b>" command, those earlier file revisions can actually be restored as the most current revision (that is, restored to the "repository head") by the process of <i>reverting</i>. This becomes a particularly useful option if you need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock. When development projects experience broken builds or other problems, this becomes one of the most useful and powerful features of version control.</p>

  <p>A word of caution: it's easy to get confused by the terminology of "revisions" versus "versions." <i>Revisions</i> are specific updates to individual files, such 1.1, 1.2, 1.3. When you run the "cvs log filename" command, the results are all of that particular file's revision numbers. By contrast, <i>versions</i> are <b><i>sets</i></b> of file revisions that are tagged and named at a certain point in time. The confusion occurs because versions are sometimes named similarly to file revisions (1.0, 1.1, 1.2 etc.). But versions do not have to be named this way; they can be any set of characters the Project Owner designates, and probably should use a different numbering scheme.</p>

  <p>First, before you attempting to do any reverting, it's recommended that you examine the differences between the file version currently at the head of the repository and the version you want to revert to. The command to do this is:</p>

   <p><code>cvs diff -c -r version# -r version# filename</code></p>

  <p>This enables you to compare the two files before attempting to revert. The order for the file versions in this command is not critical, as long as you know can distinguish between the two versions.</p>

  <p>The command to revert requires strict observance in ordering the version numbers, however. Assuming you want to revert from a later version to an earlier version, the command is:</p>

   <p><code>cvs update -j later_version# -j earlier_version# filename</code></p>

  <p>Because there is more than one method for reverting, see also:<br />
   <a href="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes">More about reverting</a><br />
   <a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72">More about revision history</a></p>

  <p>You should also know that reverting may result in "sticky tag" errors. These can be resolved using the following update command with a special switch:</p>

   <p><code>cvs update -dAP</code></p>

  <p>(<a href="http://cvsbook.red-bean.com/cvsbook.html#Getting_Snapshots__Dates_And_Tagging_">What are sticky tag errors?</a>)</p>
  <!--

    <h3><a name="cvstips">Feedback on this document</a></h3>
  <p>
    The author of this help document has made every attempt to compile accurate, helpful information about using CVS for projects hosted on this site. If you think any content in the above document is wrong, inadequate, or something is just plain missing ... that's good. This is open source, so step up to the plate and contribute your suggestions for additions and improvements.
    </p> -->

  <p>More CVS help: <a href="ddCVS_cvsmanaging.html">Managing project files and directories with command line CVS</a></p>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>
  </div>
 


@


1.8
log
@fixed broken internal link
@
text
@a0 8
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Contributing changes with CVS</title>
 </head>

 <body>
d4 2
a5 1
  <p>CVS tool documents: Index</p>
d7 3
a9 3
  <div>
   <dl>
    <dt><a href="ddCVS.html">About source code version control with CVS</a></dt>
d11 2
a12 1
    <dt><a href="ddCVS_cvsglossary.html">A version control glossary</a></dt>
d14 1
a14 1
    <dd><a href="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</a></dd>
d16 2
a17 2
    <dd>
     <b>You are here: Contributing source code changes with CVS</b> 
d19 2
a20 2
     <ul>
      <li><b><a href="#cvscommit">Committing files and directories</a></b></li>
d22 1
a22 1
      <li><b><a href="#cvsadd">Adding new files and directories</a></b></li>
d24 1
a24 1
      <li><b><a href="#work">Working with files</a></b></li>
d26 1
a26 1
      <li><b><a href="#filetypes">About file types</a></b></li>
d28 1
a28 1
      <li><b><a href="#cvsupdate">Keeping your working copy up to date (cvs update)</a></b></li>
d30 1
a30 1
      <li><b><a href="#cvstatus">Comparing your working files to the CVS repository</a></b></li>
d32 1
a32 1
      <li><b><a href="#otherdiff">Comparing files before you commit</a></b></li>
d34 1
a34 1
      <li><b><a href="#cvsmerging">Merging your changes</a></b></li>
d36 1
a36 1
      <li><b><a href="#cvsresolving">Resolving merge conflicts</a></b></li>
d38 3
a40 3
      <li><b><a href="#reverting">Revision history and reverting</a></b></li>
     </ul>
    </dd>
d42 5
a46 1
    <dd><a href="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</a></dd>
d48 2
a49 2
    <dt><a href="/servlets/HelpTOC">Back to main Help index</a></dt>
   </dl>
d55 2
a56 4
<pre>
<code>  cvs commit -m "Type your changes message here" filename
 </code>
</pre>
d72 2
a73 4
<pre>
   <code>cvs add filename</code>
 
</pre>
d79 1
d82 1
d101 2
a102 4
<pre>
   <code>cvs -qn update</code> 
 
</pre>
d119 2
a120 4
<pre>
   <code>cvs update</code>
 
</pre>
a124 4
<pre>
   <code>cvs update -d</code>
 
</pre>
d126 3
d131 1
d136 2
a137 4
<pre>
   <code>cvstatus</code>
 
</pre>
d140 2
a141 4
<pre>
   <code>cvs status filename</code>
 
</pre>
d146 1
a146 1
   <dt class="c3">Locally modified</dt>
d150 1
a150 1
	<dt class="c3">Locally Added</dt>
d154 1
a154 1
	<dt class="c3">Locally Removed</dt>
d158 1
a158 1
	<dt class="c3">Needs Checkout</dt>
d163 1
a163 1
   <dt class="c3">Needs Patch</dt>
d169 1
a169 1
   <dt class="c3">Needs Merge</dt>
d173 1
a173 1
   <dt class="c3">File had conflicts on merge</dt>
d178 1
a178 1
   <dt class="c3">Unknown</dt>
d187 2
a188 4
<pre>
   <code>cvs diff filename</code> 
 
</pre>
d197 2
a198 4
<pre>
   <code>diff -y filename filename-new</code>
 
</pre>
d208 1
a208 1
  <p>To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <b>&gt;&gt;&gt;&gt;&gt;&gt;</b> and <b>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;/B&gt;. When CVS cannot resolve a conflict, it includes both versions of the affected line or sections in the file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again.</b></p>
d210 2
a211 1
  <p class="c4"><a href="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40">An example of a conflict</a><br />
d213 1
d222 2
a223 4
<pre>
   <code>cvs diff -c -r version# -r version# filename</code>
 
</pre>
d228 2
a229 4
<pre>
   <code>cvs update -j later_version# -j earlier_version# filename</code>
 
</pre>
d236 2
a237 4
<pre>
   <code>cvs update -dAP</code>
 
</pre>
d248 6
a253 4
 <div class="courtesylinks"><a href="/servlets/HelpTOC">Back to main Help index</a></div>
 </div>
</body>
</html>
@


1.7
log
@added additional info about cvstatus command
@
text
@d188 1
a188 1
     command gave a conflict and CVS could not resolve the changes made.  If you have not already done so, you need to <a href="cvsresolving">resolve the conflict</a>.</dd>
@


1.6
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d160 1
a160 1
   <dd>Your version has not yet been committed.</dd>
d162 22
a183 1
   <dt class="c3">Needs patch</dt>
d185 1
a185 1
   <dd>Your version needs to be updated because someone else has made changes.</dd>
d187 2
a188 1
   <dt class="c3">File had conflicts on merge</dt>
d190 3
a192 1
   <dd>CVS could not resolve changes made to this file and committed. (<a href="cvsresolving">Resolving merge conflicts</a>.)</dd>
d195 1
d224 1
a224 1
  <p>To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <b>&gt;&gt;&gt;&gt;&gt;&gt;</b> and <b>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;/B&gt;. When CVS cannot resolve a conflict, it includes both verions of the affected line or sections inthe file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again.</b></p>
@


1.5
log
@fixed broken internal link to doc subsection
@
text
@d1 248
a248 226
<HTML>
<HEAD>
<TITLE>Contributing changes with CVS</TITLE>
</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <SPAN CLASS="Header">Contributing source code changes with command-line CVS</SPAN>
<P>
<SPAN CLASS="PlainText"><B>CVS tool documents: Index</B>
<P>
<UL>
<DL>
<DT><A HREF="ddCVS.html">About source code version control with CVS</A>
<DT><A HREF="ddCVS_cvsglossary.html">A version control glossary</A>
<DD><A HREF="ddUsingCVS_command-line.html">Using command-line CVS to access project source files</A>
<DD><B>You are here: Contributing source code changes with CVS
<UL>
	<LI><A HREF="#cvscommit">Committing files and directories</A>
	<LI><A HREF="#cvsadd">Adding new files and directories</A>
	<LI><A HREF="#work">Working with files</A>
	<LI><A HREF="#filetypes">About file types</A>
	<LI><A HREF="#cvsupdate">Keeping your working copy up to date (cvs update)</A>
	<LI><A HREF="#cvstatus">Comparing your working files to the CVS repository</A>
	<LI><A HREF="#otherdiff">Comparing files before you commit</A>
	<LI><A HREF="#cvsmerging">Merging your changes</A>
	<LI><A HREF="#cvsresolving">Resolving merge conflicts</A>
	<LI><A HREF="#reverting">Revision history and reverting</A>
</UL></B>
<DD><A HREF="ddCVS_cvsmanaging.html">Managing project files and directories with CVS</A>
<DT><A HREF="/servlets/HelpTOC">Back to main Help index</A>
</DL>
</UL>
<P>

<HR NOSHADE SIZE=1>
<SPAN CLASS="InputHeader"><A NAME="contributing"></A>Contributing your changes into CVS</SPAN>
<P>
<A NAME="cvscommit"></A>To <I>commit</I> your changes to a file into the shared repository, type:
<BLOCKQUOTE>
       <B>cvs commit -m "Type your changes message here" filename</B>
</BLOCKQUOTE>
<P>
If you do not include a description of your change to the file, you will be prompted to add it by invoking your file editor before CVS can complete the commit action. 
<P>
To commit your changes to all files in a directory and any subdirectories:
<BLOCKQUOTE>
          <B>cd top_directory_to_commit</B><BR>
          <B>cvs commit -m "Type your change message here"</B>
</BLOCKQUOTE>
<P>
All commits are logged automatically and posted to the project's cvs mailing list.
<P>
<HR NOSHADE SIZE=1>
<A NAME="cvsadd"></A><SPAN CLASS="InputHeader">Adding files/directories</SPAN>

        <P>To <I>add</I> a new file to the CVS repository after you have first created and edited it in your working directory, type:
<BLOCKQUOTE>
          <B>cvs add filename</B><BR>
</BLOCKQUOTE>
         Then follow up with the &quot;cvs commit filename&quot command. If you do not first add the file, CVS does not recognize it.</LI>

<P>
If you have cvs write permissions, you can add subdirectories to your project's source tree using the &quot<B>cvs add</B>&quot command. You can then move existing files into new subdirectories with the &quot;<B>cvs move</B>&quot; command.
<P>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Committing" TARGET="_new">More about committing changes</A><BR>
<A HREF="http://cvshome.org/docs/manual/cvs_7.html#SEC66" TARGET="_new">More about adding files and directories</A>
<P>

<HR NOSHADE SIZE=1>
<SPAN CLASS="InputHeader"><A NAME="work"></A>Working with files</SPAN>
<P>
Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project.
<P>
When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <I>cvs commit</I>) your modified versions of files.
<P>
More about "<A HREF="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1" TARGET=_NEW>What CVS is not</A>."
<P>

<HR NOSHADE SIZE=1>
<SPAN CLASS="InputHeader"><A NAME="filetypes"></A>About file types</SPAN>
<P>
<P>
The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues.
<P>
More about <A HREF="http://cvshome.org/docs/manual/cvs_9.html#SEC80" TARGET="_new">Handling binary files</A> in CVS.
<P>

<HR NOSHADE SIZE=1>
<A NAME="cvsupdate"></A><SPAN CLASS="InputHeader">Keeping your working files up to date with the repository</SPAN>
<P>
If you want to look before you leap, you can get a list of all files in your local directory not up to date with the project repository by using the following command:<BR>
<BLOCKQUOTE>
          <B>cvs -qn update</B> </LI>
</BLOCKQUOTE>
Files in the affected directory or directories are listed with their current status indicated as follows:
<UL>
<LI>? = File is unrecognized by CVS (needs to be added and committed).
<LI>A = File is added; file is recognized by CVS but still needs to be committed to the repository.
<LI>M = File has been modified by another developer since you checked out your working copy. This means that you need to update.
<LI>U = File is updated.
<LI>C = File has merge conflicts that must be resolved by hand.
</UL>
<P>
To go ahead and actually perform an update to make your working directory up to sync with the repository, the command is:
<BLOCKQUOTE>
	<B>cvs update</B>
</BLOCKQUOTE>
You can also update individual files by adding the filename to the command.
<P>Or, to include any new directories when updating, do:
<BLOCKQUOTE>
        <B>cvs update -d</B> 
</BLOCKQUOTE>
<P> 
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC132" TARGET="_new">More about the cvs update command</A><BR>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC134" TARGET="_new">More about CVS update output</A>
<P>

<HR NOSHADE SIZE=1>
<A NAME="cvstatus"></A><SPAN CLASS="InputHeader">Comparing your working files to the repository</SPAN>
<P>
Another way to determine whether all of your working files are in sync with the latest versions in the repository is with the command:
<BLOCKQUOTE>
<B>cvstatus</B><BR>
</BLOCKQUOTE>
or for status on individual files:<BR> 
<BLOCKQUOTE>
<B>cvs status filename</B>
</BLOCKQUOTE>
<P>
This comparison may return one of the following messages:
<P>
<DL>
<DT><B><I>Locally modified</I></B> <DD>Your version has not yet been committed.
<DT><B><I>Needs patch</I></B> <DD>Your version needs to be updated because someone else has made changes.
<DT><B><I>File had conflicts on merge</I></B> <DD>CVS could not resolve changes made to this file and committed. (<A HREF="cvsresolving">Resolving merge conflicts</A>.)
</DL>
<P>
In general, a good rule of thumb is to make sure your working files are up to date with the repository <I>just before you commit your changes to a file</I>. The reason for this is that sometimes your commit may be unsuccessful, for example, you may be trying to commit from the wrong directory or perhaps another developer has committed changes to that same file after you checked it out of the repository or last updated it. Trying to commit your changes to an older version of the same file often causes conflicts when CVS tries to merge these. The result of your commit attempt under such circumstances is a somewhat daunting failure message about "dying gasps" from CVS. (Unfortunately, you don't find this out until <I>after</I> you've gone through the process of mentally composing and entering a pithy change log message.)
<P>
To see the differences between your copy of a file and the latest version in the repository:<BR>
<BLOCKQUOTE>
          <B>cvs diff filename</B> </LI>
</BLOCKQUOTE>
<P>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Finding_Out_What_You__And_Others__Did_--_update_And_diff" TARGET=_NEW>More about comparing your work with the project repository</A>
<P>

<HR NOSHADE SIZE=1>
<A NAME="otherdiff"></A><SPAN CLASS="InputHeader">Comparing versions of files <I>before</I> you commit (diff)</SPAN>
<P>
Perhaps you want to see the changes another developer has made to the same file <I>before</I> you commit your own changes. For example, suppose you are committing some very complex changes which you anticipate may conflict with another developer's work.
<P>
In this case, a workable solution is to save off your working file under a different name (something like: "filename-new"). Then you can run the &quot<B>cvs update</B>&quot command and compare the latest version from the repository with your file before committing your changes. You can even compare the two files side-by-side using the following diff command:
<BLOCKQUOTE>
<B>diff -y filename filename-new</B>
</BLOCKQUOTE>
<P>

<HR NOSHADE SIZE=1>
<A NAME="cvsmerging"></A><SPAN CLASS="InputHeader">Merging your changes with other developers' changes</SPAN>
<P>
By giving the &quot<B>cvs update</B>&quot command, you are essentially telling CVS to merge the latest versions of files from the repository into your working copies.
<P>
Sometimes, however, other modifications made to a file since you last updated do not mesh well with your version. Or, you've made changes that conflict with the repository version. CVS makes every attempt to resolve such conflicts automatically when you update and commit, but sometimes it cannot resolve everything. Conflicts within the file must be resolved by hand.
<P>

<HR NOSHADE SIZE=1>
<A NAME="cvsresolving"></A><SPAN CLASS="InputHeader">Resolving merge conflicts</SPAN>
<P>
To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by <B>>>>>>></B> and <B><<<<<<<</B>. When CVS cannot resolve a conflict, it includes both verions of the affected line or sections inthe file, with the latest version usually first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revisions numbers. Then you can save the file and commit again.

<P>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40" TARGET="_new">An example of a conflict</A><BR>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Detecting_And_Resolving_Conflicts" TARGET="_new">More about resolving conflicts</A>
<P>

<HR NOSHADE SIZE=1>
<A NAME="reverting"></A><SPAN CLASS="InputHeader">Revision history and reverting</SPAN>
<P>
Beyond the usefulness of being able to review a file's modification history using the &quot<B>cvs log</B>&quot command, those earlier file revisions can actually be restored as the most current revision (that is, restored to the "repository head") by the process of <I>reverting</I>. This becomes a particularly useful option if you need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock. When development projects experience broken builds or other problems, this becomes one of the most useful and powerful features of version control.
<P>
A word of caution: it's easy to get confused by the terminology of "revisions" versus "versions." <I>Revisions</I> are specific updates to individual files, such  1.1, 1.2, 1.3. When you run the "cvs log filename" command, the results are all of that particular file's revision numbers. By contrast, <I>versions</I> are <B><I>sets</I></B> of file revisions that are tagged and named at a certain point in time. The confusion occurs because versions are sometimes named similarly to file revisions (1.0, 1.1, 1.2 etc.). But versions do not have to be named this way; they can be any set of characters the Project Owner designates, and probably should use a different numbering scheme.

<P>
First, before you attempting to do any reverting, it's recommended that you examine the differences between the file version currently at the head of the repository and the version you want to revert to. The command to do this is:
<BLOCKQUOTE>
<B>cvs diff -c -r version# -r version# filename</B>
</BLOCKQUOTE>
<P>
This enables you to compare the two files before attempting to revert. The order for the file versions in this command is not critical, as long as you know can distinguish between the two versions. 
<P>
The command to revert requires strict observance in ordering the version numbers, however. Assuming you want to revert from a later version to an earlier version, the command is:
<BLOCKQUOTE>
<B>cvs update -j later_version# -j earlier_version# filename</B>
</BLOCKQUOTE>
<P>
Because there is more than one method for reverting, see also:<BR>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes" TARGET="_new">More about reverting</A><BR>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72" TARGET="_new">More about revision history</A><BR>
<P>

You should also know that reverting may result in "sticky tag" errors. These can be resolved using the following update command with a special switch: 
<BLOCKQUOTE>
<B>cvs update -dAP</B>
</BLOCKQUOTE>
(<A H REF="http://cvsbook.red-bean.com/cvsbook.html#Getting_Snapshots__Dates_And_Tagging_" TARGET="_new">What are sticky tag errors?</A>)
<P>

<!--
<P>
<A NAME="cvstips"><span class="InputHeader">Feedback on this document</span></A>
<P>
The author of this help document has made every attempt to compile accurate, helpful information about using CVS for projects hosted on this site. If you think any content in the above document is wrong, inadequate, or something is just plain missing ... that's good. This is open source, so step up to the plate and contribute your suggestions for additions and improvements.
<P>
-->

<HR NOSHADE SIZE=1>
More CVS help: <A HREF="ddCVS_cvsmanaging.html">Managing project files and directories with command line CVS</A><BR>
<A HREF="/servlets/HelpTOC">Back to main Help index</A></P></SPAN>

</SPAN> 
</TR>
</TABLE>
</BODY>
</HTML>
@


1.4
log
@index revisions and other general html edits
@
text
@d150 1
a150 1
<A NAME="diffs"></A><SPAN CLASS="InputHeader">Comparing versions of files <I>before</I> you commit (diff)</SPAN>
@


1.4.6.1
log
@fixed broken internal link and added info to cvs status
@
text
@d133 5
a137 51
<dl>
 <dt><b>Locally Added</b></dt>
     <dd>You have added the file with `add', and not yet committed your
     changes.</dd>

	<dt><b>Locally Removed</b></dt>
     <dd>You have removed the file with `remove', and not yet committed
     your changes.</dd>

	<dt><b>Needs Checkout</b></dt>
     <dd>Someone else has committed a newer revision to the repository.
     The name is slightly misleading; you will ordinarily use `update'
     rather than `checkout' to get that newer revision.</dd>

   <dt><b>Needs Patch</b></dt>

   <dd>Like Needs Checkout, but the CVS server will send a patch rather
     than the entire file. Sending a patch or sending an entire file
     accomplishes the same thing.</dd>

   <dt><b>Needs Merge</b></dt>
     <dd>Someone else has committed a newer revision to the repository, and
     you have also made modifications to the file.</dd>

   <dt><b>File had conflicts on merge</b></dt>

   <dd>This is like Locally Modified, except that a previous `update'
     command gave a conflict and CVS could not resolve the changes made.  If you have not already done so, you need to open the file in an editor and <a href="ddCVS_cvscontributing.html#cvsresolving">resolve the conflict</a>.</dd>

   <dt><b>Unknown</b></dt>
     <dd>CVS doesn't know anything about this file.  For example, you have
     created a new file and have not run `cvs add'.</dd>
  </dl>


















@


1.4.6.1.2.1
log
@fixed broken link
Issue number:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d25 1
a25 1
	<LI><A HREF="#diffs">Comparing files before you commit</A>
@


1.3
log
@added <title> tags to all files
@
text
@d3 1
a3 3

<TITLE>Contributing Changes with Command-Line CVS</TITLE>

d8 3
a10 8
    <TD CLASS="Header" NOWRAP>Contributing changes with command-line CVS</TD>
  </TR>
</TABLE>

<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" WIDTH="100%">
  <TR>
<SPAN CLASS="PlainText">

d14 18
a31 14
<DT><A HREF="#work">Working with files</A>
<DT><A HREF="#filetypes">About file types</A>
<DT><A HREF="#contributing">Contributing your changes</A>
	<DD><A HREF="#cvscommit">Committing files and directories</A>
	<DD><A HREF="#cvsadd">Adding new files and directories</A>
<DT><A HREF="#cvsimport">Importing existing source files</A>
<DT><A HREF="#cvsandrcs">CVS and RCS</A>
<DT><A HREF="#keywords">Using keywords</A>
<DT><A HREF="#cvsupdate">Keeping your working copy up to date (cvs update)</A>
<DT><A HREF="#cvstatus">Comparing your working files to the CVS repository</A>
<DT><A HREF="#otherdiff">Comparing files before you commit</A>
<DT><A HREF="#cvsmerging">Merging your changes</A>
<DT><A HREF="#cvsresolving">Resolving merge conflicts</A>
<DT><A HREF="#reverting">Revision history and reverting</A>
a33 7

<P>
<SPAN CLASS="InputHeader"><A NAME="work"></A>Working with files</SPAN>
<P>
Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project.
<P>
When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <I>cvs commit</I>) your modified versions of files.
a34 4
More about "<A HREF="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1" TARGET=_NEW>What CVS is not</A>."
<P>
<BR>
<BR>
d36 2
a37 4
<SPAN CLASS="InputHeader"><A NAME="filetypes"></A>About file types</SPAN>
<P>
<P>
The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues.
d39 1
a39 8
More about <A HREF="http://cvshome.org/docs/manual/cvs_9.html#SEC80" TARGET="_new">Handling binary files</A> in CVS.
<P>
<BR>
<BR>

<SPAN CLASS="InputHeader"><A NAME="contributing"></A>Contributing your changes into CVS</SPAN>
<UL>
<P><A NAME="cvscommit"></A><LI>To <I>commit</I> your changes to a file into the shared repository, type:
d41 1
a41 1
       <B>cvs commit -m "Type your changes message here" FILENAME</B>
d45 2
a46 1
<P><LI>To commit your changes to all files in a directory and any subdirectories:
a50 1
</UL>
d54 1
a54 1

d61 1
a61 1
         Then follow up with the &quotcvs commit filename&quot command. If you do not first add the file, CVS does not recognize it.</LI>
a68 2
<BR>
<BR>
d70 2
a71 1
<A NAME="cvsimport"></A> <B>Importing existing code?</B>
d73 1
a73 5
If you have existing files to add to the project, you can import these into CVS using the following command:
<BLOCKQUOTE>
		<B>cvs import filename</B>
</BLOCKQUOTE>

d75 1
a75 1
Importing allows you to add a lot of files at once, something like a super "cvs add." To import <I>all</I> existing directories and files, in your top level directory type:
d77 1
a77 5
<B>cvs import -m &quotlog message&quot projectname</B>
<P>
This creates the files and directories in the CVS repository for your project on this site. If you want to preserve these files and directories in their original state, you may want to tag or archive this set of original files before you or any other developers begin checking out working copies of project files.
<P>
If your existing files are already under versioning control -- either in another CVS repository or in a versioning different system such as RCS -- there is no automated method for importing existing files that retains file histories. Using the cvs import command, copying files over, or creating them as new files does not retain these histories.
a78 2
<BR>
<BR>
d80 2
a81 5
<A NAME="copyfromrcs"></A>Neither cvs import nor cvs copy preserves  the RCS revision histories of existing files brought in to CVS, but there is a way to do this by using:
<BLOCKQUOTE>
<B>cvs cp filename,v</B>
</BLOCKQUOTE>
If you do not copy files using the "filename,v", all versioning information for each file is lost.
a82 1
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC112" TARGET="_new">More about &quot;<B>cvs import&quot</B></A>
d84 1
a84 4
<BR>
<BR>

<SPAN CLASS="InputHeader"><A NAME="cvsandrcs"></A>CVS and RCS</SPAN>
d86 1
a86 6
If you're already familiar with RCS, both RCS and CVS use a similar format for storing the version control histories of individual files. But you should be aware of at least two critical differences in adapting CVS:
<P>
<UL>
<LI>One of the central principals in RCS is file locking, which prevents other developers from checking out or modifying a file when you have checked it out. The benefit to file locking is that developers never have to deal with conflicting modifications within files. RCS protects files by only allowing them to be modified by one person at a time. Therefore, the drawback to RCS is: you can't commit your changes to a file while another developer has it checked out.
<LI>The central tenant of CVS is to allow developers to check out, modify, and commit files concurrently, truly a benefit to projects with remote, geographically dispersed developers. The tradeoff is that on a CVS version controlled project, you can count on dealing with merge conflicts in files. The only method for resolving such conflicts is by hand-editing the file. Thus, project workflow with CVS ends up being a little different.
</UL>
d89 1
a89 21
<A HREF="http://www.cvshome.org/cyclic/cyclic-pages/rcs.html" TARGET="_new">More about RCS and CVS</A>
<P>
<BR>
<BR>

<A NAME="keywords"></A><SPAN CLASS="InputHeader">Keyword substitution</SPAN>
<P>
Keyword substitution (a.k.a keyword expansion) is an RCS holdover that may be useful to you as a developer. Keywords essentially let you embed version information permanently in source files. A string containing the full version information associated with a particular keyword is substituted whenever the file is subsequently revised. 
<P>
As an example, including:
<BLOCKQUOTE>
<B>$Author: susank $</B>
</BLOCKQUOTE>
within the files permanently retains the login name of the user who checked in that revision.
<P>Keyword substitution is a method for tracking file versions once the files are no longer part of a CVS repository. Keyword substitution can also be configured and suppressed.
<P>
<A HREF="http://cvshome.org/docs/manual/cvs_12.html#SEC98" TARGET="_new">More about keywords (including a list of common keywords)</A>
<P>
<BR>
<BR>

a117 2
<BR>
<BR>
d119 1
a137 1

d141 1
a141 1
<P><LI>To see the differences between your copy of a file and the latest version in the repository:<BR>
a147 2
<BR>
<BR>
d149 1
a158 2
<BR>
<BR>
d160 1
a166 2
<BR>
<BR>
d168 2
a169 1
<A NAME="cvsresolving"></A><LI>Resolving merge conflicts
d171 2
a172 1
To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by &quot>>>>>>&quot and &quot<<<<<<<&quot. When CVS cannot resolve a conflict, it includes both versions of the affect line or sections in the file, usually the latest version first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revision numbers. Then save the file and commit.
a176 2
<BR>
<BR>
d178 1
d181 1
a181 1
Beyond the usefulness of being able to review a file's modification history using the &quot<B>cvs log</B>&quot command to review, earlier versions can actually be restored as the most current revision (that is, to the "repository head") by the process of <I>reverting</I>. This can become a particularly useful option if you want or need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock.  
d183 4
a186 1
The command to revert to an earlier version of a file is:
d188 1
a188 1
<B>cvs up -r filename version_#</B>
d191 13
a203 1
Reverting may results in "sticky tag" errors. You can resolve these using the following update command with a special switch: 
a207 7


<!--
revisions are specific updates to files, i.e. 1.1, 1.2, 1.3
versions are SETS of file revisions tagged and named at a certain point in time (the confusion comes because versions are sometimes named 1.0, 1.1, 1.2 etc. but don't have to be named that way, can be any set of characters project owner designates)

-->
a208 7
<BR>
<BR>

<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72" TARGET="_new">More about revision history</A><BR>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes" TARGET="_new">More about reverting</A>


d219 2
a220 1
<A HREF="Help.html">Back to main Help index</A></P></SPAN>
@


1.2
log
@removed window's nasty line breaks, and corrected more links in HelpBox files
PR:
Obtained from:
Submitted by:
Reviewed by:
@
text
@d1 7
d146 1
a146 1
<B>$Author: lori $</B>
d294 2
@


1.1
log
@new and revised help documentation for v1.0
@
text
@d1 286
a286 286
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD CLASS="Header" NOWRAP>Contributing changes with command-line CVS</TD>
  </TR>
</TABLE>

<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" WIDTH="100%">
  <TR>
<SPAN CLASS="PlainText">

<P>
<UL>
<DL>
<DT><A HREF="#work">Working with files</A>
<DT><A HREF="#filetypes">About file types</A>
<DT><A HREF="#contributing">Contributing your changes</A>
	<DD><A HREF="#cvscommit">Committing files and directories</A>
	<DD><A HREF="#cvsadd">Adding new files and directories</A>
<DT><A HREF="#cvsimport">Importing existing source files</A>
<DT><A HREF="#cvsandrcs">CVS and RCS</A>
<DT><A HREF="#keywords">Using keywords</A>
<DT><A HREF="#cvsupdate">Keeping your working copy up to date (cvs update)</A>
<DT><A HREF="#cvstatus">Comparing your working files to the CVS repository</A>
<DT><A HREF="#otherdiff">Comparing files before you commit</A>
<DT><A HREF="#cvsmerging">Merging your changes</A>
<DT><A HREF="#cvsresolving">Resolving merge conflicts</A>
<DT><A HREF="#reverting">Revision history and reverting</A>
</DL>
</UL>

<P>
<SPAN CLASS="InputHeader"><A NAME="work"></A>Working with files</SPAN>
<P>
Between checking files out of the project repository and checking them back in, CVS has virtually nothing to do with how files are used in the project environment or build process. That is governed by the project owner and other external factors unique to the project.
<P>
When you make changes to existing files, you must edit your working copies of these files in a file editor on your local machine using your file editor of choice. None of the changes you make to your working files has any effect on the project's source repository or on other developers' work until you check in (that is, do a <I>cvs commit</I>) your modified versions of files.
<P>
More about "<A HREF="http://www.cvshome.org/docs/manual/cvs_1.html#SEC1" TARGET=_NEW>What CVS is not</A>."
<P>
<BR>
<BR>

<SPAN CLASS="InputHeader"><A NAME="filetypes"></A>About file types</SPAN>
<P>
<P>
The information provided in this document about CVS commands and actions assumes that the project files you are working with are text files. It is possible to include binary files in version control with CVS, although there are some special issues.
<P>
More about <A HREF="http://cvshome.org/docs/manual/cvs_9.html#SEC80" TARGET="_new">Handling binary files</A> in CVS.
<P>
<BR>
<BR>

<SPAN CLASS="InputHeader"><A NAME="contributing"></A>Contributing your changes into CVS</SPAN>
<UL>
<P><A NAME="cvscommit"></A><LI>To <I>commit</I> your changes to a file into the shared repository, type:
<BLOCKQUOTE>
       <B>cvs commit -m "Type your changes message here" FILENAME</B>
</BLOCKQUOTE>
<P>
If you do not include a description of your change to the file, you will be prompted to add it by invoking your file editor before CVS can complete the commit action. 
<P><LI>To commit your changes to all files in a directory and any subdirectories:
<BLOCKQUOTE>
          <B>cd top_directory_to_commit</B><BR>
          <B>cvs commit -m "Type your change message here"</B>
</BLOCKQUOTE>
</UL>
<P>
All commits are logged automatically and posted to the project's cvs mailing list.
<P>

<A NAME="cvsadd"></A><SPAN CLASS="InputHeader">Adding files/directories</SPAN>

        <P>To <I>add</I> a new file to the CVS repository after you have first created and edited it in your working directory, type:
<BLOCKQUOTE>
          <B>cvs add filename</B><BR>
</BLOCKQUOTE>
         Then follow up with the &quotcvs commit filename&quot command. If you do not first add the file, CVS does not recognize it.</LI>

<P>
If you have cvs write permissions, you can add subdirectories to your project's source tree using the &quot<B>cvs add</B>&quot command. You can then move existing files into new subdirectories with the &quot;<B>cvs move</B>&quot; command.
<P>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Committing" TARGET="_new">More about committing changes</A><BR>
<A HREF="http://cvshome.org/docs/manual/cvs_7.html#SEC66" TARGET="_new">More about adding files and directories</A>
<P>
<BR>
<BR>

<A NAME="cvsimport"></A> <B>Importing existing code?</B>
<P>
If you have existing files to add to the project, you can import these into CVS using the following command:
<BLOCKQUOTE>
		<B>cvs import filename</B>
</BLOCKQUOTE>

<P>
Importing allows you to add a lot of files at once, something like a super "cvs add." To import <I>all</I> existing directories and files, in your top level directory type:
<P>
<B>cvs import -m &quotlog message&quot projectname</B>
<P>
This creates the files and directories in the CVS repository for your project on this site. If you want to preserve these files and directories in their original state, you may want to tag or archive this set of original files before you or any other developers begin checking out working copies of project files.
<P>
If your existing files are already under versioning control -- either in another CVS repository or in a versioning different system such as RCS -- there is no automated method for importing existing files that retains file histories. Using the cvs import command, copying files over, or creating them as new files does not retain these histories.
<P>
<BR>
<BR>

<A NAME="copyfromrcs"></A>Neither cvs import nor cvs copy preserves  the RCS revision histories of existing files brought in to CVS, but there is a way to do this by using:
<BLOCKQUOTE>
<B>cvs cp filename,v</B>
</BLOCKQUOTE>
If you do not copy files using the "filename,v", all versioning information for each file is lost.
<P>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC112" TARGET="_new">More about &quot;<B>cvs import&quot</B></A>
<P>
<BR>
<BR>

<SPAN CLASS="InputHeader"><A NAME="cvsandrcs"></A>CVS and RCS</SPAN>
<P>
If you're already familiar with RCS, both RCS and CVS use a similar format for storing the version control histories of individual files. But you should be aware of at least two critical differences in adapting CVS:
<P>
<UL>
<LI>One of the central principals in RCS is file locking, which prevents other developers from checking out or modifying a file when you have checked it out. The benefit to file locking is that developers never have to deal with conflicting modifications within files. RCS protects files by only allowing them to be modified by one person at a time. Therefore, the drawback to RCS is: you can't commit your changes to a file while another developer has it checked out.
<LI>The central tenant of CVS is to allow developers to check out, modify, and commit files concurrently, truly a benefit to projects with remote, geographically dispersed developers. The tradeoff is that on a CVS version controlled project, you can count on dealing with merge conflicts in files. The only method for resolving such conflicts is by hand-editing the file. Thus, project workflow with CVS ends up being a little different.
</UL>
<P>

<A HREF="http://www.cvshome.org/cyclic/cyclic-pages/rcs.html" TARGET="_new">More about RCS and CVS</A>
<P>
<BR>
<BR>

<A NAME="keywords"></A><SPAN CLASS="InputHeader">Keyword substitution</SPAN>
<P>
Keyword substitution (a.k.a keyword expansion) is an RCS holdover that may be useful to you as a developer. Keywords essentially let you embed version information permanently in source files. A string containing the full version information associated with a particular keyword is substituted whenever the file is subsequently revised. 
<P>
As an example, including:
<BLOCKQUOTE>
<B>$Author$</B>
</BLOCKQUOTE>
within the files permanently retains the login name of the user who checked in that revision.
<P>Keyword substitution is a method for tracking file versions once the files are no longer part of a CVS repository. Keyword substitution can also be configured and suppressed.
<P>
<A HREF="http://cvshome.org/docs/manual/cvs_12.html#SEC98" TARGET="_new">More about keywords (including a list of common keywords)</A>
<P>
<BR>
<BR>

<A NAME="cvsupdate"></A><SPAN CLASS="InputHeader">Keeping your working files up to date with the repository</SPAN>
<P>
If you want to look before you leap, you can get a list of all files in your local directory not up to date with the project repository by using the following command:<BR>
<BLOCKQUOTE>
          <B>cvs -qn update</B> </LI>
</BLOCKQUOTE>
Files in the affected directory or directories are listed with their current status indicated as follows:
<UL>
<LI>? = File is unrecognized by CVS (needs to be added and committed).
<LI>A = File is added; file is recognized by CVS but still needs to be committed to the repository.
<LI>M = File has been modified by another developer since you checked out your working copy. This means that you need to update.
<LI>U = File is updated.
<LI>C = File has merge conflicts that must be resolved by hand.
</UL>
<P>
To go ahead and actually perform an update to make your working directory up to sync with the repository, the command is:
<BLOCKQUOTE>
	<B>cvs update</B>
</BLOCKQUOTE>
You can also update individual files by adding the filename to the command.
<P>Or, to include any new directories when updating, do:
<BLOCKQUOTE>
        <B>cvs update -d</B> 
</BLOCKQUOTE>
<P> 
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC132" TARGET="_new">More about the cvs update command</A><BR>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_20.html#SEC134" TARGET="_new">More about CVS update output</A>
<P>
<BR>
<BR>

<A NAME="cvstatus"></A><SPAN CLASS="InputHeader">Comparing your working files to the repository</SPAN>
<P>
Another way to determine whether all of your working files are in sync with the latest versions in the repository is with the command:
<BLOCKQUOTE>
<B>cvstatus</B><BR>
</BLOCKQUOTE>
or for status on individual files:<BR> 
<BLOCKQUOTE>
<B>cvs status filename</B>
</BLOCKQUOTE>
<P>
This comparison may return one of the following messages:
<P>
<DL>
<DT><B><I>Locally modified</I></B> <DD>Your version has not yet been committed.
<DT><B><I>Needs patch</I></B> <DD>Your version needs to be updated because someone else has made changes.
<DT><B><I>File had conflicts on merge</I></B> <DD>CVS could not resolve changes made to this file and committed. (<A HREF="cvsresolving">Resolving merge conflicts</A>.)
</DL>

<P>
In general, a good rule of thumb is to make sure your working files are up to date with the repository <I>just before you commit your changes to a file</I>. The reason for this is that sometimes your commit may be unsuccessful, for example, you may be trying to commit from the wrong directory or perhaps another developer has committed changes to that same file after you checked it out of the repository or last updated it. Trying to commit your changes to an older version of the same file often causes conflicts when CVS tries to merge these. The result of your commit attempt under such circumstances is a somewhat daunting failure message about "dying gasps" from CVS. (Unfortunately, you don't find this out until <I>after</I> you've gone through the process of mentally composing and entering a pithy change log message.)
<P>
<P><LI>To see the differences between your copy of a file and the latest version in the repository:<BR>
<BLOCKQUOTE>
          <B>cvs diff filename</B> </LI>
</BLOCKQUOTE>
<P>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Finding_Out_What_You__And_Others__Did_--_update_And_diff" TARGET=_NEW>More about comparing your work with the project repository</A>
<P>
<BR>
<BR>

<A NAME="diffs"></A><SPAN CLASS="InputHeader">Comparing versions of files <I>before</I> you commit (diff)</SPAN>
<P>
Perhaps you want to see the changes another developer has made to the same file <I>before</I> you commit your own changes. For example, suppose you are committing some very complex changes which you anticipate may conflict with another developer's work.
<P>
In this case, a workable solution is to save off your working file under a different name (something like: "filename-new"). Then you can run the &quot<B>cvs update</B>&quot command and compare the latest version from the repository with your file before committing your changes. You can even compare the two files side-by-side using the following diff command:
<BLOCKQUOTE>
<B>diff -y filename filename-new</B>
</BLOCKQUOTE>
<P>
<BR>
<BR>

<A NAME="cvsmerging"></A><SPAN CLASS="InputHeader">Merging your changes with other developers' changes</SPAN>
<P>
By giving the &quot<B>cvs update</B>&quot command, you are essentially telling CVS to merge the latest versions of files from the repository into your working copies.
<P>
Sometimes, however, other modifications made to a file since you last updated do not mesh well with your version. Or, you've made changes that conflict with the repository version. CVS makes every attempt to resolve such conflicts automatically when you update and commit, but sometimes it cannot resolve everything. Conflicts within the file must be resolved by hand.
<P>
<BR>
<BR>

<A NAME="cvsresolving"></A><LI>Resolving merge conflicts
<P>
To resolve merge conflicts, open the file in your file editor. Look for lines or sections marked by &quot>>>>>>&quot and &quot<<<<<<<&quot. When CVS cannot resolve a conflict, it includes both versions of the affect line or sections in the file, usually the latest version first. Your task is to delete the unwanted lines, along with the lines containing the conflict symbols and revision numbers. Then save the file and commit.
<P>
<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_7.html#SEC40" TARGET="_new">An example of a conflict</A><BR>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Detecting_And_Resolving_Conflicts" TARGET="_new">More about resolving conflicts</A>
<P>
<BR>
<BR>

<A NAME="reverting"></A><SPAN CLASS="InputHeader">Revision history and reverting</SPAN>
<P>
Beyond the usefulness of being able to review a file's modification history using the &quot<B>cvs log</B>&quot command to review, earlier versions can actually be restored as the most current revision (that is, to the "repository head") by the process of <I>reverting</I>. This can become a particularly useful option if you want or need to return to an earlier point in a file's evolution for whatever reason, somewhat like being able to turn back the clock.  
<P>
The command to revert to an earlier version of a file is:
<BLOCKQUOTE>
<B>cvs up -r filename version_#</B>
</BLOCKQUOTE>
<P>
Reverting may results in "sticky tag" errors. You can resolve these using the following update command with a special switch: 
<BLOCKQUOTE>
<B>cvs update -dAP</B>
</BLOCKQUOTE>
(<A H REF="http://cvsbook.red-bean.com/cvsbook.html#Getting_Snapshots__Dates_And_Tagging_" TARGET="_new">What are sticky tag errors?</A>)


<!--
revisions are specific updates to files, i.e. 1.1, 1.2, 1.3
versions are SETS of file revisions tagged and named at a certain point in time (the confusion comes because versions are sometimes named 1.0, 1.1, 1.2 etc. but don't have to be named that way, can be any set of characters project owner designates)

-->
<P>
<BR>
<BR>

<A HREF="http://www.gnu.org/manual/cvs/html_chapter/cvs_16.html#SEC72" TARGET="_new">More about revision history</A><BR>
<A HREF="http://cvsbook.red-bean.com/cvsbook.html#Examining_And_Reverting_Changes" TARGET="_new">More about reverting</A>



<!--
<P>
<A NAME="cvstips"><span class="InputHeader">Feedback on this document</span></A>
<P>
The author of this help document has made every attempt to compile accurate, helpful information about using CVS for projects hosted on this site. If you think any content in the above document is wrong, inadequate, or something is just plain missing ... that's good. This is open source, so step up to the plate and contribute your suggestions for additions and improvements.
<P>
-->

<HR NOSHADE SIZE=1>
<A HREF="Help.html">Back to main Help index</A></P></SPAN>

</SPAN> 
</TR>
</TABLE>
@

