Source Code Control System in UNIX:SCCS Command Structure and CVS : Concurrent Versioning System.

By -

SCCS Command Structure

We can appreciate the commands under SCCS better if we first try to understand the design considerations. Below we enumerate some of the points which were borne in mind by the designers when SCCS was created initially.

• Between two revisions a file under SCCS is considered to be idle.

• Between two adjacent versions, both idles, there is only a small change in the content. This change is regarded as delta. Suppose for some file F there is a delta change d, then one needs to maintain both F and d to be able to do the version management. This is because SCCS supports versioning at every node in a version tree.

• Version numbers can be generated automatically. The delta changes finally result in creating a hierarchy. In fact, version numbers determine the traversal required on the version tree to spot a particular version.

• We need a command use to indicate which file we retrieve and a command delta to indicate the change that needs to be incorporated. That then explains the command structure for SCCS.

Figure 17.2 illustrates the manner in which an SCCS encoded file may be generated.

clip_image001

Figure 17.2: The “idle" and “revision" periods in SCCS.

Such files may subsequently go through an evolution with several idle periods in between. When a file is retrieved, it is decoded for normal viewing and presented. Usually, one uses the delta command to create a new version. Based on the version taken up for revision, a new version number is generated automatically.

17.3.1 An Example Session

In this example session we have used some command options. In Table 17.1 we give explanation for options available with various SCCS commands.

To begin with we need to create a new file. We may do so as follows:

admin -n s.testfile

clip_image002

Table 17.1: SCCS command options.

This command creates an SCCS formatted file with an empty body. The options used with admin command have interpretations given in table 17.1.

We can now use the visual editor and put some text into it.

get -e s.testfile

The -e option is to invoke ”open for edit". This command prints the version number and number of lines in testfile. If we perform a delta, we can create a newer version of testfile. This can be done simply as follows:

delta s.testfile

We may just add comments or actually make some changes. This can be now checked by using a visual editor again.

Unix provides a facility to view any file with a given version number. For example, to view and run a certain previous version 1.2, we may use the command shown below.

get -p -r1.2 s.testfile

The -p option is to invoke a path and -r is to invoke a run.

Like Make, SCCS also supports some macros. Readers should consult their system's documentation to study the version management in all its facets. We shall next take a brief tour of CVS.

CVS : Concurrent Versioning System

Linux environment offers a concurrent versioning utility, called CVS which supports on- current development of a project. The team members in the project team may make concurrent updates as the project evolves. The primary idea in CVS revolves around maintaining a project repository which always reflects the current official status of the project. CVS allows project developers to work on parts of the project by making copies of the project in their own scratch pad areas. Updates on the work-in-progress scratch pads do not affect the repository. Individuals may seek to finalize their work on the scratch pad and write back to the repository to update a certain aspect of the project. Technically, it is quite possible for more than one individual to make copies and develop the same program. However, this can raise consistency problems. So writing back into the repository is done in a controlled way. If the updates are in different parts, these are carried out with no conflict. If the updates are in the same part of a file, a merge conflict may occur and these are reported. These conflicts need to be reconciled before a commit into the repository is performed.

Essentially, CVS is a command line utility in Linux (and also in some other flavors of Unix). There are network versions of CVS that allow access to repository over the network as well. For now we shall assume that we have a CVS utility available on a single machine with multiple users accessing the files in it. Let us examine some typical usage scenarios of CVS commands. For example, consider the command lines below. export CVSROOT=/homes/iws/damu/cvs

cvs checkout project-5

The first command line is to look for the cvs command in user damu's home directory. The second line basically checks out what files are there in project-5. It also makes the copies of project-5 files available to the user. Typically, these may be some .c or .h files or some others like .tex files. As we stated earlier, CVS supports an update phase of operation. The update command and a typical response from it are shown next.

cvs update project-5

When one attempts to update, typically the system prompts to indicate if someone else also made any updates after you had copied the files. In other words, all the updates that occurred in sequence from different people are all shown in order. Each update obtains a distinct version number. Like SCCS, CVS also generates internally a numbering scheme which will give a versioning tree. In the case someone else’s' update is at the same location in a file, then the messages would indicate if there is a merge conflict. A response to a typical update command is shown below:

$ cvs update

cvs update: Updating .

RCS file: /homes/iws/damu/cvs/project-5/main.c,v retrieving revision 1.1

retrieving revision 1.2

Merging differences between 1.1 and 1.2 into proj.h M proj.h

U main.c

In the example above we had no merge conflicts. In case of a merge conflict, we get messages to indicate that. Let us assume we have merge conflict in updating main.c, then the messages we may get would look like those shown below.

$ cvs update

cvs update: Updating .

RCS file: /homes/iws/damu/cvs/project-5/main.c,v retrieving revision 1.2

retrieving revision 1.3

Merging differences between 1.2 and 1.3 into main.c rcsmerge: warning: conflicts during merge

cvs update: conflicts found in main.c C main.c

Usually, the conflicts are shown with some repeated character sequence to help identify where it occurred. One, therefore, needs to resolve the conflicts and then may be commit the correctly updated version to repository. A CVS commit generates a newer version in repository. A CVS commit command and its response is shown below.

$ cvs commit

cvs commit: Examining . Checking in main.c;

/homes/iws/damu/cvs/project-5/main.c,v <-- main.c new revision: 1.2; previous revision: 1.1

done

The steps shown above for checkout, update and commit are the basic steps. There are means available to import an entire project and effect an update to create a newer version of the project. For those details the reader is advised to refer to the man pages.

Comments

Post a Comment

Popular posts from this blog

Input Output (IO) Management:HW/SW Interface and Management of Buffers.

By -
Image
5.3 HW/SW Interface IO management requires that a proper set-up is created by an application on computer system with an IO device. An IO operation is a combination of HW and SW instructions as shown in Figure 5.8. Following the issuance of an IO command, OS kernel resolves it, and then communicates Figure 5.8: Communication with IO devices. with the concerned device driver. The device drivers in turn communicate with IO devices. The application at the top level only communicates with the kernel. Each IO request from an application results in generating the following: Naming or identification of the device to communicate. Providing device independent data to communicate; The kernel IO subsystem arranges for the following: The identification of the relevant device driver. We discuss device drivers in Section 5.3.1. Allocation of buffers. We discuss buffer management in Section 5.4. Reporting of errors. Tracking the device usage (is the device free, who is the current u...
Read more

Introduction to Operating Systems:Early History: The 1940s and 1950s

By -
Early History: The 1940s and 1950s Operating systems have evolved over the last 60 years through several distinct phases or generations that correspond roughly to the decades (see the Operating Systems Thinking feature, Innovation).3 In the 1940s, the earliest electronic digital computers did not include operating systems.4, 5, 6 Machines of the time were so primitive that programmers often entered their machine-language programs one bit at a time on rows of mechanical switches. Eventually, programmers entered their machine-language programs on punched cards. Then, assembly languages—which used English-like abbreviations to represent the basic operations of the computer— were developed to speed the programming process. General Motors Research Laboratories implemented the first operating sys- tem in the early 1950s for its IBM 701 computer.7 The systems of the 1950s generally executed only one job at a time, using techniques that smoothed the transition between jobs to obtain maximu...
Read more

Input Output (IO) Management:IO Organization.

By -
Image
IO Organization In the previous section we discussed various issues that arise from the need to support a wide range of devices. To meet these varied requirements, a few well understood modalities have evolved over time. The basic idea is to select a mode of communication taking device characteristics into account or a need to synchronize with some event, or to just have a simple strategy to ensure a reliable assured IO. Computers employ the following four basic modes of IO operation: 1. Programmed mode 2. Polling mode 3. Interrupt mode 4. Direct memory access mode. We shall discuss each of these modes in some detail now. 5.2.1 Programmed Data Mode In this mode of communication, execution of an IO instruction ensures that a program shall not advance till it is completed. To that extent one is assured that IO happens before anything else happens. As depicted in Figure 5.1, in this mode an IO instruction is issued to an IO device and the program executes in “busy-waiting” (idli...
Read more