Concurrent Versioning System

1. Concurrent Versioning System Chapter 8 (ALBING’s)

2. 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

3. Introduction • The database of revisions is often called a repository • Users checkouta 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

4. 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 sandboxby 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)

5. 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

6. 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

7. 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 • Toset 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

8. 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 • ProjectNameis 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

9. 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

10. 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 cvswrappersin 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)

11. 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 sureCVSROOTis 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

12. Checkout a Sandbox • If you want to check out into a different directory name use • cvs checkout -d directorymodule • (note that the -d must be between the command and the module name)

13. 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

14. 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 file • cvs –e emacs commit FileName1 FileName2 FilaName3 • All files in a specific directory • cvs –e emacs commit Dir • All files in the current directory down • cvs –e emacs commit

15. 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

16. 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!+-----+ +-----+ +-----+ +-----+ +-----+

17. 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.

18. 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

19. 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

20. CVS diff • Can also check difference between some previous version and the current version • cvs diff –r 1.15 FileName • Or between two versions • cvs diff –r 1.12 –r 1.15 FileName • Or since a certain date • cvs –diff –D 06-Sep-10 FileName

21. cvs status • cvs status • Gives info on the current files in sandbox • Mostly revision info

22. 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

23. Typical Sequence • Check out a copy • Edit some files • cvs diff • cvs update • cvs –e emacs commit

24. 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

26. 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.4in 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

27. 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

28. 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

29. 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!!!

30. 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

31. 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 …

32. 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

33. 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

34. Branching Tags

35. CVS Tree

36. 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