Revision Control (RCS, CVS, Git)

Home , CVSNT, Git, Revision control system

ENGG1410: Introductory Programming for Engineers Lab 4: “Introduction to C Programming”: Revision Control (RCS, CVS, Git)

Shawki Areibi School of Engineering, University of Guelph Fall 2021

Start Date: Week #5 2021 Duration: 1 Week Report Due Date: Week #6 2021, Drop Box

1 Objectives:

The purpose of this lab is to:

• introduce you to the concept of version control

• teach you how to use cvs.

• expose you to all the useful commands within cvs.

2 Introduction

In the software development process, revision control, also known as version control or source control, is the management of changes made over time. These changes can be to source code, project assets, or any other information that goes into the ﬁnished product. It permits many people to work on the same parts of a project without worrying that their changes will overwrite the work of anyone else. The collection of revisions and their metadata is called a repository or repo. The repository represents a step-by-step chronological record of every change made to help project managers revert all or part of the project to a previous state if necessary.

2.1 Centralized vs. Distributed Systems If a revision control systems uses a centralized repository, its data is contained in a single database con- taining the authoritative version of all project ﬁles. Other systems employ a distributed model. In these systems, changes can be checked, and then synchronized between repositories. Two popular software packages used for revision control include “CVS” and “Git”. First developed in 1986, CVS is a venerable and inﬂuential revision control system, last updated in 2008. While still used for smaller projects, CVS lacks many of the characteristics of modern revision control that are crucial for large- scale professional software development. Variants of CVS include CVSNT, which supports case-insensitive

1 ﬁle names, and OpenCVS that uses stronger security methods. “Git” on the other hand is a distributed revision control system designed and implemented by Linus Torvalds for use in the development of the Linux kernel. First released in 2005, Git is now the most widely-used version control system in the world. The software is free, open source, and released under the GPL.

2.2 How Revisions are made? Revision control systems are usually hosted on a networked server. After the repository is set up, using it generally involves the following steps:

1. If the developer has created a new file that should become part of the project, the file must be added to the repository. The file is uploaded to the repository, and anyone else working on the project can see and use the file.

2. If the developer wants to edit a file that is already part of the project, the file must be checked out. The act of checking out downloads the desired revision of the file to the developer’s local version of the project. Usually, the revision that a developer wants to edit is the most recent revision: this revision is known as the ”head”.

3. After the developer edits the file locally and is ready to add it to the official version of the project, the file can be checked in. This action is also known as making a commit. The developer is asked to write a summary of what changes were made and why. These comments, with the updated version of the file, are uploaded to the repository.

4. If someone else has checked in revisions to the same file since the last time the developer checked it out, the system announces that there are conflicts. It calculates the differences line-by-line, and the developers who made the changes must agree upon how their individual changes should be merged. The merging is usually done manually: the developers compare the conflicting versions and decide how to resolve them into one document.

5. If there are no conﬂicts, the new version is updated in the repository, and the entire project receives a new revision number, permanently and uniquely identifying its current state.

3 CVS

CVS is primarily used as a source code control system for text files. Programmers will generate revisions to individual source code files. A collection of these files may define a specific software release. CVS aims to manage the collection of these files and the respective revisions of the individual files that make up the collection. CVS is a command driven file checkout, update, compare and management system. Front end web and desktop GUI systems are available to ease the use of CVS. The first step in using CVS is setting up your environment for CVS. For example if you are a csh user then you will setup the environment by the following: setenv CVSROOT ’/home/Project/CVS_root’ setenv CVSEDITOR /bin/vi

2 3.1 How to use CVS? Below are several useful commands along with options that demonstrate how CVS can be used to create, import, export, checkout, update, and check-in changes. 1. Creating cvs repository for the ﬁrst time: the user has to issue the following command

cvs -d /home/Project/CVS_root init

Note: this is the CM repostitory and not a developer working area. No work, editing of ﬁles or changes should be made directly to this directory. Files are edited in the user’s local working directory. 2. Importing a new project: The command “import” is used put the project under CVS control. The user will check in all ﬁlesand directories from within the current working directory. Below is an example of the command entered by the user. The command notation is:

import [-options] repositoryName vendortag releasetag cvs import -m "Put text description here" ProgABC CorpABC start

3. Exporting a project: The command “export” is used to get a copy of the sources and directories with the intent that the ﬁles will not be altered but shipped oﬀ site. So if an original release is required to be extracted then the user should issue the following command:

cvs export -r start ProgABS

4. Checkout Build: The command “checkout or co” is used to extract a directory with all its subdi- rectories of the project along with its ﬁles

cvs co ProgABS

To checkout a praticular (previous) release or build:

cvs co -r Rel-1A ProgABC

To pull out a single ﬁle for editing without getting the whole project, iss e the command

cvs edit ProgABC/file.c

5. Checkin/Commit: When done editing the ﬁles, check-in (commit) your changes. Here are commands that will commit the changes

cvs ci file.c cvs ci -m "Put text description here" file.c cvs ci -m "Put text description here" ProgABC

6. Add/Delete Files: Programmers can either add or delete ﬁles from the repo by issuing the following commands:

cvs add file.c cvs add fileA.c fileB.c fileC.c cvs delete file.c

3 3.2 CVS Commands Below is a list of the most important CVS commands:

1. admin: CVS interface to assorted administrative facilities.

2. annotate: Shows the revision modiﬁed each line of a ﬁle.

3. checkout: Check out sources from the CVS repository for editing.

4. commit: Check ﬁles into the CVS repository.

5. diff: Show file differences between revisions.

6. export: Export sources from CVS.

7. history: Show status of ﬁles and users.

8. import: Import sources into CVS. Used for initial checkin of code into the CVS root repository.

9. log: Print out log information for ﬁles.

10. update: Bring local work directory in sync with repository

11. add: Add a ﬁle or directory to the repository.

12. delete: Delete a ﬁle or directory from the repository.

3.3 CVS Utility: Useful Resources Here are useful Version Control resources:

• CVS - Concurrent Version System for Managing File Versions (YouTube) CVS “Concurrent Version System”

• Git Tutorial for Begineers – Github Version Control) Github Version Control

• CVS Intro, Commands and Examples CVS Intro, Commands and Examples

4 Requirements

Enter, compile and execute the program that implements the following functionality:

5 Deliverables

1. Lab Preparation File:

• Name your ﬁle as follows: ENG1410 F21 LAB4 Section(Wed,Thur,..) Group# Preparation.pdf • The preparation ﬁle can be hand written or typed. But has to be neat.

4 • The preparation ﬁle should consist of the ﬂow chart and pseudo code. • Only one submission is allowed.

2. Lab Final Report File:

• Name your file as follows: ENG1410 F21 LAB4 Section(Wed,Thur,..) Group# FinalReport.pdf • Check the format of the final report below in the next section. • Keep the first page only for the title page. • Only one submission is allowed.

3. Zipped Project File:

• Name your file as follows: ENG1410 F21 LAB4 Section(Wed,Thur,..) Group# Project.zip • The project file should have a README file that explains the input and output of your program.

4. DEMO:

• You will need to demonstrate to the Teaching Assistant that your program fulﬁlls the requirements. • The DEMO will take place during the LAB hours and not outside these hours.

5 6 Report

Below is the general format of the report required:

1. Title Page:

• Course #, and Date • Lab # and name of experiment • Your Group #, and Names

2. Start a new page and explain how you implemented your design by providing the following:

(a) Problem Statement, i. Briefly describe the problem solved in the lab. (b) Assumptions and Constraints. i. Constraints could be for example no optimization with compilation. (c) How you solved the Problem, i. Flowchart. ii. Pseudo Code. iii. Block Diagram. (d) System Overview & Justification of Design i. Give an overview of the system to be designed. ii. Briefly explain how the system works and reasons behind the design.

3. Error Analysis

(a) Confirm no syntax errors are present. (b) Confirm no semantic and logical errors are present. (c) Describe any problems with your program. (d) If no problems in the final system, describe problems/errors encountered during the development and how they were resolved.