This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
cleanup, cvswrite.html/contribute.html
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Wed, 28 Nov 2001 15:24:25 -0800
- Subject: cleanup, cvswrite.html/contribute.html
I've applied this patch to clean up tagging, formatting, and typos in
cvswrite.html and contribute.html. There are no content changes. The
pages now pass validation as XHTML 1.0 Transitional if I insert the
appropriate header.
zw
===================================================================
Index: contribute.html
--- contribute.html 2001/11/05 22:10:19 1.40
+++ contribute.html 2001/11/28 23:22:39
@@ -1,8 +1,8 @@
<html>
-
<head>
-<meta name="description" content="Contributing to the GCC project.">
-<meta name="keywords" content="GCC, standards, copyright, patches, contributing">
+<meta name="description" content="Contributing to the GCC project." />
+<meta name="keywords"
+ content="GCC, standards, copyright, patches, contributing" />
<title>Contributing to GCC</title>
</head>
@@ -17,16 +17,15 @@ improvements, etc. for GCC</p>
contributions must meet.</p>
<h2>Coding Standards</h2>
-
- <p>All contributions must conform to the <a
- href="http://www.gnu.org/prep/standards_toc.html";>GNU Coding
- Standards</a>. There are also some <a
- href="codingconventions.html">additional coding conventions for
- GCC</a>; these include documentation and testsuite requirements as
- well as requirements on code formatting. Submissions which do not
- conform to the standards will be returned with a request to address
- any such problems.</p>
+<p>All contributions must conform to the <a
+href="http://www.gnu.org/prep/standards_toc.html";>GNU Coding
+Standards</a>. There are also some <a
+href="codingconventions.html">additional coding conventions for
+GCC</a>; these include documentation and testsuite requirements as
+well as requirements on code formatting. Submissions which do not
+conform to the standards will be returned with a request to address
+any such problems.</p>
<h2>Copyright Assignment</h2>
@@ -44,7 +43,6 @@ your request.</p>
<p>Small changes can be accepted without a copyright assignment form
on file.</p>
-
<h2>Submitting Patches</h2>
<p>Every patch must have several pieces of information before we can
@@ -76,22 +74,22 @@ A ChangeLog entry as plaintext; see the
format and content, and the <a href="codingconventions.html">GCC
coding conventions</a> and <a
href="http://www.gnu.org/prep/standards_toc.html";>GNU Coding
-Standards</a> for further information. The ChangeLog entries should be
-plaintext rather than part of the patch since the top of the ChangeLog
-changes rapidly and a patch to the ChangeLog would probably no longer
-apply by the time your patch is reviewed.
+Standards</a> for further information. The ChangeLog entries should
+be plaintext rather than part of the patch since the top of the
+ChangeLog changes rapidly and a patch to the ChangeLog would probably
+no longer apply by the time your patch is reviewed.
</dd>
<dt>Bootstrapping and testing</dt>
<dd>
A list of targets where the patch survived a bootstrap of GCC. A
-bootstrap on at least one host is required for any non-trivial change. A
-full GCC testsuite run is also required. You can also <a
-href="simtest-howto.html">use one or more simulators</a> to increase your
-test coverage. With your patch, provide a list of hosts where the GCC
-testsuite was run, including an analysis of any regressions.
-Documentation changes do not require a bootstrap, but must pass <code>make
-info</code> and <code>make dvi</code>.
+bootstrap on at least one host is required for any non-trivial change.
+A full GCC testsuite run is also required. You can also <a
+href="simtest-howto.html">use one or more simulators</a> to increase
+your test coverage. With your patch, provide a list of hosts where
+the GCC testsuite was run, including an analysis of any regressions.
+Documentation changes do not require a bootstrap, but must pass
+<code>make info</code> and <code>make dvi</code>.
</dd>
<dt>The patch itself</dt>
@@ -108,53 +106,52 @@ as a candidate for the release branch.
</dl>
- <p>Don't mix together changes made for different reasons. Send them
- <em>individually</em>. Ideally, each change you send should be
- impossible to subdivide into parts that we might want to consider
- separately, because each of its parts gets its motivation from the
- other parts. In particular, changes to code formatting to conform
- to coding standards are best not mixed with substantive changes,
- because that makes it difficult to see what the real changes are.
- (In the case of a very large reorganization of code, it may make
- sense to separate changes even further to make it clearer what has
- changed; for example, by first sending structural changes that make
- subsequent changes easier but do not change GCC's behavior, then new
- code, then the changes that actually make use of the new code and
- change GCC's behavior.)</p>
-
- <p>We accept patches as plain text (preferred for the compilers
- themselves), MIME attachments (preferred for the web pages),
- or as uuencoded gzipped text.</p>
-
- <p>When you have all these pieces, bundle them up in a mail message and
- send it to
- <a href="mailto:gcc-patches@gcc.gnu.org";>gcc-patches@gcc.gnu.org</a>.
- All patches and related discussion should be sent to the gcc-patches
- mailinglist. For further information on the GCC CVS repository, see
- the <a href="cvs.html">Anonymous read-only CVS access</a> and
- <a href="cvswrite.html">Read-write CVS access</a> pages.
-
- <p>If you do not receive a response to a patch that you have submitted
- within a month or so,
- it may be a good idea to chase it by sending a follow-up email to
- <a href="mailto:gcc-patches@gcc.gnu.org";>gcc-patches@gcc.gnu.org</a>.
- Patches can occasionally fall through the cracks. Please be sure to
- include the URL of the entry in the mailing list archive of the original
- submission.</p>
-
- <p>Patches to the standard C++ library (libstdc++-v3), and its web
- pages, and discussion of such patches, should go to <a
- href="mailto:libstdc++@gcc.gnu.org";>libstdc++@gcc.gnu.org</a> as
- well as to gcc-patches. Patches to the Java library (libgcj) should
- go to <a
- href="mailto:java-patches@gcc.gnu.org";>java-patches@gcc.gnu.org</a>
- instead of gcc-patches.</p>
-
- <p>Everything listed here still applies if you can check in the
- patch without further approval under the <a
- href="cvswrite.html#policies">GCC write access policies</a>, except
- that ChangeLog entries may be included as part of the patch since
- no-one else will need to apply it to the tree later.</p>
+<p>Don't mix together changes made for different reasons. Send them
+<em>individually</em>. Ideally, each change you send should be
+impossible to subdivide into parts that we might want to consider
+separately, because each of its parts gets its motivation from the
+other parts. In particular, changes to code formatting to conform to
+coding standards are best not mixed with substantive changes, because
+that makes it difficult to see what the real changes are. (In the
+case of a very large reorganization of code, it may make sense to
+separate changes even further to make it clearer what has changed; for
+example, by first sending structural changes that make subsequent
+changes easier but do not change GCC's behavior, then new code, then
+the changes that actually make use of the new code and change GCC's
+behavior.)</p>
+
+<p>We accept patches as plain text (preferred for the compilers
+themselves), MIME attachments (preferred for the web pages), or as
+uuencoded gzipped text.</p>
+
+<p>When you have all these pieces, bundle them up in a mail message
+and send it to <a
+href="mailto:gcc-patches@gcc.gnu.org";>gcc-patches@gcc.gnu.org</a>.
+All patches and related discussion should be sent to the gcc-patches
+mailinglist. For further information on the GCC CVS repository, see
+the <a href="cvs.html">Anonymous read-only CVS access</a> and <a
+href="cvswrite.html">Read-write CVS access</a> pages.</p>
+
+<p>If you do not receive a response to a patch that you have submitted
+within a month or so, it may be a good idea to chase it by sending a
+follow-up email to <a
+href="mailto:gcc-patches@gcc.gnu.org";>gcc-patches@gcc.gnu.org</a>.
+Patches can occasionally fall through the cracks. Please be sure to
+include the URL of the entry in the mailing list archive of the
+original submission.</p>
+
+<p>Patches to the standard C++ library (libstdc++-v3), and its web
+pages, and discussion of such patches, should go to <a
+href="mailto:libstdc++@gcc.gnu.org";>libstdc++@gcc.gnu.org</a> as well
+as to gcc-patches. Patches to the Java library (libgcj) should go to
+<a href="mailto:java-patches@gcc.gnu.org";>java-patches@gcc.gnu.org</a>
+instead of gcc-patches.</p>
+
+<p>Everything listed here still applies if you can check in the patch
+without further approval under the <a
+href="cvswrite.html#policies">GCC write access policies</a>, except
+that ChangeLog entries may be included as part of the patch since
+no-one else will need to apply it to the tree later.</p>
</body>
</html>
===================================================================
Index: cvswrite.html
--- cvswrite.html 2001/09/16 19:26:36 1.42
+++ cvswrite.html 2001/11/28 23:22:39
@@ -1,6 +1,9 @@
<html>
-
<head>
+<meta name="description"
+ content="Instructions for read-write access to the GCC CVS repository." />
+<meta name="keywords"
+ content="GCC, patches, checking in, CVS, SSH, access policy" />
<title>Read-write CVS access</title>
</head>
@@ -8,11 +11,11 @@
<h1 align="center">Read-write CVS access</h1>
-<p>We have read/write access to the CVS repository available for all our
-significant developers. Maintainers are also encouraged to edit the
-<a href="gnatswrite.html">GNATS database</a>.</p>
+<p>We have read/write access to the CVS repository available for all
+our significant developers. Maintainers are also encouraged to edit
+the <a href="gnatswrite.html">GNATS database</a>.</p>
-<hr>
+<hr />
<h3>Contents</h3>
<ol>
<li><a href="#authenticated">Authenticated access</a></li>
@@ -23,113 +26,120 @@ significant developers. Maintainers are
<li><a href="#branches">Creating branches</a></li>
</ol>
-<hr>
+<hr />
<h2><a name="authenticated">Authenticated access</a></h2>
<p>Authenticated access is provided via the SSH protocol. Please
-provide us with your public key which you can generate via the
-"ssh-keygen" program. This will store your public key in the file
-.ssh/identity.pub in your home directory.
-Please use
-<a href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi";>this form</a>
+provide us with your public key, which you can generate via the
+<code>ssh-keygen</code> program. This will store your public key in
+the file <code>.ssh/identity.pub</code> in your home directory.
+Please use <a
+href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi";>this form</a>
to supply the file and your other details.</p>
<p>Once we have this information we will set up an account on
-gcc.gnu.org and inform you by mail. At this point you should be
-able to check out a tree with CVS and add yourself to the MAINTAINERS
-file to test write access. See <a href="#checkin">Checking in a change</a>
-for how to proceed with checking in your changes.</p>
+<code>gcc.gnu.org</code> and inform you by mail. At this point you
+should be able to check out a tree with CVS and add yourself to the
+MAINTAINERS file to test write access. See <a
+href="#checkin">Checking in a change</a> for how to proceed with
+checking in your changes.</p>
-<hr>
+<hr />
<h2><a name="setup">Setting up your local CVS tree</a></h2>
-<p>Once you can login to the machine, it's trivial to start using ssh from
-your remote machine. Set CVS_RSH in your environment to "ssh". Then issue
-the command
+<p>Once you can login to the machine, it's trivial to start using ssh
+from your remote machine. Set <code>CVS_RSH</code> in your
+environment to "<code>ssh</code>". Then issue the command</p>
<blockquote><code>
-cvs -z 9 -d :ext:username@gcc.gnu.org:/cvs/gcc co gcc
+cvs -z 9 -d :ext:<i>username</i>@gcc.gnu.org:/cvs/gcc co gcc
</code></blockquote>
-
-where <code>username</code> is your user name at gcc.gnu.org.
-This will check out a new CVS tree that you should be able to work with
-in the normal fashion, including committing changes.
-<p>It is also possible to convert an existing CVS tree to use ssh by replacing
-all the "Root" files in the local tree with the following contents:</p>
+<p>where <i>username</i> is your user name at
+<code>gcc.gnu.org</code>. This will check out a new CVS tree that you
+should be able to work with in the normal fashion, including
+committing changes.</p>
+
+<p>It is also possible to convert an existing CVS tree to use ssh by
+replacing all the "Root" files in the local tree with the following
+contents:</p>
<blockquote><code>
-username@gcc.gnu.org:/cvs/gcc
+<i>username</i>@gcc.gnu.org:/cvs/gcc
</code></blockquote>
<p>To avoid the nuisance of having to supply your passphrase for each
operation, you may want to use <code>ssh-agent</code>(1) followed by
<code>ssh-add</code>(1) and entering your passphrase once for all.
Either start your session as a child of <code>ssh-agent</code> or run
-it as a demon and set the values of the environment variables
+it as a daemon and set the values of the environment variables
<code>SSH_AUTHENTICATION_SOCKET</code> and <code>SSH_AGENT_PID</code>
in each relevant process to what <code>ssh-agent</code> prints when it
starts. To avoid messages about (lack of) X11 forwarding, put in your
-<samp>$HOME/.ssh/config</samp> and entry like:
-<blockquote><code>
-Host gcc.gnu.org<br>
+<samp>$HOME/.ssh/config</samp> an entry like:</p>
+
+<blockquote>
+<pre>
+Host gcc.gnu.org
ForwardX11 no
-</code></blockquote>
+</pre>
+</blockquote>
<h2>Web pages</h2>
<p>Note that when you check in changes to our web pages, these will
automatically be checked out into the web server's data area.</p>
-<hr>
+<hr />
<h2><a name="policies">Write access policies</a></h2>
-<p>The GCC project grants some developers various levels of write access
-to the GCC master sources. CVS doesn't provide fine grained control over
-access to the repository; therefore, we depend on each developer to follow
-the appropriate policies.</p>
+<p>The GCC project grants some developers various levels of write
+access to the GCC master sources. CVS doesn't provide fine grained
+control over access to the repository; therefore, we depend on each
+developer to follow the appropriate policies.</p>
<dl>
- <dt>Global write permission.</dt> <dd>A very limited number of
- developers have global write permission over the entire
- repository.</dd>
-
- <dt>Localized write permission.</dt> <dd><p>This is for people who have
- primary responsibility for ports, front ends, or significant hunks
- of code in the compiler. These folks are allowed to make changes in
- code they maintain without going through any kind of approval
- process.</p>
+ <dt>Global write permission.</dt>
+ <dd><p>A very limited number of developers have global write permission
+ over the entire repository.</p></dd>
+
+ <dt>Localized write permission.</dt>
+ <dd><p>This is for people who have primary responsibility for ports,
+ front ends, or significant hunks of code in the compiler. These
+ folks are allowed to make changes in code they maintain without
+ going through any kind of approval process.</p>
- <p>
- Maintainers of a port maintain the files in config/<port>/,
+ <p>Maintainers of a port maintain the files in config/<i>port</i>/,
the configure fragments for the port, documentation for the port and
test cases for features or bugs specific to this port. Port
maintainers do not have approval rights in other files.</p>
</dd>
- <dt>Write after approval.</dt> <dd>This is folks that make regular
- contributions, but do not fall into one of the two previous
- categories. People with write after approval need to submit their
- patches to the list; once the patches have been approved by the
- appropriate maintainers the patches may be checked into the GCC
- sources.</dd>
+ <dt>Write after approval.</dt>
+ <dd><p>This is folks that make regular contributions, but do not fall
+ into one of the two previous categories. People with write after
+ approval need to submit their patches to the list; once the patches
+ have been approved by the appropriate maintainers the patches may be
+ checked into the GCC sources.</p></dd>
</dl>
-<p>The list of folks with write access to the repository can be found in the
-<tt>MAINTAINERS</tt> file in the GCC distribution.</p>
+<p>The list of folks with write access to the repository can be found
+in the <tt>MAINTAINERS</tt> file in the GCC distribution.</p>
-<p>Also note that fixes for obvious typos in ChangeLog files, docs, web
-pages, comments and similar stuff need not be approved. Just check in the
-fix. We don't want to get overly anal about checkin policies.</p>
-
-<p>When you have checked in a patch exactly as it has been approved, you
-do not no need to tell that to people -- including the approver. People
-interested in when a particular patch is committed can check CVS or the <a
-href="http://gcc.gnu.org/ml/gcc-cvs/";>gcc-cvs</a> list.</p>
-
-<p>Maintainers are free to import files maintained outside
-the tree from their official versions without explicit write approval.
-Such files would include <code>config.guess</code> and
+<p>Also note that fixes for obvious typos in ChangeLog files, docs,
+web pages, comments and similar stuff need not be approved. Just
+check in the fix. We don't want to get overly anal about checkin
+policies.</p>
+
+<p>When you have checked in a patch exactly as it has been approved,
+you do not need to tell that to people -- including the approver.
+People interested in when a particular patch is committed can check
+CVS or the <a href="http://gcc.gnu.org/ml/gcc-cvs/";>gcc-cvs</a>
+list.</p>
+
+<p>Maintainers are free to import files maintained outside the tree
+from their official versions without explicit write approval. Such
+files would include <code>config.guess</code> and
<code>config.sub</code>.</p>
<p>Any maintainer with CVS write access may <a href="#branches">create
@@ -138,11 +148,12 @@ the compiler they maintain, provided tha
copyright assignments on file. Merging such developments back to the
mainline still needs approval in the usual way.</p>
-<hr>
+<hr />
<h2><a name="checkin">Checking in a change</a></h2>
<p>It is expected that before you check in any change you will do the
-following:
+following:</p>
+
<ul>
<li>If your change is to code that is not in a front-end, or is to the
C front-end, verify that the compiler bootstraps with your change.
@@ -150,16 +161,16 @@ following:
with exactly the change that you intended to check in; it's not
good enough to have bootstrapped with an earlier variant. (Unless
the only changes from the earlier variant are formatting and
- comment changes; if there are <strong>any</strong> changes to the code
- itself you should re-bootstrap.) It is recommended that you also <a
- href="simtest-howto.html">use a simulator</a> to increase your test
- coverage.</li>
-
-<li>If your change is to code that is not in a front-end, or is to
- the C front-end, verify that the all of the GCC regression tests
- behave identically before and after your patch. You can do a
- <code>make -k check</code> at the top of the tree to run all of the
- tests.</li>
+ comment changes; if there are <strong>any</strong> changes to the
+ code itself you should re-bootstrap.) It is recommended that you
+ also <a href="simtest-howto.html">use a simulator</a> to increase
+ your test coverage.</li>
+
+<li>If your change is to code that is not in a front-end, or is to the
+ C front-end, verify that the all of the GCC regression tests
+ behave identically before and after your patch. You can do a
+ <code>make -k check</code> at the top of the tree to run all of
+ the tests.</li>
<li>If your change is to code that is in a front-end, other than the C
front-end, you need to verify only that the tests for that
@@ -180,55 +191,58 @@ minimize the amount of time where the tr
all. Repeated failure to adhere to these rules could result in the
revocation of check-in privileges by the Steering Committee.</p>
-<p>The following is meant to provide a very quick overview of how to check
-in a change. It is not meant to be a replacement for the CVS manual but
-instead a supplement. The CVS manual is distributed as part of the CVS
-sources as a texinfo file.
-<a href="http://www.cvshome.org/cyclic/cvs/doc-blandy.html";>
-http://www.cvshome.org/cyclic/cvs/doc-blandy.html</a> contains
-a link to an reasonably simple introduction to CVS.</p>
+<p>The following is meant to provide a very quick overview of how to
+check in a change. It is not meant to be a replacement for the CVS
+manual but instead a supplement. The CVS manual is distributed as
+part of the CVS sources as a texinfo file. <a
+href="http://www.cvshome.org/cyclic/cvs/doc-blandy.html";>
+http://www.cvshome.org/cyclic/cvs/doc-blandy.html</a> contains a link
+to an reasonably simple introduction to CVS.</p>
<p>In all the commands listed below, you can give an explicit list of
filenames to the cvs command. We recommend you list files explicitly
-when performing checkins to avoid accidental checkins of local code.</p>
+when performing checkins to avoid accidental checkins of local
+code.</p>
<ol>
-<li>Sync your sources with the master repository via "<tt>cvs update</tt>"
-before attempting a checkin; this will save you a little time if someone
-else has modified that file since the last time you sync'd your sources.
-It will also identify any files in your local tree that you have
-modified.</li>
-
-<li>Apply the patch to your local tree and update the <tt>ChangeLog</tt>
-file. Use the current date/time for the <tt>ChangeLog</tt> entry, not
-the time that the patch was submitted.</li>
+<li>Sync your sources with the master repository via "<tt>cvs
+update</tt>" before attempting a checkin; this will save you a little
+time if someone else has modified that file since the last time you
+sync'd your sources. It will also identify any files in your local
+tree that you have modified.</li>
+
+<li>Apply the patch to your local tree and update the
+<tt>ChangeLog</tt> file. Use the current date/time for the
+<tt>ChangeLog</tt> entry, not the time that the patch was
+submitted.</li>
<li>Make sure to rebuild any generated files that would be affected by
the patch. Make sure to check them in along with the files explicitly
modified by the patch.</li>
-<li>We recommend using "<tt>cvs diff</tt>" after applying a patch to
-a local tree. Review the output to make sure that only the changes
-you wanted to check in will be checked in. Also check to see if the
+<li>We recommend using "<tt>cvs diff</tt>" after applying a patch to a
+local tree. Review the output to make sure that only the changes you
+wanted to check in will be checked in. Also check to see if the
copyright dates need to be updated.</li>
-<li>Use "<tt>cvs commit</tt>" to check in the patch. You can enter the
-log message via the "<tt>-m</tt>" argument to commit, or wait for the
-editor window to appear and enter the log message in the editor
+<li>Use "<tt>cvs commit</tt>" to check in the patch. You can enter
+the log message via the "<tt>-m</tt>" argument to commit, or wait for
+the editor window to appear and enter the log message in the editor
window.</li>
-<li>After exiting the editor, CVS will connect to the GCC cvs server and
-check in your changes. When your prompt returns the checkin is finished.
-A message will be sent to the "<tt>gcc-cvs</tt>" mailing list (when
-set up) indicating that a change was made. CVS will provide a message
-if an error occurs and it will not check in any files.</li>
+<li>After exiting the editor, CVS will connect to the GCC cvs server
+and check in your changes. When your prompt returns the checkin is
+finished. A message will be sent to the "<tt>gcc-cvs</tt>" mailing
+list indicating that a change was made. CVS will provide a message if
+an error occurs and it will not check in any files.</li>
</ol>
-<hr>
+<hr />
<h2><a name="example">Example check-in session</a></h2>
-<p>Here's an actual check-in session for a patch John Carr recently sent
-to the GCC list. This was the <tt>ChangeLog</tt> for his change:
+<p>Here's an actual check-in session for a patch John Carr recently
+sent to the GCC list. This was the <tt>ChangeLog</tt> for his
+change:</p>
<blockquote>
<pre>
@@ -262,13 +276,14 @@ M gcc/objc/Makefile.in
</pre>
</blockquote>
-<p>The question marks indicate files in my local repository that are not
-part of the official sources. The "M" indicates files I've changed locally
-for some unrelated work -- thus I have to be careful to avoid checking
-them in. A "U" would have indicated a file that CVS updated because my
-local copy was out of date relative to the master sources.
+<p>The question marks indicate files in my local repository that are
+not part of the official sources. The "M" indicates files I've
+changed locally for some unrelated work -- thus I have to be careful
+to avoid checking them in. A "U" would have indicated a file that CVS
+updated because my local copy was out of date relative to the master
+sources.</p>
-<p>The local repository is now up to date.
+<p>The local repository is now up to date.</p>
<h3>Apply the patch to the local source</h3>
@@ -307,7 +322,7 @@ done
<h3>Add ChangeLog entry by hand</h3>
<p><tt>ChangeLog</tt> entries should be handled as straight text;
-patches against <tt>ChangeLog</tt>s rarely apply correctly.
+patches against <tt>ChangeLog</tt>s rarely apply correctly.</p>
<blockquote>
<pre>
@@ -318,8 +333,8 @@ patches against <tt>ChangeLog</tt>s rare
<h3>Review changes for correctness</h3>
<p>The patch and its associated <tt>ChangeLog</tt> entry are in my
-local tree; now I run <tt>cvs diff</tt> on the modified files and review
-the output.
+local tree; now I run <tt>cvs diff</tt> on the modified files and
+review the output.</p>
<blockquote>
<pre>
@@ -328,12 +343,12 @@ the output.
</blockquote>
<p>Look at <tt>/tmp/FOO</tt> and verify that only the changes we want
-are in the diff file.
+are in the diff file.</p>
<h3>Update Copyrights</h3>
-<p>Review the changed files to see if any copyrights need updating,
-in this particular case all three needed their copyrights updated.
+<p>Review the changed files to see if any copyrights need updating, in
+this particular case all three needed their copyrights updated.</p>
<blockquote>
<pre>
@@ -349,9 +364,9 @@ in this particular case all three needed
</pre>
</blockquote>
-<p>My editor starts and I enter the log message; the lines starting with
-<TT>CVS:</TT> are automatically added by CVS and will be automatically
-removed:
+<p>My editor starts and I enter the log message; the lines starting
+with <tt>CVS:</tt> are automatically added by CVS and will be
+automatically removed:</p>
<blockquote>
<pre>
@@ -375,7 +390,7 @@ CVS: -----------------------------------
</blockquote>
<p>Now write & quit from the editor, and CVS will start the actual
-checkin process....
+checkin process....</p>
<blockquote>
<pre>
@@ -400,15 +415,16 @@ done
</blockquote>
<p>Note that only a single CVS log message was used for all the files;
-this is the normal and expected behavior. It is not necessary to perform
-multiple commits and split up the CVS log entry on a file by file basis.
-Note this implies that each checkin is for a single logical change
-that may effect multiple files. If you have several unrelated changes,
-you should check them in with separate cvs commit commands.</p>
+this is the normal and expected behavior. It is not necessary to
+perform multiple commits and split up the CVS log entry on a file by
+file basis. Note this implies that each checkin is for a single
+logical change that may effect multiple files. If you have several
+unrelated changes, you should check them in with separate cvs commit
+commands.</p>
<p>And that's it!</p>
-<hr>
+<hr />
<h2><a name="branches">Creating branches</a></h2>
<p>When creating a branch for development, you should first tag the