Concurrent Versioning System Chapter 8 ALBINGs CVS Concurrent

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/CS 230 S 2011, you can set this with: setenv CVSROOT /home/cvs/CS 230 S 2011 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/CS 230 To set up a CVS directory cvs init Or cvs –d /home/cvs/CS 230 s 2011 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 Project. Name Vendor-Tag Release-Tag Project. Name 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 Project. Name that contains all selected files from the project directory cvs import –m “This is project X release Y” Project. Name 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 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 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 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 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 File. Name 1 File. Name 2 Fila. Name 3 All files in a specific directory cvs –e emacs commit File. Name 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 File. Name –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 file. Name 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 File. Name Can name more than one file or a directory Code lines preceded by a < indicate deleted lines while those preceded by > indicate added lines 31 d 30 < … line got deleted > … new line added 66 a 67 92 c 92 < 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 File. Name cvs diff –r 1. 12 –r 1. 15 File. Name Or since a certain date cvs –diff –D 06 -Sep-10 File. Name

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 My. Project

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 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 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 My. Project 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 Branches allow different development paths to be tried They can be created from the main trunk, or from other branches