1 CVS Concurrent Versioning System CRASH COURSE! presented by Axel Polleres with improvements by Holger Lausen and Eyal Oren cf. ://.

1

CVSConcurrent Versioning System

CRASH 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

Coffee.java(1.1)

Checkout

Coffee.javacoffee.java

Checkout

EDITING

EDITING

coffee.java

Update (OK)

internal comparisonwith existing version

Coffee.javaCoffee.java

(1.2)

commit

CHECK MERGED FILE

Coffee.java

Coffee.java(1.3)

Commit

update (nicht OK)

Vergleich mit Version im

Repository

Holger AxelCVS-Server

CVS principles by example

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:[email protected]:/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:[email protected]:/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 ([email protected]:/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

Check Out / Update WSMO

Getting all together:(first time)Remote > Checkout Module

Commandline alternative: cvs –d

:ext:[email protected]:/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“

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!*

* Has only to be checked if you retrieved an old version before, see next slide

This ensures that you retrieveAll new subdirectories recursively!

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

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

Some more context menu options:

16

Logging/Annotating-example

1.4 (ruben 19-Mar-04): the current version of WSMO-Standard does not provide the required modeling elements to describe1.4 (ruben 19-Mar-04): them yet. Future versions of WSMO-Standard will define the required modeling elements and1.4 (ruben 19-Mar-04): the details of the choreography and orchestration of the BravoAir Web Service will be added1.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>

cvs log:

cvs annotate:

This is usefulinformation!!!

Use diff, log and annotate extensively!

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:

1) Move file locally2) Remove old file from CVS3) 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 theCVS-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!