1 / 33

12 CVS

12 CVS. Mauro Jaskelioff (originally by Gail Hopkins). Introduction. CVS Working with an existing CVS module Creating your own CVS module. Diff. Computer Science has developed algorithms that can automatically detect the changes to a file - especially text files

Download Presentation

12 CVS

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. 12 CVS Mauro Jaskelioff (originally by Gail Hopkins)

  2. Introduction • CVS • Working with an existing CVS module • Creating your own CVS module

  3. Diff • Computer Science has developed algorithms that can automatically detect the changes to a file - especially text files • One such algorithm is encapsulated in a UNIX tool call diff

  4. Diff Example world1.cc int main( ) { printf(“hello world”); } world2.cc int main( ) { printf(“Hello World!”); }

  5. Diff Example (2) $ diff world1.cc world2.cc 2c2 < printf(“hello world”); --- > printf(“Hello World!”);

  6. More on Diff • Command line - diff file1 file2 • “show me how to change file1 into file2” • Output • Displays the ed commands needed to change file1 into file2 • 2c2 • Change line 2 in file1 into line2 of file2

  7. CVS: Concurrent Versions System • Many version control systems exist, CVS is one of them • Not the best but open source and installed in unnc-cslinux. Also available in most Linux distributions and widely used. • CVS is a backward delta system

  8. Copy-Modify-Merge • From last lecture: • A developer copies the version of the system in which they are interested into their own filespace • They then make any changes they want • This is then merged back into the central version • CVS uses “version tracking” to manage multiple users

  9. Working with an Existing set of Source Code • You need to set the environment variable $CVSROOT for the location of the CVS repository • You then type cvs checkoutmodule. This will create a directory with the module name in your filespace. This directory will contain the current state of all the source code

  10. Working with an Existing set of Source Code (2) • You can type cvs checkout -r tag module to get the version of the system with the specified tag • You can then change files at will.

  11. Committing Changes • cvs diff -c will show you what changes you have made • cvs commit filenames will place all your changes in the repository. If you miss out filenames then it will commit everything in your current directory and all its subdirectories • You will be prompted to enter a description of your change

  12. Merging Changes • If another user has made changes since you checked out the files then cvs commit will fail with an Up-to-date check error • Use cvs update -d to get hold of the other developer’s changes

  13. Conflict Resolution • From last lecture: • With a version tracking system there has to be a mechanism for deciding what to do if two developers have changed the same file • CVS uses diff to manage as much of this automatically as possible • If changes overlap badly though, you will get a merge conflict which has to be resolved by hand

  14. Resolving Conflicts • In the partially merged version you will find: You can then edit these together <<<<<< filename your changes here ====== committed changes here >>>>>> version number of file

  15. Example: Using CVS [person1]$ export CVSROOT=/home/ [person1]$ cvs checkout cvstest cvs checkout: Updating cvstest U cvstest/world1.cc [person1]$ ls cvstest [person1]$ cd cvstest [cvstest]$ ls CVS world1.cc [cvstest]$

  16. Person 1 Edits world1.cc int main( ) { printf(“hello world”); } int main( ) { printf(“Hello World!”); }

  17. Person 1 commits Changes $ cvs commit cvs commit: Examining . Checking in world1.cc; /home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc new revision: 1.2; previous revision: 1.1 done

  18. Person 2 gets a Copy $ ls $ cvs checkout cvstest cvs checkout: Updating cvstest U cvstest/world1.cc

  19. Example: Person 1 makes a change /* This is a comment added by Person 1 */ int main( ) { printf(“Hello World!”); }

  20. Example: Person 2 makes a change int main( ) { printf(“Hello World!”); } /* This is a comment added by Person 2 */

  21. Person 1 Commits their Change $ cvs commit cvs commit: Examining . Checking in world1.cc; /home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc new revision: 1.3; previous revision: 1.2 done

  22. …then Person 2 tries to Commit their Change $ cvs commit cvs commit: Examining . cvs commit: Up-to-date check failed for ‘world1.cc’ cvs [commit aborted]: correct above errors

  23. Person 2 Updates their Version $ cvs update -d cvs update: Updating . RCS file: /home/mjj/cvs/cvstest/world1.cc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into M world1.cc

  24. Person 2’s Version of world1.cc [cvstest]$ less world1.cc /* This is a comment added by Person 1 */ int main( ) { printf(“Hello World!”); } /* This is a comment added by Person 2 */

  25. Person 2 attempts to Commit [cvstest]$ cvs commit cvs commit: Examining . Checking in world1.cc; /home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc new revision: 1.4; previous revision: 1.3 done

  26. Person 1 makes more changes • Person1 checks out the last version and modifies the file • And then succesfully commits the changes. /* This is a comment added by Person 1 */ int main( ) { printf(“Hello World - Hello!”); } /* This is a comment added by Person 2 */

  27. Person 2 makes more changes /* This is a comment added by Person 1 */ int main( ) { printf(“Hello World!”); } /* This is a comment added by Person 2 */

  28. This time when Person 2 Updates… $ cvs update -d cvs update: Updating . RCS file: /home/mjj/cvs/cvstest/world1.cc,v retrieving revision 1.4 retrieving revision 1.5 Merging differences between 1.4 and 1.5 into rcsmerge: warning: conflicts during merge cvs update: conflicts found in world1.cc C world1.cc

  29. World1.cc with Conflicts in it /* This is a comment added by Person 1 */ int main( ) { <<<<<<< world1.cc printf(“Hello World!”); ======= printf(“Hello World - Hello!”); >>>>>>> 1.5 } /* This is a comment added by Person 2 */

  30. More CVS Commands • cvs init initialises $CVSROOT to act as a repository • cvs import directory vendor release creates a new repository in $CVSROOT called directory. It puts everything in your current directory into the repository • cvs export checks a versions out of CVS without all the additional directories. This can be used for a release of the code

  31. More CVS Commands (2) • cvs add filename schedules a new file to go into the repository • cvs delete filename schedules a file to be removed from the repository (N.B. You must already have deleted it from your filespace) • man cvs will show you a lot more commands - for viewing the log files, changing the version number tags and creating branches

  32. CVS won’t Solve Everything!! • Projects need a policy for what happens if someone commits “broken” code to the repository. Most often people have forgotten to add files • If lots of people are working on the same file at once it can cause headaches when merging. Projects should try and organise themselves so that most of the time people work on different files

  33. CVS won’t Solve Everything!(2) • What constitutes an acceptable log message? • Who is allowed to edit a file? • Updating and Committing has to happen regularly for CVS to work properly • Renaming files is problematic

More Related