ch55.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

<DL>

	<DD>

<HR>

<A NAME="Heading16<FONT COLOR="#000077"><B>NOTE: </B></FONT>Is any code completely

	bug-free? This certainly isn't the case for complex programs in which bugs might

	become apparent only when code is integrated from different developers. Your aim

	is to at least make your own part of the world bug-free.

<HR>



</DL>



<H4 ALIGN="CENTER"><A NAME="Heading17<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>:<FONT

COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">/* A little something for RCS */

#include &lt;stdio.h&gt;

main()

{

      printf(&quot;Programming at its finest...\n&quot;);



}

</FONT></PRE>

<P>The first step in creating an RCS file is to make an RCS directory:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ mkdir RCS

</FONT></PRE>

<P>This is where your RCS files will be 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 following:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ ci finest.c

</FONT></PRE>

<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.

<H4 ALIGN="CENTER"><A NAME="Heading18<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:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ co -l finest.c

</FONT></PRE>

<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:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ ci -r3 finest.c

</FONT></PRE>

<P>This creates a new release of the file as 3.1. You could also start a branch at

revision 2.7 by issuing the following:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ ci -r2.7.1 finest.c

</FONT></PRE>

<P>You can remove out-of-date versions with the <TT>rcs</TT> command and its <TT>-o</TT>

option:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcs -o2.6 finest.c

</FONT></PRE>

<H4 ALIGN="CENTER"><A NAME="Heading19<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<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$keyword$

</FONT></PRE>

<P>which is transformed into<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$keyword: value$

</FONT></PRE>

<P>Some keywords used by RCS are shown in the following list: 

<TABLE BORDER="0">

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>$Author$</TT> </TD>

		<TD ALIGN="LEFT">The user who checked in a revision </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>$Date$</TT> </TD>

		<TD ALIGN="LEFT">The date and time of check-in </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>$Log$</TT> </TD>

		<TD ALIGN="LEFT">Accumulated messages that describe the file </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT">





			<BLOCKQUOTE>

			<P><TT>Revision$</TT>



			</BLOCKQUOTE>



			<P>

		</TD>

		<TD ALIGN="LEFT">





			<BLOCKQUOTE>

			<P>The revision number



			</BLOCKQUOTE>



			<P>

		</TD>

	</TR>

</TABLE>

If your <TT>finest.c</TT> file used the keywords from the previous table, the command<FONT

COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ ident finest.c

</FONT></PRE>

<P>produces output like this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$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 $

</FONT></PRE>

<CENTER>

<H3><A NAME="Heading20<FONT COLOR="#000077">Retrieving Version Information

from an RCS File</FONT></H3>

</CENTER>

<P>Instead of querying the contents of an RCS file based on keywords, you might be

interested in obtaining summary information about the version attributes using the

<TT>rlog</TT> command with the <TT>-t</TT> option. On the <TT>finest.c</TT> RCS file,

the output from<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rlog -t finest.c

</FONT></PRE>

<P>would produce output formatted like this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">RCS file:      finest.c,v;   Working file:   finest.c

head:          3.2

locks:         pete: 2.1;  strict

access list: rick tim

aymbolic names:

comment leader:  &quot; * &quot;

total revisions: 10;

description:

You know...programming at its finest...

</FONT></PRE>

<P><TT>head </TT>refers to the version number of the highest revision in the entire

stream. <TT>locks</TT> describes which users have versions checked out and the type

of lock (strict or implicit for the RCS file owner). <TT>access list</TT> is a list

of users who have been authorized to make deltas on this RCS file. The next section

illustrates how user access privileges for an RCS file can be changed.

<CENTER>

<H3><A NAME="Heading21<FONT COLOR="#000077">Administering Access</FONT></H3>

</CENTER>

<P>One of the most important functions of RCS is to mediate the access of users to

a set of files. For each file, RCS maintains a list of users who have permission

to create deltas on that file. This list is empty to begin with, so that all users

have permission to make deltas. The <TT>rcs</TT> command is used to assign user names

or group names with delta privileges. The command<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcs -arick,tim finest.c

</FONT></PRE>

<P>enables the users Rick and Tim to make deltas on <TT>finest.c</TT> and simultaneously

restricts all other users (except the owner) from that privilege.</P>

<P>Perhaps you change your mind and decide that the user Rick is not worthy of making

deltas on your wonderful <TT>finest.c</TT> program. You can deny him that privilege

using the <TT>-e</TT> option:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">&amp; rcs -erick finest.c

</FONT></PRE>

<P>Suddenly, in a fit of paranoia, you can trust no one to make deltas on <TT>finest.c</TT>.

Like a software Mussolini, you place a global lock (which applies to everyone, including

the owner) on release 2 of <TT>finest.c</TT> using the <TT>-e</TT> and <TT>-L</TT>

options:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcs -e -L2 finest.c

</FONT></PRE>

<P>so that no one can make changes on any delta in the release 2 stream. Only the

file owner could make changes, but this person still would have to explicitly put

a lock on the file for every checkout and checkin operation.

<CENTER>

<H3><A NAME="Heading22<FONT COLOR="#000077">Comparing and Merging Revisions</FONT></H3>

</CENTER>

<P>Revisions can be compared to each other to discover what, if any, differences

lie between them. This can be used as a means of safely merging together edits of

a single source file by different developers. The <TT>rcsdiff</TT> command is used

to show differences between revisions existing in an RCS file, or between a checked-out

version and the most current revision in the RCS file. To compare the <TT>finest.c</TT>

1.2 version to the 1.5 version, enter the following:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcsdiff -r1.2 -r1.5 finest.c

</FONT></PRE>

<P>The output would appear something like the following:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">RCS file: finest.c,v

retrieving revision 1.1

rdiff  -r1.2 -r1.5 finest.c

6a7,8

&gt;

&gt; /* ...but what good is this? */

</FONT></PRE>

<P>This output indicates that the only difference between the files is that two new

lines have been added after the original line six. To just compare your current checked-out

version with that of the &quot;head&quot; version in the RCS file, simply enter the

following:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcsdiff finest.c

</FONT></PRE>

<P>Once you have determined if there are any conflicts in your edits with others,

you may decide to merge together revisions. You can do this with the <TT>rcsmerge</TT>

command. The format of this command is to take one or two filenames representing

the version to be merged, and a third filename indicating the working file (in the

following example, this is <TT>finest.c</TT>).</P>

<P>The command<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">$ rcsmerge -r1.3 -r1.6 finest.c

</FONT></PRE>

<P>produces output like this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">RCS file: finest.c,v

retrieving revision 1.3

retrieving revision 1.6

Merging differences between 1.3 and 1.6 into finest.c

</FONT></PRE>

<P>If any lines between the two files overlapped, <TT>rcsmerge</TT> would indicate

which lines originated from which merged file in the working copy. You would have

to resolve these overlaps by explicitly editing the working copy to remove any conflicts

before checking the working copy back into RCS.



<DL>

	<DT></DT>

</DL>





<DL>

	<DD>

<HR>

<A NAME="Heading23<FONT COLOR="#000077"><B>NOTE: </B></FONT>There is an implied

	order in which the files to be merged are placed in the <TT>rcsmerge</TT> command.

	If you are placing a higher version before a lower one at the <TT>-r</TT> options,

	this is essentially undoing the edits that have transpired from the older (lower)

	version to the newer (higher) version.

<HR>



</DL>



<CENTER>

<H3><A NAME="Heading24<FONT COLOR="#000077">Tying It All Together: Working

with make and RCS</FONT></H3>

</CENTER>

<P>The <TT>make</TT> program supports interaction with RCS, enabling you to have

a largely complete software development environment. However, the whole issue of

using <TT>make</TT> with RCS is a sticky one if your software project involves several

people sharing source code files. Clearly, it may be problematic if someone is compiling

files that you need to be stable in order to do your own software testing. This may

be more of a communication and scheduling issue between team members than anything

else. At any rate, using <TT>make</TT> with RCS can be very convenient for a single

programmer, particularly in the Linux environment.</P>

<P><TT>make</TT> can handle RCS files through the application of user-defined suffix

rules that recognize the <TT>,v</TT> suffix. RCS interfaces well with <TT>make</TT>

because its files use the <TT>,v</TT> suffix, which works well within a suffix rule.

You could write a set of RCS-specific suffix rules to compile C code as follows:<FONT

COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">CO = co

.c,v.o:

      ${CO} $&lt;

      ${CC} ${CFLAGS} -c $*.c

      - rm -f $*.c

</FONT></PRE>

<P>The <TT>CO</TT> macro represents the RCS check-out command. The <TT>$*.c</TT>

macro is necessary because <TT>make</TT> automatically strips off the <TT>.c</TT>

suffix. The hyphen preceding the <TT>rm</TT> command instructs <TT>make</TT> to continue,

even if the <TT>rm</TT> fails. For <TT>main.c</TT> stored in RCS, <TT>make</TT> generates

these commands:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">co main.c

cc -O -c main.c

rm -f main.c

</FONT></PRE>

<CENTER>

<H3><A NAME="Heading25<FONT COLOR="#000077">Summary</FONT></H3>

</CENTER>

<P>Linux offers two key utilities for managing software development: <TT>make</TT>

and RCS. <TT>make</TT> is a program that generates commands for compilation, linking,

and other related development activities. <TT>make</TT> can manage dependencies between

source code and object files so that an entire project can be recompiled as much

as is required for it to be up-to-date. RCS is a set of source code control programs

that enables several developers to work on a software project simultaneously. It

manages the use of a source code file by keeping a history of editing changes that

have been applied to it. The other benefit of versioning control is that it can,

in many cases, reduce disk space requirements for a project. CVS is an enhancement

to the RCS programs. It automatically provides for the merging of revisions. This

capability enables several developers to work on the same source code file at once,

with the caveat that they are responsible for any merging conflicts that arise.









</td>
</tr>
</table>
<!-- begin footer information -->


</body></html>