Check-In Requirements

Kelley Cook kelleycook@yahoo.com
Fri Jun 2 08:17:00 GMT 2000


Only one minor nit ...

>+     the only changes from the earlier variant are formatting and
>+     comment changes; if there are <emph>any</emph> changes to the
code
>+     itself you should re-bootstrap.)

There is no HTML tag <emph> :(. 

You can use <em> which usually get rendered as italics or <strong>
which usually gets rendered as bold.

For those that weren't aware http://validator.w3.org/ is a good place
to check the legalness of pages.  The cvswrite page also had the <h2>
tags on the wrong side of the <a> tags which are fixed below.

-- Kelley Cook


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
--- cvswrite.html.orig	Fri Jun 02 10:43:30 2000
+++ cvswrite.html	Fri Jun 02 11:07:54 2000
@@ -23,7 +23,7 @@
 </ol>
 
 <hr>
-<a name="authenticated"><h2>Authenticated access</h2></a>
+<h2><a name="authenticated">Authenticated access</a></h2>
 
 <p>Authenticated access is provided via ssh, which you can retrieve from
 <a href=" ftp://ftp.cs.hut.fi/pub/ssh/ "> ftp://ftp.cs.hut.fi/pub/ssh/ </a>.
@@ -44,7 +44,7 @@
 for how to proceed with checking in your changes.
 
 <hr>
-<a name="setup"><h2>Setting up your local CVS tree</h2></a>
+<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
@@ -87,7 +87,7 @@
 automatically be checked out into the web server's data area.
 
 <hr>
-<a name="policies"><h2>Write access policies</h2></a>
+<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
@@ -125,7 +125,7 @@
 href=" http://gcc.gnu.org/ml/gcc-cvs/ ">gcc-cvs</a> list.
 
 <hr>
-<a name="checkin"><h2>Checking in a change</h2></a>
+<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:
@@ -136,7 +136,7 @@
     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 <emph>any</emph> changes to the code
+    comment changes; if there are <strong>any</strong> changes to the code
     itself you should re-bootstrap.)
 
 <li>If your change is to code that is not in a front-end, or is to   
@@ -156,13 +156,12 @@
 <li>When you post your change to <code>gcc-patches</code>, indicate
     what platform you have used for testing.
 </ul>
-These rules are designed to ensure that checked-in code does not
+<p>These rules are designed to ensure that checked-in code does not
 contain bugs that prevent other people from continuing to get their
 work done.  There will always be bugs, but these rules help to
 minimize the amount of time where the tree does not build at
 all. Repeated failure to adhere to these rules could result in the
 revocation of check-in privileges by the Steering Committee.
-</p>
 
 <p>This 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 
@@ -205,7 +204,7 @@
 if an error occurs and it will not check in any files.
 
 <hr>
-<a name="example"><h2>Example check-in session</h2></a>
+<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:


More information about the Gcc mailing list