CVS Concurrent Versioning System CRASH COURSE!

1. CVSConcurrent Versioning SystemCRASH COURSE! presented by Axel Polleres with improvements by Holger Lausen and Eyal Oren cf. http://www.cvshome.org

2. Overview • What is CVS? • Web Access (to the latest version) • How to install CVS client • Windows+Cygwin • WinCVS • Linux • How to commit changes • How to remove files from CVS • How to structure your files • Logging! • Summary

3. What is CVS? • Concurrent versioning system which allows several users to work concurrently on text files. • Especially Useful for program development, HTML/XML files, LaTex or any other text-based files. • You can concurrently work on the source files as long as you do not modify the same sections!

4. Checkout Checkout Coffee.java coffee.java internal comparison with existing version EDITING EDITING coffee.java Update (OK) commit Coffee.java (1.2) Coffee.java Vergleich mit Version im Repository update (nicht OK) CHECK MERGED FILE Coffee.java Commit Coffee.java (1.3) CVS principles by example Holger CVS-Server Axel Coffee.java (1.1)

5. Web Access (read only) • http://cvs.deri.at/wsmo/ • Functionality: • Browsing/Retrieving any version any file • DIFF between any 2 versions

6. Installing CVS • Windows+Cygwin • Cygwin is a Windows port of all useful GNU tools, providing all kinds of nice UNIX commands and software packages under windows (grep, diff, latex, ps2pdf, dvips, dvipdf, etc.) • Web-Installer at: http://www.cygwin.com/ • Make sure to select CVS and ssh packages! • You get a shell link installed on your desktop: • Open shell! • Type: export CVS_RSH=/bin/ssh • Change directory to the dir you want to checkout WSMO to: cd c: cd <PATH_TO_LOCAL_WSMO_CVS> • Checkout WSMO: cvs –d :ext:USER@c703-dericvs.uibk.ac.at:/usr/local/cvsroot/ checkout wsmo

7. Installing CVS • Linux • You need Linux machine with CVS and ssh installed (this is standard) • You need to set the environment variable CVS_RSH to /usr/bin/ssh (or wherever ssh is installed). • Type: export CVS_RSH=/bin/ssh • Change directory to the dir you want to checkout WSMO to: cd c: cd <PATH_TO_LOCAL_WSMO_CVS> • Checkout WSMO: cvs –d :ext:USER@c703-dericvs.uibk.ac.at:/usr/local/cvsroot/ checkout wsmo

8. Installing WinCVS Download WinCVS 1.3.13.2: http://wincvs.org/download.html#wincvs_recommended and install (all defaults of the install wizard are OK) Configure: Admin>Preferences

9. Emacs & CVS (from Eyal) • Good: • Emacs has a good cvs mode, but it is only paying off if you’re using Emacs for editing • Bad • you need a cvs client (from cygwin or wincvs), put the directory where cvs.exe is in your path • I don’t know how to tell emacs the cvs password (it works here, but I don’t know how) • need to make a env. variable CVSROOT with the correct value (username@cvs.deri.at:/usr/local/cvsroot) • in emacs: • M-x cvs-examine • M-x cvs-status • M-x cvs-update • those give you a cvs-buffer, in which you can walk through the files and do update, commit, diff, log, status, etc. • use the emacs help

10. Getting all together: (first time) Remote > Checkout Module Commandline alternative: cvs –d :ext:USER@cvs.deri.at:/usr/local/cvsroot/ checkout wsmo Update some files (optionally to a specific date) Modify > Update Selection Commandline alternative: cvs update –D “2004-03-24 23:45“ Check Out / Update WSMO

11. Changing files and comitting files: • After installing CVS and checking out WSMO, you can freely edit your local copies of files. • Before comitting changes, always update to see whether someone else has comitted changes to the file in between (cf. next slide) • Commit often, avoid monster changes, since this invreases risk of conflicts! • In case of conflicts: Always resolve any conflicts before comitting! • Commit your changes: • Right-click on the file you want to commit • Rule of thumb always only commit single files, rather than whole directories!) • Always enter a meaningful logging message! This helps your co-authors! Example: Commandline alternative: cvs commit <filename>

12. Update files: • Before making changes, or comitting, you should always update! • It is useful to update always on the ehole directory, to see whether new files have been added: Commandline alternative: cvs update -dA This ensures that you retrieve the most current version!* This ensures that you retrieve All new subdirectories recursively! * Has only to be checked if you retrieved an old version before, see next slide

13. Resolving conflicts: • In case of conflicts (someone else conflicts are marked in WinCVS and a new file is stored which contains the file in the state before the update: • Conflicts are in general very unlikely, since CVS automatically merges changes which do affect different parts of the file, all you have to ensure is to always update before comitting! • If conflicts cannot be avoided, CVS marks them in the file and you can resolve them manually: Example: How conflicts are marked in a text editor: (Remark:to find conflicting parts, search for „<<<<<“)

14. Adding, committing and deleting files • Add the new file in the CVS directory where you want to check it in locally, in winCVS it is marked with „?“: • Mark the file (Again: rule of thumb, only add single files!) • Use the add symbol to add the file for committing: • Finally, right klick and commit as usual: (Again:Don‘t forget log message!) • To delete files mark the file and press „remove selected“:

15. Diffs & Logging Some more context menu options: • Adding log messages helps your co-authors to keep track of changes! Use Log to browse through the log history. • With Diff you can check the differences between your files and the repository version • Always Diff before committing and then sum up the diffs in a few sentences in the log message! • Very useful! Display which line was comitted when by which user! • Commandline alternatives: cvs log <filename> cvs diff <filename> cvs annotate <filename>

16. Logging/Annotating-example cvs log: This is useful information!!! Use diff, log and annotate extensively! cvs annotate: 1.4 (ruben 19-Mar-04): the current version of WSMO-Standard does not provide the required modeling elements to describe 1.4 (ruben 19-Mar-04): them yet. Future versions of WSMO-Standard will define the required modeling elements and 1.4 (ruben 19-Mar-04): the details of the choreography and orchestration of the BravoAir Web Service will be added 1.4 (ruben 19-Mar-04): to this document.</p> 1.3 (ruben 17-Mar-04): 1.3 (ruben 17-Mar-04): <P></P> 1.3 (ruben 17-Mar-04): <H2><A id=SubCongoWSMO>3.2 The <EM>Congo</EM> Web Service in WSMO-Standard</A></H2> 1.1 (axel 12-Mar-04): 1.1 (axel 12-Mar-04): <p></p> 1.2 (axel 12-Mar-04): <h1><a id="UseCasesWSMO">4. Use Cases in WSMO</a></h1>

17. How to structure your deliverable • On the CVS server: • Commit only the source files, i.e. only xhtml and graphics! • (no .PDFs, or .dvi, etc!) • Do not duplicate files (like e.g. the WSMO logo, always refer to • the logo and stylesheet via its URL in your source file • (using the deliverable template ensures this!) • Do not create subdirectories for versions! • (there is no need for this, since you can always recover any • previous version!) • Example: Should be WSMO/d16/ not WSMO/d16/v01 Make version subdirectories only on the webserver!!

18. Moving files/directories • CVS has one big weakness: • Moving/renaming files is not easily possible: • Only possibility: • Move file locally • Remove old file from CVS • Add+commit renamed file to CVS. • Moving directories is easier, but has to be done by the administrator. • Problem: everyone has to remove his/her local copy manually.  Conclusion: If you want to change your file structure, contact the CVS-server admin… • only do this, if it is really necessary! • Try to build up a meaningful structure from the start!

19. Tagging • Tagging allows to mark a particular revision of a file to retrieve it more easily: • Select the file(s) to be tagged • „modify“>“create a tag on selection“ or: • Type your tag, e.g. d9v01 • To get an overview you can ask winCVS for a tree view (STRG+G): • You can continue updating new versions, if you need to retrieve this version later on, you can do so by: • Update selection and then in the options tab specify the tag:

20. Branching I(you may skip this slide if you are branching the latest version) • Branching allows you to alter an older version of a source in the CVS (e.g. for proof read deliverables:) • get the version you want to edit from the repository: • (select the file(s); request an update; in the „Update Options“ tab select a date or tag you want to modify) • You can see that you are working on an older version in the file view: • And in the graph view:

21. Branching II • Make sure you have slected the file(s) you want to branch • „Modify“ > „Create a branch“ or press: • Enter the branch name (if you use the name of a tag previously used you have to check „Overwrite existing tags with the same name“ option • That‘s it you have created a branch.

22. Branching III • Now you can modify the file(s) and update them in the selected branch, by simply committing them(just make sure that you are really working on the branch (see Branching I) • Looking at the graph, we see that we have modified revision 1.3: • The symbol in front of 1.3.2.1 indicates that you are still working with the branch, if you want to work with the main tree again make an update and select „reset any sticky date/tag‘-k‘ options

23. Summary • When used correctly, CVS is a great benefit for concurrent development/publishing! • You do not have to take care about versioning on the CVS side, the system does it itself! • Commit often in small pieces! • Avoid committing useless files, only source files! • Anybody can fix typos immediately! (authors will be notified via mail) • Only check in sources! • It is THE place for ALL latest source files, so nobody has to ask around for the “latest” files, but just looks into repository!