906-909.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 169 行
HTML
169 行
<HTML>
<HEAD>
<TITLE>Linux Unleashed, Third Edition:Source Code Control</TITLE>
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!--ISBN=0672313723//-->
<!--TITLE=Linux Unleashed, Third Edition//-->
<!--AUTHOR=Tim Parker//-->
<!--PUBLISHER=Macmillan Computer Publishing//-->
<!--IMPRINT=Sams//-->
<!--CHAPTER=56//-->
<!--PAGES=906-909//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="904-906.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="909-911.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A><FONT COLOR="#000077">Deltas</FONT></H4>
<P>The set of changes that RCS records for an RCS file is referred to as a <I>delta</I>. The version number has two forms. The first form contains a release number and a level number. The release number is normally used to reflect a significant change to the code in the file. When you first create an RCS file, it is given a default release of 1 and level of 1 (1.1). RCS automatically assigns incrementally higher integers for the level number within a release (for example, 1.1, 1.2, 1.3, and so on). RCS enables you to override this automatic incrementing whenever you want to upgrade the version to a new release.</P>
<P>The second form of the version number also has the release and level components, but adds a branch number followed by a sequence number. You might use this form if you were developing a program for a client that required bug fixes, but you don’t want to place these fixes in the next “official” version. Although the next version may include these fixes anyway, you may be in the process of adding features that would delay its release. For this reason, you would add a branch to your RCS file for this other development stream, which would then progress with sequence increments. For example, imagine that you have a planned development stream of 3.1, 3.2, 3.3, 3.4, and so on. You realize that you need to introduce a bug fix stream at 3.3, which will not include the functionality proposed for 3.4. This bug fix stream would have a numbering sequence of 3.3.1.1, 3.3.1.2, 3.3.1.3, and so on.</P>
<BLOCKQUOTE>
<P><FONT SIZE="-1"><HR><B>Tip: </B><BR>As a matter of good development practice, each level or sequence should represent a complete set of changes. That implies that the code in each version is tested to be free of any obvious bugs. You shouldn’t jump from version 2.00 to 3.00, for example, just because you fixed a few bugs in 2.00. Usually, major version increases are related to additional features, not maintenance releases.<HR></FONT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><FONT SIZE="-1"><HR><B>Note: </B><BR>Is any code ever completely bug-free? This certainly isn’t the case for complex programs in which bugs may become apparent only when code is integrated from different developers. Your aim is to make at least your own part of the world bug-free. While we’ll never achieve bug-free programs, we can minimize the potential bugs and isolate the few that remain much more easily.<HR></FONT>
</BLOCKQUOTE>
<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">Creating an RCS file</FONT></H4>
<P>Let’s assume that you have the following file of C code, called <TT>finest.c</TT>:</P>
<!-- CODE SNIP //-->
<PRE>
/* A little something for RCS */
#include <stdio.h>
main()
{
printf(“Programming at its finest…\n”);
}
</PRE>
<!-- END CODE SNIP //-->
<P>The first step in creating an RCS file is to make an RCS directory:
</P>
<!-- CODE SNIP //-->
<PRE>
$ mkdir RCS
</PRE>
<!-- END CODE SNIP //-->
<P>This is where your RCS files are maintained. You can then check a file into RCS by issuing the <TT>ci</TT> (check-in) command. Using your trusty <TT>finest.c</TT> program, enter the fol-lowing:</P>
<!-- CODE SNIP //-->
<PRE>
$ ci finest.c
</PRE>
<!-- END CODE SNIP //-->
<P>This operation prompts for comments and then creates a file in the RCS directory called <TT>finest.c,v</TT>, which contains all the deltas on your file. After this, RCS transfers the contents of the original file and denotes it as revision 1.1. Anytime that you check in a file, RCS removes the working copy from the RCS directory.</P>
<H4 ALIGN="LEFT"><A NAME="Heading12"></A><FONT COLOR="#000077">Retrieving an RCS File</FONT></H4>
<P>To retrieve a copy of your file, use the <TT>co</TT> (check-out) command. If you use this command without any parameters, RCS gives you a read-only version of the file, which you can’t edit. You need to use the <TT>-l</TT> option in order to obtain a version of the file that you can edit.</P>
<!-- CODE SNIP //-->
<PRE>
$ co -l finest.c
</PRE>
<!-- END CODE SNIP //-->
<P>Whenever you finish making changes to the file, you can check it back in using <TT>ci</TT>. RCS prompts for text that is entered as a log of the changes made. This time the <TT>finest.c</TT> file is deposited as revision 1.2.</P>
<P>RCS revision numbers consist of release, level, branch, and sequence components. RCS commands typically use the most recent version of a file, unless they are instructed otherwise. For instance, say that the most recent version of <TT>finest.c</TT> is 2.7. If you want to check in <TT>finest.c</TT> as release 3, issue the <TT>ci</TT> command with the <TT>-r</TT> option, like this:</P>
<!-- CODE SNIP //-->
<PRE>
$ ci -r3 finest.c
</PRE>
<!-- END CODE SNIP //-->
<P>This creates a new release of the file as 3.1. You can also start a branch at revision 2.7 by issuing the following:
</P>
<!-- CODE SNIP //-->
<PRE>
$ ci -r2.7.1 finest.c
</PRE>
<!-- END CODE SNIP //-->
<P>You can remove out-of-date versions with the <TT>rcs</TT> command and its <TT>-o</TT> option.</P>
<!-- CODE SNIP //-->
<PRE>
$ rcs -o2.6 finest.c
</PRE>
<!-- END CODE SNIP //-->
<H4 ALIGN="LEFT"><A NAME="Heading13"></A><FONT COLOR="#000077">Using Keywords</FONT></H4>
<P>RCS lets you enter keywords as part of a file. These keywords contain specific information about such things as revision dates and creator names that can be extracted using the <TT>ident</TT> command. Keywords are embedded directly into the working copy of a file. When that file is checked in and checked out again, these keywords have values attached to them. The syntax is</P>
<!-- CODE SNIP //-->
<PRE>
$keyword$
</PRE>
<!-- END CODE SNIP //-->
<P>which is transformed into
</P>
<!-- CODE SNIP //-->
<PRE>
$keyword: value$
</PRE>
<!-- END CODE SNIP //-->
<P>Some keywords used by RCS are shown in the following list:
</P>
<TABLE WIDTH="80%"><TR>
<TD WIDTH="40%" ALIGN="LEFT"><TT>$Author$</TT>
<TD WIDTH="60%" ALIGN="LEFT">The user who checked in a revision
<TR>
<TD><TT>$Date$</TT>
<TD>The date and time of check-in
<TR>
<TD VALIGN="TOP"><TT>$Log$</TT>
<TD>Accumulated messages that describe the file
<TR>
<TD><TT>Revision$</TT>
<TD>The revision number
</TABLE>
<P>If your <TT>finest.c</TT> file used the keywords from the previous table, the command</P>
<!-- CODE SNIP //-->
<PRE>
$ ident finest.c
</PRE>
<!-- END CODE SNIP //-->
<P>produces output like this:
</P>
<!-- CODE //-->
<PRE>
$Author: pete $
$Date: 95/01/15 23:18:15 $
$Log: finest.c,v $
# Revision 1.2 95/01/15 23:18:15 pete
# Some modifications
#
# Revision 1.1 95/01/15 18:34:09 pete
# The grand opening of finest.c!
#
$Revision: 1.2 $
</PRE>
<!-- END CODE //-->
<P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="904-906.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="909-911.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?