DOCSLIB.ORG

Revision Control (RCS, CVS, Git)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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 finished 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 files. 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 influential 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 file 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 conflicts, 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 first 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 files 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 filesand 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 files will not be altered but shipped off 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 files cvs co ProgABS To checkout a praticular (previous) release or build: cvs co -r Rel-1A ProgABC To pull out a single file for editing without getting the whole project, iss e the command cvs edit ProgABC/file.c 5. Checkin/Commit: When done editing the files, check-in (commit) your changes. Here are com- mands 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 files 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 modified each line of a file. 3. checkout: Check out sources from the CVS repository for editing. 4. commit: Check files into the CVS repository. 5. diff: Show file differences between revisions. 6. export: Export sources from CVS. 7. history: Show status of files 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 files. 10. update: Bring local work directory in sync with repository 11. add: Add a file or directory to the repository. 12. delete: Delete a file 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 file as follows: ENG1410 F21 LAB4 Section(Wed,Thur,..) Group# Preparation.pdf • The preparation file can be hand written or typed. But has to be neat. 4 • The preparation file should consist of the flow 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 fulfills the require- ments. • 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.
Recommended publications
  • Generating Commit Messages from Git Diffs

    Generating Commit Messages from Git Diffs

    Generating Commit Messages from Git Diffs Sven van Hal Mathieu Post Kasper Wendel Delft University of Technology Delft University of Technology Delft University of Technology [email protected] [email protected] [email protected] ABSTRACT be exploited by machine learning. The hypothesis is that methods Commit messages aid developers in their understanding of a con- based on machine learning, given enough training data, are able tinuously evolving codebase. However, developers not always doc- to extract more contextual information and latent factors about ument code changes properly. Automatically generating commit the why of a change. Furthermore, Allamanis et al. [1] state that messages would relieve this burden on developers. source code is “a form of human communication [and] has similar Recently, a number of different works have demonstrated the statistical properties to natural language corpora”. Following the feasibility of using methods from neural machine translation to success of (deep) machine learning in the field of natural language generate commit messages. This work aims to reproduce a promi- processing, neural networks seem promising for automated commit nent research paper in this field, as well as attempt to improve upon message generation as well. their results by proposing a novel preprocessing technique. Jiang et al. [12] have demonstrated that generating commit mes- A reproduction of the reference neural machine translation sages with neural networks is feasible. This work aims to reproduce model was able to achieve slightly better results on the same dataset. the results from [12] on the same and a different dataset. Addition- When applying more rigorous preprocessing, however, the per- ally, efforts are made to improve upon these results by applying a formance dropped significantly.
  • Introduction to Version Control with Git

    Introduction to Version Control with Git

    Warwick Research Software Engineering Introduction to Version Control with Git H. Ratcliffe and C.S. Brady Senior Research Software Engineers \The Angry Penguin", used under creative commons licence from Swantje Hess and Jannis Pohlmann. March 12, 2018 Contents 1 About these Notes1 2 Introduction to Version Control2 3 Basic Version Control with Git4 4 Releases and Versioning 11 Glossary 14 1 About these Notes These notes were written by H Ratcliffe and C S Brady, both Senior Research Software Engineers in the Scientific Computing Research Technology Platform at the University of Warwick for a series of Workshops first run in December 2017 at the University of Warwick. This document contains notes for a half-day session on version control, an essential part of the life of a software developer. This work, except where otherwise noted, is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Li- cense. To view a copy of this license, visit http://creativecommons.org/ licenses/by-nc-nd/4.0/. The notes may redistributed freely with attribution, but may not be used for commercial purposes nor altered or modified. The Angry Penguin and other reproduced material, is clearly marked in the text and is not included in this declaration. The notes were typeset in LATEXby H Ratcliffe. Errors can be reported to [email protected] 1.1 Other Useful Information Throughout these notes, we present snippets of code and pseudocode, in particular snippets of commands for shell, make, or git. These often contain parts which you should substitute with the relevant text you want to use.
  • Efficient Algorithms for Comparing, Storing, and Sharing

    Efficient Algorithms for Comparing, Storing, and Sharing

    EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2012 Major Subject: Computer Science EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Tiffani L. Williams Committee Members, Nancy M. Amato Jennifer L. Welch James B. Woolley Head of Department, Hank W. Walker May 2012 Major Subject: Computer Science iii ABSTRACT Efficient Algorithms for Comparing, Storing, and Sharing Large Collections of Evolutionary Trees. (May 2012) Suzanne Jude Matthews, B.S.; M.S., Rensselaer Polytechnic Institute Chair of Advisory Committee: Dr. Tiffani L. Williams Evolutionary relationships between a group of organisms are commonly summarized in a phylogenetic (or evolutionary) tree. The goal of phylogenetic inference is to infer the best tree structure that represents the relationships between a group of organisms, given a set of observations (e.g. molecular sequences). However, popular heuristics for inferring phylogenies output tens to hundreds of thousands of equally weighted candidate trees. Biologists summarize these trees into a single structure called the consensus tree. The central assumption is that the information discarded has less value than the information retained. But, what if this assumption is not true? In this dissertation, we demonstrate the value of retaining and studying tree collections.
  • Higher Inductive Types (Hits) Are a New Type Former!

    Higher Inductive Types (Hits) Are a New Type Former!

    Git as a HIT Dan Licata Wesleyan University 1 1 Darcs Git as a HIT Dan Licata Wesleyan University 1 1 HITs 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! They were originally invented[Lumsdaine,Shulman,…] to model basic spaces (circle, spheres, the torus, …) and constructions in homotopy theory 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! They were originally invented[Lumsdaine,Shulman,…] to model basic spaces (circle, spheres, the torus, …) and constructions in homotopy theory But they have many other applications, including some programming ones! 2 Generator for 2 equality of equality Patches Patch a a 2c2 diff b d = < b c c --- > d 3 3 id a a b b
  • Bluej Teamwork Repository Configuration

    Bluej Teamwork Repository Configuration

    BlueJ Teamwork Repository Configuration Version 2.0 for BlueJ Version 2.5.0 (and 2.2.x) Davin McCall School of Engineering & IT, Deakin University 1 Introduction This document gives a brief description of how you might set up a version control repository for use with BlueJ’s teamwork features. It is intended mainly as a “quick start” guide and not as a complete reference – for that you should refer to the version control software documentation (i.e. the CVS manual or the Subversion manual) – but it does explain some BlueJ-specific concepts (such as how BlueJ supports the notion of student groups or teams). Setting up a repository usually requires a server to which you have “root” or administrator access. This may mean that you need to ask a Systems Administrator to set up the repository for you. Since BlueJ version 2.5.0, both Subversion and CVS are supported version control systems. BlueJ version 2.2.x supports only CVS. BlueJ versions prior to 2.2.0 did not support teamwork features. Chapters 2 and 3 explain how to set up and test a repository using CVS. Chapter 4 then covers the equivalent steps for using Subversion. 2 Setting up a simple single user CVS repository for testing the BlueJ teamwork features 2.1 Setting up the repository server On Unix / Linux / MacOS X: You must have the CVS software installed on the machine you intend to use as a server. There is a good chance that it is already installed, but if not, your vendor or distribution provider will almost certainly provide packages that can be installed.
  • Homework 0: Account Setup for Course and Cloud FPGA Intro Questions

    Homework 0: Account Setup for Course and Cloud FPGA Intro Questions

    Cloud FPGA Homework 0 Fall 2019 Homework 0 Jakub Szefer 2019/10/20 Please follow the three setup sections to create BitBucket git repository, install LATEX tools or setup Overleaf account, and get access to the course's git repository. Once you have these done, answer the questions that follow. Submit your solutions as a single PDF file generated from a template; more information is at end in the Submission Instructions section. Setup BitBucket git Repository This course will use git repositories for code development. Each student should setup a free BitBucket (https://bitbucket.org) account and create a git repository for the course. Please make the repository private and give WRITE access to your instructor ([email protected]). Please send the URL address of the repository to the instructor by e-mail. Make sure there is a README:md file in the repository (access to the repository will be tested by a script that tries to download the README:md from the repository address you share). Also, if you are using a Apple computer, please add :gitignore file which contains one line: :DS Store (to prevent the hidden :DS Store files from accidentally being added to the repository). If you have problems accessing BitBucket git from the command line, please see the Appendix. Setup LATEX and Overleaf Any written work (including this homework's solutions) will be submitted as PDF files generated using LATEX [1] from provided templates. Students can setup a free Overleaf (https://www. overleaf.com) account to edit LATEX files and generate PDFs online; or students can install LATEX tools on their computer.
  • Version Control – Agile Workflow with Git/Github

    Version Control – Agile Workflow with Git/Github

    Version Control – Agile Workflow with Git/GitHub 19/20 November 2019 | Guido Trensch (JSC, SimLab Neuroscience) Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 2 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 3 Motivation • Version control is one aspect of configuration management (CM). The main CM processes are concerned with: • System building • Preparing software for releases and keeping track of system versions. • Change management • Keeping track of requests for changes, working out the costs and impact. • Release management • Preparing software for releases and keeping track of system versions. • Version control • Keep track of different versions of software components and allow independent development. [Ian Sommerville,“Software Engineering”] Forschungszentrum Jülich, JSC:SimLab Neuroscience 4 Motivation • Keep track of different versions of software components • Identify, store, organize and control revisions and access to it • Essential for the organization of multi-developer projects is independent development • Ensure that changes made by different developers do not interfere with each other • Provide strategies to solve conflicts CONFLICT Alice Bob Forschungszentrum Jülich, JSC:SimLab Neuroscience 5 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich,
  • Revision Control

    Revision Control

    Revision Control Tomáš Kalibera, (Peter Libič) Department of Distributed and Dependable Systems http://d3s.mff.cuni.cz CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics Problems solved by revision control What is it good for? Keeping history of system evolution • What a “system” can be . Source code (single file, source tree) . Textual document . In general anything what can evolve – can have versions • Why ? . Safer experimentation – easy reverting to an older version • Additional benefits . Tracking progress (how many lines have I added yesterday) . Incremental processing (distributing patches, …) Allowing concurrent work on a system • Why concurrent work ? . Size and complexity of current systems (source code) require team work • How can concurrent work be organized ? 1. Independent modifications of (distinct) system parts 2. Resolving conflicting modifications 3. Checking that the whole system works . Additional benefits . Evaluating productivity of team members Additional benefits of code revision control • How revision control helps . Code is isolated at one place (no generated files) . Notifications when a new code version is available • Potential applications that benefit . Automated testing • Compile errors, functional errors, performance regressions . Automated building . Backup • Being at one place, the source is isolated from unneeded generated files . Code browsing • Web interface with hyperlinked code Typical architecture Working copy Source code repository (versioned sources) synchronization Basic operations • Check-out . Create a working copy of repository content • Update . Update working copy using repository (both to latest and historical version) • Check-in (Commit) . Propagate working copy back to repository • Diff . Show differences between two versions of source code Simplified usage scenario Source code Check-out or update repository Working 1 copy 2 Modify & Test Check-in 3 Exporting/importing source trees • Import .
  • FAKULTÄT FÜR INFORMATIK Leveraging Traceability Between Code and Tasks for Code Reviews and Release Management

    FAKULTÄT FÜR INFORMATIK Leveraging Traceability Between Code and Tasks for Code Reviews and Release Management

    FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Jan Finis FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Einsatz von Nachvollziehbarkeit zwischen Quellcode und Aufgaben für Code Reviews und Freigabemanagement Author: Jan Finis Supervisor: Prof. Bernd Brügge, Ph.D. Advisors: Maximilian Kögel, Nitesh Narayan Submission Date: May 18, 2011 I assure the single-handed composition of this master’s thesis only supported by declared resources. Sydney, May 10th, 2011 Jan Finis Acknowledgments First, I would like to thank my adviser Maximilian Kögel for actively supporting me with my thesis and being reachable for my frequent issues even at unusual times and even after he left the chair. Furthermore, I would like to thank him for his patience, as the surrounding conditions of my thesis, like me having an industrial internship and finishing my thesis abroad, were sometimes quite impedimental. Second, I want to thank my other adviser Nitesh Narayan for helping out after Max- imilian has left the chair. Since he did not advise me from the start, he had more effort working himself into my topic than any usual adviser being in charge of a thesis from the beginning on. Third, I want to thank the National ICT Australia for providing a workspace, Internet, and library access for me while I was finishing my thesis in Sydney. Finally, my thanks go to my supervisor Professor Bernd Brügge, Ph.D.
  • Distributed Revision Control with Mercurial

    Distributed Revision Control with Mercurial

    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
  • Scaling Git with Bitbucket Data Center

    Scaling Git with Bitbucket Data Center

    Scaling Git with Bitbucket Data Center Considerations for large teams switching to Git Contents What is Git, why do I want it, and why is it hard to scale? 01 Scaling Git with Bitbucket Data Center 05 What about compliance? 11 Why choose Bitbucket Data Center? 13 01 What is Git, why do I want it, and why is it hard to scale? So. Your software team is expanding and taking on more high-value projects. That’s great news! The bad news, however, is that your centralized version control system isn’t really cutting it anymore. For growing IT organizations, Some of the key benefits Codebase safety moving to a distributed version control system is now of adopting Git are: Git is designed with maintaining the integrity considered an inevitable shift. This paper outlines some of managed source code as a top priority, using secure algorithms to preserve your code, change of the benefits of Git as a distributed version control system history, and traceability against both accidental and how Bitbucket Data Center can help your company scale and malicious change. Distributed development its Git-powered operations smoothly. Community Distributed development gives each developer a working copy of the full repository history, Git has become the expected version control making development faster by speeding up systems in many circles, and is very popular As software development increases in complexity, and the commit process and reducing developers’ among open source projects. This means its easy development teams become more globalized, centralized interdependence, as well as their dependence to take advantage of third party libraries and on a network connection.
  • Source Code Revision Control Systems and Auto-Documenting

    Source Code Revision Control Systems and Auto-Documenting

    Source Code Revision Control Systems and Auto-Documenting Headers for SAS® Programs on a UNIX or PC Multiuser Environment Terek Peterson, Alliance Consulting Group, Philadelphia, PA Max Cherny, Alliance Consulting Group, Philadelphia, PA ABSTRACT This paper discusses two free products available on UNIX and PC RCS, which is a more powerful utility than SCCS, was written in environments called SCCS (Source Code Control System) and early 1980s by Walter F. Tichy at Purdue University in Indiana. It RCS (Revision Control System). When used in a multi-user used many programs developed in the 1970s, learning from environment, these systems give programmers a tool to enforce mistakes of SCCS and can be seen as a logical improvement of change control, create versions of programs, document changes SCCS. Since RCS stores the latest version in full, it is much to programs, create backups during reporting efforts, and faster in retrieving the latest version. RCS is also faster than automatically update vital information directly within a SASâ SCCS in retrieving older versions and RCS has an easier program. These systems help to create an audit trail for interface for first time users. RCS commands are more intuitive programs as required by the FDA for a drug trial. than SCCS commands. In addition, there are less commands, the system is more consistent and it has a greater variety of options. Since RCS is a newer, more powerful source code INTRODUCTION control system, this paper will primarily focus on that system. The pharmaceutical industry is one of the most regulated industries in this country. Almost every step of a clinical trial is subject to very strict FDA regulations.