Transcript Concurrent Versioning System - College of Saint Benedict

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 them
Allows a group of people to work on the code simultaneously


Guarantees 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


Changes made on the local copy can later be committed to the
repository


All work is then made on the local copy (sandbox)
 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


A user can update her sandbox by adding changes that have
been committed to the repository since the sandbox was last
created or updated


"files are out of date: you must run cvs update first"
(or something to that effect)
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 us
If no editor is specified, vi will open

ESC 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/CS230S2011
 Or use, cvs -d /home/cvs … with all your commands
Setup CVS

Initializes the repository


The same repository can be used for many projects



First step before CVS can be used
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 ReleaseTag




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 files
Others might not be useful
automatically ignore all file patterns listed in the
.cvsignore file




ls –a to see hidden files
E.g. *.zip or *.class
Can 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


Now you can work normally on the sandbox







cvs checkout module
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


More than one file


cvs –e emacs commit FileName1 FileName2 FilaName3
All files in a specific directory


cvs –e emacs commit FileName
cvs –e emacs commit Dir
All files in the current directory down

cvs –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 files

Others 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 out


All 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

> … new line added
66a67
92c92



< from
---> to
CVS diff

Can also check difference between some
previous version and the current version


Or between two versions


cvs diff –r 1.15 FileName
cvs diff –r 1.12 –r 1.15 FileName
Or since a certain date
 cvs –diff –D 06-Sep-10 FileName
cvs status



cvs status
Gives info on the current files in sandbox
Mostly revision info
cvs log

Shows the history of a file’s revisions and associated comments


cvs log









For every commit, the user is prompted for a comment describing the
changes made
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 copy
Edit some files
cvs diff
cvs update
cvs –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
Tagging
If 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


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 checkout –r Branchname MyProject
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 tag



cvs tag –b QA
cvs co –r QA myproject
cvs 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

Branches




Each 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 digit
If 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 code
This 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