Concurrent Versioning System

Chapter 8 (ALBING’s)

CVS – Concurrent Versioning System

Version control system A tool that uses a database to store all revisions of

the project files managed Runs on UNIX, Windows (95 or NT), Macintosh, etc …

What does it do?Stores previous versions and easily retrieves themAllows a group of people to work on the code

simultaneouslyGuarantees conflict resolution without loss of any changes!

Allows developers to see who is editing files, what changes, and when and why that happened

Introduction

The database of revisions is often called a repository

Users checkout a copy of the project (files and directories) into their own local space All work is then made on the local copy (sandbox)

Changes made on the local copy can later be committed to the repository become visible to all other users

At commit time, the new revisions will be created in the repository (rather than overwriting the existing) Nothing will ever be lost! New versions will be created

Introduction If you try to commit files that are out of date, you will

be stopped with the error message "files are out of date: you must run cvs update first"

(or something to that effect)

A user can update her sandbox by adding changes that have been committed to the repository since the sandbox was last created or updated Committed changes made by other developers are integrated

into your sandbox

If somebody else has committed a change to a part of the code that you have updated a conflict might arise which must be resolved manually (very

infrequent)

Syntax cvs [cvs-options] command [command-options & args]

cvs options- d CVS-root-dir

an absolute path for the repository in case $CVSROOT isn’t set properly

- e editor sometimes CVS requires comments from usIf no editor is specified, vi will openESC ZZ to quit

The Repository While multiple repositories are possible, it is usually

easiest to have just one

The environment variable $CVSROOT should point to the repository

E.g. if your CVSROOT is /home/cvs/CS230S2011, you can set this with: setenv CVSROOT /home/cvs/CS230S2011Or use, cvs -d /home/cvs … with all your

commands

Setup CVS Initializes the repository

First step before CVS can be used

The same repository can be used for many projects This step is usually done once /home/cvs/CS230

To set up a CVS directory cvs init Or cvs –d /home/cvs/CS230s2011 init

initializes the directory to be the cvs root directory Notice the CVSROOT folder inside the repository

Need not worry about this step

Import a Project to CVS Usually CVS is used over existing projects

A project is said to be imported to CVS

While in project’s root directory cvs –e emacs import ProjectName Vendor-Tag Release-Tag

ProjectName is the name you’d like to give for this project or module to differentiate it from other modules in the repository

-e emacs tells Linux to use emacs for editing instead of the default vi

Now, we’ve created a new directory in the CVSROOT called ProjectName that contains all selected files from the project directory

cvs import –m “This is project X release Y” ProjectName Vendor-Tag Release-Tag

Import a Project to CVS Not every file in the project need to be kept

under source control

.class files can be recreated from .java filesOthers might not be usefulautomatically ignore all file patterns listed in

the .cvsignore file ls –a to see hidden files

E.g. *.zip or *.classCan be placed in CVSROOT directory under CVS Or, placed in all directories of the project that we’re

importing which contain files to be ignored

Import a Project to CVS CVS can also control non source code files

CVS regards the files you put into it as plain-text Need to tell CVS about others so that it doesn’t do

special substitutions on check in and check out• Need to tell CVS that they are binary files-E.g. image files

Update cvswrappers in CVSROOT folder in the repository*.jar –k ‘b’*.gif –k ‘b’*.doc –k ‘b’*.xls –k ‘b’Specifies a keyword substitution mode (treat as binary)

Checkout a Sandbox Now it is time to check out a local copy of the project

files Go to where you’d like to place the sandbox, run

cvs checkout module cvs co module Will create a directory called module and check the CVS module

of the same name out into it Make sure CVSROOT is pointing to the right directory or use cvs with –d option

Now you have a copy of the project in the selected folder Notice the CVS folder inside … for administrative purposes

Checkout a Sandbox

If you want to check out into a different directory name use cvs checkout -d directory module (note that the -d must be between the command and the

module name)

Checkout a Sandbox Go to where you’d like to place the sandbox, run

cvs checkout module Now you can work normally on the sandbox

Modify Add Remove Compile Run Test

Adding a file to a checked out module: cvs add file

file will be added at the next commit cvs add -kb filename # for a binary file

cvs commit Removing a file from a module:

cvs remove file file will be removed at the next commit will not work unless you delete file first from your sandbox

rm file cvs commit

Commit

Makes your changes available in repository Your files are now the latest version (i.e.

creates new version)Can commit a single file

cvs –e emacs commit FileName

More than one filecvs –e emacs commit FileName1 FileName2 FilaName3

All files in a specific directorycvs –e emacs commit Dir

All files in the current directory downcvs –e emacs commit

Commit Will be asked to describe change

Comment on your version

Can see comments on all versions using cvs log

Can also specify message on command line cvs commit FileName –m “bug fix”

If you omit the log message (-m option), an editor will be invoked to allow you to enter a log message

CVS won’t commit if you have non-up-to-date filesOthers have committed changes to files that you’ve

updated

Revisions CVS assigns numbers such as 1.1, 1.2, and so on, and that is all one needs

to know Each version of a file has a unique revision number Revision numbers look like `1.1', `1.2', `1.3.2.2' or even `1.3.2.2.4.5‘

A revision number always has an even number of period-separated decimal integers By default revision 1.1 is the first revision of a file

Each successive revision is given a new number by increasing the rightmost number by one

The following displays a few revisions, with newer revisions to the right +-----+ +-----+ +-----+ +-----+ +-----+

!1.1! ---- !1.2! ---- !1.3! ---- !1.4! ---- !1.5!+-----+ +-----+ +-----+ +-----+ +-----+

Updating Files cvs update

Brings your files up-to-date Compare files in sandbox with their counterparts in repository cvs update fileName

All files examined will be shown with a one letter code preceding them U - update - the file changed in the repository but not in your

sandbox. Your sandbox has been updated M - merge - your sandbox file has changed, but it can be

merged into the repository copy with no errors C - conflict - your sandbox file has changed and CANNOT be

merged into the repository. ? - unknown - this file not under the control of CVS and ignored.

Conflicts What if someone has updated (and committed)

a portion of a file that you checked outAll changes will be in your sandbox (with different

markings to differentiate among them) It is up to you to resolve the conflict and commit new

code remove the dividing lines (i.e. <<<<<<. =====, >>>>>)main() {

<<<<<<< hello.c printf("Hello, World!"); ======= printf("Hello World"); >>>>>>> 1.2 }

Usually updates are done when commit fails

CVS diff Differences between the version that you checked

out and the file as it stands after your updates cvs diff FileName Can name more than one file or a directory Code lines preceded by a < indicate deleted lines while

those preceded by > indicate added lines 31d30

< … line got deleted 66a67

> … new line added 92c92

< from ---- > to

CVS diff

Can also check difference between some previous version and the current versioncvs diff –r 1.15 FileName

Or between two versionscvs diff –r 1.12 –r 1.15 FileName

Or since a certain datecvs –diff –D 06-Sep-10 FileName

cvs status

cvs statusGives info on the current files in sandboxMostly revision info

cvs log Shows the history of a file’s revisions and associated

comments For every commit, the user is prompted for a comment

describing the changes made

cvs log Complete file name from repository Local file name in sandbox Version that is head (most up-to-date) Access limitations List of tags (symbolic names) for the module The revision # # lines added and deleted etc …

cvs log -- help

Typical Sequence

Check out a copyEdit some filescvs diffcvs updatecvs –e emacs commit

Tagging Used to mark particular milestones

cvs tag Rel_2_4 Will put the tag Rel_2_4 on the head version of all source files from

the directory (down) where this command was executed down Can be applied to a single file or a group of files by listing them

explicitly $ , . : ; @ are not allowed in tag names

This way you can tell exactly which version you’d like to checkout Assume you’ve released code to user User found a bug But meanwhile, you updated the code so that the error can’t be

replicated Can check out the exact version that was given to the user cvs checkout –r Rel_2_4 MyProject

Tagging If a copy of backend.java in your sandbox and was checked out

from revision 1.4, then CVS will tag revision 1.4

Note that the tag is applied immediately to revision 1.4 in the repository (without your revisions) No need to commit Tagging is not like modifying a file, or other operations in which one

first modifies the working directory and then runs cvs commit to transfer that modification to the repository

One potentially surprising aspect of the fact that cvs tag operates on the repository is that you are tagging the checked-in revisions, which may differ from locally modified files in your working directory If you want to avoid doing this by mistake, specify the `-c' option to

cvs tag

Tagging If there are any locally modified files, CVS will abort

with an error before it tags any files $ cvs tag -c rel-0-4 cvs tag: backend.java is locally modified cvs [tag aborted]: correct the above errors first!

Tagged files can’t be updated! If you checkout a tagged release then no commits can be made Refer to the static version of code that existed upon the tag's

creation As a result, you cannot commit changes back into the tree at

the tagged place that you checked them out from Must make it a branch

TaggingIf you try to do anything with a tagged copy of the

project, CVS will see the sticky tag and will not let you do anything

You can't commit the file - CVS will complain about the sticky tag

CVS will not update the file with a normal "cvs update" command because it will look at the sticky tag and assume you want the file to be in recorded (tagged) version

Normally one does not modify tags They exist in order to record the history of the repository and so

deleting them or changing their meaning would, generally, not be what you want

Tagging However, there might be cases in which one uses a tag temporarily or

accidentally puts one in the wrong place

Can move the tag to new version (say you updated the bug pointed out by the customer – done on the newest version though and not on the tagged release) (we mean to make the same tag point to different revisions) cvs tag –F Rel_2_4 cvs tag –F Rel_2_4 Account.java

Moves Rel_2_4 tag to the current version of Account.java in case it has been modified

i.e., newest version of the file has the tag now But, what if your file has been modified by you after the release but before the

customer’s bug was updated! If you use above command, you’ll lose all changes made between the release and date the bus

was fixed!!!

Tags can be removed using cvs tag –d Rel_2_4 Gone forever!!!

Branching Tags cvs tag –b Branchname

From the local directory containing the most up-to-date code

Creates a branching tag we can have more than one path in the source repository

Can check out from and commit changes to either of main path or the branches

Allows us to move forward with new development on the head of the source (main path) while providing fixes against a previous version

Branching Tags To checkout a branch

cvs checkout –r Branchname MyProject

When you are finished making changes to your working directory, save it as the next revision on the new branch with (CVS will remember that you are in a branch)cvs –e emacs commit

When to do branching?Right away after a release to another group

QA, customer, etc …

Branching Tags

Steps to set up and use a branching tagcvs tag –b QAcvs co –r QA myprojectcvs status (shows you the important difference

between this version and other versions)Sticky tags

cvs update -r QA (in case you have to update your sandbox), then cvs –e emacs commit

Any changes committed will go against the branch!

Must update main branch (trunk) separately

Branching Tags

BranchesEach branch has a unique branch number

A branch number is created by appending a number to the revision number of the revision the branch is forked from

When, CVS creates a branch number, it picks the first unused even integer, starting with 2

More than one branch may fork from on revision

Branching Tags

CVS Tree

Branches and Tags Trunk

As code gets modified and is committed back to the repository, it adds another revision to extend the tree

Add 1 to the last revision digitIf no branches are specified when checking out working

directories, the tree simply grows in a line along the main trunk of the tree

Tag A tag can be used to name a particular revision of the codeThis tag can later be used to compare different revisions, to go

back to an earlier version, or to specify a place to create a branch

Branch Branches allow different development paths to be tried They can be created from the main trunk, or from other

branches