1 / 36

Concurrent Versioning System

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 ?

linus
Download Presentation

Concurrent Versioning System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

  33. Branching Tags

  34. CVS Tree

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

More Related