Source Code Control System in UNIX:How Does Versioning Help.

By -

Module 17: Source Code Control System in UNIX

A very large programming project evolves over time. It is also possible that many teams work concurrently on different parts of such a large system. In such a case each team is responsible for a certain part of the project. Their own segments evolve over time. These segments must dovetail with the rest of the project team efforts. So, during the development phase, each development team has to learn to manage changes as they happen. It is quite a common practice to proceed on the assumption of availability of some module at a future time. So, even while designing one's own mandated module, one needs to be able to account for some yet to be completed module(s). One may even have to integrate a newer version of a module with enhanced features. In some sense, a software may have several generations and versions of evolution. In industry parlance, these generations are sometimes called α or β releases. There may even be a version number to suit a certain specific configuration.

Unix supports these developmental possibilities, i.e. supporting creation and invocation of various versions by using a system support tool called SCCS. In this chapter we shall study how SCCS helps in versioning.

17.1 How Does Versioning Help

Essentially, a large software design is like an emerging collage in an art studio with many assistants assisting their master in developing a large mural. However, in the software design, the ability to undo has its charms. There are two major ways in which versioning helps. First, we should realize that a rollback may be required at any stage of development. Should it be the case then, it should then be possible for us to get back to an acceptable (and perhaps an operating) version of a file. From this version of file one may fork out to a newer file which is a better version. The forking may be needed to remove some errors which may have manifested or because it was felt necessary to add newer features.

Secondly, software should cater to users of various levels of abilities and workplace environments. For instance, a home version and office version of XP cater to different workplace environments even while offering truly compatible software suites. In other words, sometimes customers need to be provided with options to choose from and tune the software for an optimal usage which may entail making choices for features, adding

some or leaving a few others to leverage the advantage of a configuration with as little overhead as possible.

17.2 The SCCS

During the period of development, there will be modules in various stages of progression. As more modules become stable, the system comes along in small increments. Each stable set yields a fairly stable working version of the system. So the support one seeks from an operating system is to be able to lock each such version for limited access. In addition, one should be able to chain various stages of locked versions in a hierarchy to reflect particular software's evolution. Unix obtains this capability by using a version tree support mechanism. The version tree hierarchy is automatically generated. The version number identifies the evolution of different nodes in the version tree over time. A typical version tree numbering scheme is shown in Figure 17.1. The higher the number, the more recent is the version. The numbers appear as an extension to show the evolution. In the next few sections we see what is provided and how it is achieved under Unix.

clip_image001

Figure 17.1: A typical version tree under SCCS.

17.2.1 How This Is Achieved

Unix obtains this capability by maintaining a version tree with the following support mechanisms.

  • Version tree hierarchy is generated automatically and follows a numbering scheme as shown in figure 17.1. The numbering helps users to identify the evolution of software from the version tree. Internally, it helps Unix in maintaining differences between related versions of files.
  • The SCCS creates files in a special format.
  • The compilation is handled in a special way.
  • Edits to the files are handled in a special way. In fact one can edit files at any level in the version tree.
  • A suite of SCCS commands are provided to manage versions and create links in the version trees.

In addition, Unix provides the following facilities:

  • Unix permits locking out of modules under development. Some modules which are stable may be permitted full access. However, those versions of modules that are still evolving may not be accessible to all the users. The access to these modules may be restricted to this module's developers only. General users may have access to an older stable version of the module. It is possible to also add gid for access to a new version being released. In Unix the access is permitted for all (or none) in the group. So adding gid for a release adds all the users in that group.
  • For management of hierarchy, it is possible to create a tree structure amongst versions. At any stage of development it is possible to create siblings in a tree. Such a sibling can have its own child versions evolving through the sub-trees under it. As shown in Figure 17.1, the version tree grows organically as new versions emerge.
  • Unix supports precedence amongst the versions of a module. So if a module has a newer version (usually with some bugs removed or with extensions), then this module shall be the one that shall have precedence during the loading of modules. Often this is true of files where a file may be updated frequently.

Various Unix versions from BSD, System V or Linux provide SCCS-like tools under a variety of utility names. These are CSSC, CVS, RCS, linCVS, etc. We will briefly discuss CVS in Linux environment in Section 17.4. Obviously, more recent versions clearly have more bells and whistles. Now that we have explained the underlying concepts, we shall next explore the command structure in SCCS that makes it all happen.

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