Cervisia Manual

Cervisia Manual

Cervisia Manual

Bernd Gehrmann

Revision 1.50.10

This program may be distributed under the terms of the Q Public License as defined by Trolltech AS of Norway and appearing in the file LICENSE.QPL included in the packaging of this file.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Cervisia provides a graphical view of CVS.


Chapter 1. Getting Started

Getting Started

Chapter 1. Getting Started

Accessing The Repository

In this section we assume that you are using CVS only on the client side. That means, someone (probably the administrator of the CVS repository) gave you an account on the server machine, and it's your job to checkout modules from the repository and work with them.

CVS supports several methods of accessing the repository, which can be categorized as follows:

Local

The repository is something like /home/cvs/ and is simply stored in a directory which is accessible from your computer. It may physically be on a disk which is mounted via NFS, but this is an irrelevant detail. If you often use a certain local repository, you will want to tell Cervisia about it.

Procedure 1.1. Adding A Local Repository

  1. Open the Repositories dialog by choosing Repository->Repositories....

  2. Press the Add... button.

  3. Enter the details of the repository in the dialog box that displays.

  4. Confirm by pressing the OK button.

In the future, whenever you use Cervisia to check out a new module, Cervisia will present you the repositories you have added here.

RSH

The repository name is something like :ext:bernd@cvs.cervisia.sourceforge.net:/cvsroot/cervisia.

This method requires that you have a user account on the server machine (in this case, cvs.sourceforge.net and use a remote shell for communication. By default, CVS uses rsh for this purpose, however, rsh is long considered to be insecure, and is widely replaced by ssh.

If you must use ssh, you must set the environment variable $CVS_RSH to ssh when using the CVS client. Cervisia supports this easily.

Open the repositories dialog again, and press the Add... button. Now enter the name of the repository in the first line and the remote shell (e.g. ssh) in the second line. If you now confirm with the OK button, Cervisia memorizes these settings.

Note that Cervisia can not answer possible password requests from the server machine. You must make sure that a remote login works without requiring you to enter the password. With plain vanilla rsh, this can be achieved for example by creating a $HOME/.rhosts file with a list of trusted hosts (see the rsh manpage).

With ssh, it can be achieved by copying your public key $HOME/.ssh/identity.pub to the server. In this case, the key must not be encrypted with a passphrase (see the ssh manpage and the CVS/SSH FAQ on SourceForge). If you are unsure about these issues, ask your system administrator.

pserver

pserver - The repository name looks like :pserver:gehrmab@cvs.kde.org:/home/kde

This method accesses the server via a special protocol with a relatively weak authentication (pserver stands for password authentication). Before you can use such a server, you have to login. As this isn't directly supported by Cervisia, enter on the command line

%cvs -d :pserver:joe@cvs.kde.org:/home/kde login

(of course, with your repository substituted). CVS will prompt you for your password and check with the server. If the password is ok, the repository name, together with the (slightly scrambled) password, will be appended to the file $HOME/.cvspass. Whenever CVS accesses the repository, it will silently send the password to the server, so you do not have to take care of that once you have logged in. As everybody who knows your password can work with the repository in your name (and even do major damage to it), you should keep the $HOME/.cvspass secret and non-readable for others.

Importing a module into the repository

Importing a module into the repository

Importing a module into the repository

In this section, we discuss how you put a new project into the CVS repository. If you just want to work with an existing project which is already in a repository, you may skip this section.

Figure 1.1. A screenshot of Cervisia's import dialog

>A screenshot of Cervisia's import
	     dialog

In Figure 1.1 you can see the dialog which helps you to import a project as a module. After you have filled out this form and confirmed by OK, the following CVS command is used:

cvs -d 1repository import -m "" 2module 3vendortag 4releasetag
1

The name of the $CVS; repository, also known as $CVSROOT. You must have write access to it, and the repository must be properly initialized. If the repository does not yet exist, initialize it with the command cvs -d repository init.

If the repository is remote, make sure that authentication works (see the section called “Accessing The Repository”

2

The name of the module under which the project will be stored. After the import, the project can be checked out under this name. See the section called “Checkout a module from the repository” for more information. This is also the name of the corresponding directory in the repository.

3

The vendor tag is historically used for tracking third-party sources. Just use your user name if you have no better idea. It does not matter much what you enter here.

4

This tag is also historically used for importing different versions of third-party software. If you are not doing this, use the word start or a string FOO_1_0 where FOO is the name of your project and 1.0 is the version number of the imported release.

Working directory.  This is the toplevel directory of the project you want to import. The import starts from this directory and goes down recursively.

Ignore files.  If you fill out this field, an additional -I filenames option is given go the cvs import command. This entry is interpreted as a whitespace-separated list of file name patterns which are ignored. In general, a cleaner and less error-prone way to control which files go into the repository is to create a directory with only the files which you want to import and start from that. Nevertheless, this entry may be useful if the project contains files which are by default ignored by CVS, e.g. files with the name core. In such a case, simply enter the character ! in this field. This overrules CVS's scheme of ignored files, see the section called “Ignored files”.

Import as binaries.  If you check this box, all files are imported in binary mode, i.e. an argument -kb is given to cvs import.

KDE Logo
Checkout a module from the repository

Checkout a module from the repository

Checkout a module from the repository

Before you work on a project under revision control, you must check out a working copy.

Figure 1.2. A screenshot of Cervisia's checkout dialog

Repository.  The name of the CVS repository, also known as $CVSROOT. If the repository is remote, make sure that authentication works, see the section called “Accessing The Repository”.

Module.  The name of the module to be checked out. If you are working with an existing repository, you have probably got this name from the administrator. Alternatively, if the repository has a $CVSROOT/modules file, you can retrieve a list of available modules by clicking on the Fetch list button.

Working directory.  The directory under which the module should be checked out. Note that the toplevel directory of the working copy is always created as a directory with the name as the module under the directory given here.

KDE Logo
The main screen

The main screen

The main screen

When you start Cervisia, and open a working copy by choosing File->Open Sandbox... you see a hierarchical view of the current directory. According to the settings in your .cvsignore files, the files you usually do not want to include into the repository - like e.g. object files - are not shown. For each file, you see its corresponding status. In the default setting, this is "Unknown" because Cervisia delays the fetching of information until you choose Update or Status from the File menu. With this approach, you have a minimal amount of functionality available even if you do not have a permanent connection to the CVS server.

Figure 1.3. A screenshot of Cervisia's main view

The commands in the File menu usually act only on the files which you have marked. You may also mark directories. Now choose Update from the File menu. Cervisia issues a

cvs update -n
 filenames

command to get status information for the marked files. Note that Cervisia goes recursively into subdirectories. only if you have the according option in the Settings menu set. According to the respective file's status, you now see an entry in the Status column:

  • Locally Modified - This means you have modified the file compared to the version in the repository.

  • Locally Added - This means the file does not exist in the repository, but in your working directory and you have scheduled it for addition. The actual insertion into the repository only happens after a commit.

  • Locally Removed - This means you have scheduled the file for removal, but it still exists in the repository. The actual removal happens only after a commit.

  • Needs Update - This is shown if a newer version of the file exists in the repository, e.g. because someone commited a modification. Normally, you want to update this file so you have an up-to-date version in your directory.

  • Needs Patch - This is essentially the same as before. The difference is only the hint that in case of an update, the cvs server transfers only a patch instead of the whole file to you.

  • Needs Merge - Indicates that a merge of the revision of this file in your working directory with the version in the repository is necessary. This typically happens if you have made modifications to the file file while someone else has commited his modifications. If you choose to update, the modifications in the repository are merged into your file. In case of a conflict (i.e. if someone else has changed some of the same lines like you) the new status is then "Conflict".

  • Up to Date - Indicates that the file is identical with the version in the repository.

  • Conflict - This is shown if this file still has conflict markers in it. Maybe you have previously updated the file and not resolved the conflicts.

  • Not In CVS - Indicates that the file is not registered in the CVS. If you want it to available for others, you should add it to the repository. If not, you may consider adding it to your .cvsignore file.

Now that you have got an overview of the current status of the CVS, you may want to do an update. Mark some files (or the root of the directory tree which is equivalent to marking all files in this directory). Now choose Update from the File menu. (Of course, you could have chosen this at the beginning of the session). For some of the files the status may change now. Typically, files which had "Needs Patch" or "Needs Update" are updated. So the following new items are possible in the status column:

  • Updated - Shown if the file was updated from the repository.

  • Patched - Indicates that the cvs server has sent a patch for this file and the patch has been sucessfully applied. If the patch was not successfull because there was a conflict between your modifications and those someone else commited to the repository, the status is now "Conflict".

You may have noticed that according to the status of the file, its row has a different color. The colors are chosen to somehow reflect the priority of the status. For example, a file with a conflict is marked red to show you that you have to resolve a conflict before you can continue working with the file. If your directory contains a high number of files, you may nevertheless lose the overview. To get more concise information about which files have an unusual status, simply click on the header of the Status column. The file list is then sorted by priority, so you have all important information at the top of the list. To get back to the alphabetically sorted view, click on the header of the File name column.

KDE Logo
KDE Logo
Chapter 2. Working with files

Working with files

Chapter 2. Working with files

All commonly used CVS functionality is directly available in Cervisia's main view. Commands usually act on several files at once, namely all which currently selected. If the selection includes directories, its interpretation depends on the settings made under the Settings menu. For example, if Settings->Commit and remove recursively is checked and you choose File->Commit... while a directory is selected, then all files in the tree under that directory are commited. Otherwise, only the regular files in the directory itself are affected.

You can simply edit a file by doubleclicking on it or pressing Return. This starts the editor configured under Settings->Configure Cervisia... with the file name as argument.

Adding files

Adding files to a project requires two steps: First, the files must be registered with CVS. To this end, mark all files to be added in Cervisia's main view. Then, choose File->Add to repository. Cervisia issues a command

cvs add
 filenames

If the operation was successful, the status column should have "Added to repository" for the added files.

In order to actually put the files into the repository, you must commit them. This procedure has an important advantage: You can commit the files together with modifications to other parts of the project. When doing this, one can easily see (e.g. in commit emails) that all these changes are part of a whole.

CVS is not designed to provide meaningful revision control for binary files. For example, merging binary files normally does not make sense. Furthermore, by default CVS performs keyword expansion string $Revision: 1.4 $) when a file is commited. In binary files, such replacements may corrupt the file and make it completely unusable. In order to switch this behaviour off, you should commit binary files (or other files, like Postscript) with a command line

cvs add -kb filenames

In Cervisia, this is achieved by choosing File->Add binary...

Removing files

Removing files

Removing files

Like adding files, removing files is done in two steps: First, the files have to be registered as removed by choosing File->Remove from repository which issues the command

cvs remove -f filenames

After that, this modification to the sandbox has to be commited, possibly together with other modifications to the project.

Note

The above command only works if the file is up-to-date. Otherwise, you get an error message. This behaviour is sensible: If you have modified the file compared to the version in the repository, or if someone else has made any modifications, you will first want to check if you really want to discard them.

KDE Logo
Adding and removing directories

Adding and removing directories

Adding and removing directories

Directories are handled fundamentally different from ordinary files by CVS. They are not under revision control, i.e. you cannot tell which directories existed in the project at a certain time. Furthermore, directories can never be explicitly removed (expect by removing them directly in the repository).

As a substitute, CVS follows the convention that a directory is "not existent" in a version of the project if is is empty. This convention can be enforced by using the option -P to cvs update and cvs checkout. This option can be set in the menu Settings->Prune Empty Directories On Update.

A directory can be added to the repository with the command

cvs add dirname

which is implied by the menu item File->Add to repository. Note that in contrast to adding files, adding directories does not require a commit afterwards.

KDE Logo
Commiting files

Commiting files

Commiting files

When you have made a certain amount of changes to your working copy, and you want other developers to have access to them, you 'commit' them. With a commit, you place your versions of the modified files as new revisions into the repository. A subsequent update by another developer will bring your modifications into his working copy.

In order to commit a couple of files, select them in Cervisia's main view and choose File->Commit....

Figure 2.1. A screenshot of Cervisia's commit dialog

You get a dialog that shows you on the top a list of the selected files and on the bottom a log message for your changes. When you have finished the dialog, the command

cvs commit -m message filenames

is used. Cervisia helps you in several ways to find a meaningful log message: First, in the file list you can double-click a file or press Return in order to see the changes you have made to the file. Second, it gives you a list of log messages you have previously used in a combo box. Third, this dialog is integrated with Cervisia's changelog editor described below.

Note

A common error you may encounter when commiting is Up-to-date check failed. This indicates that someone has commited changes to the repository since you last updated. Or more technically, that your BASE revision is not the newest on its branch. In such a case, CVS refuses to merge your modifications into the repository. The solution is to update, resolve any conflicts and commit again. Of course, if you are working on a software project, it is normally good style to check if the program still works after you have updated - after all, there could be bad interactions between your modifications and the other modifications which break the code.

Note

Another popular mistake results in the error message Sticky tag 'X' for file 'X' is not a branch. This happens if you try to commit a file which you have previously brought to a certain revision or tag with the command

%cvs update -r X

(which is e.g. used by the menu item Advanced->Update to Tag/Date...). In such a case, the tag on the file gets sticky, i.e. further updates do not bring you to the newest revision on the branch. If you want to commit further revisions to the branch, you have to update to the branch tag before you do further commits.

With Cervisia, it is quite easy to maintain a ChangeLog file that is compliant with the format layed out in the GNU coding guidelines. To use it, choose File->Insert ChangeLog entry.... If a file with the name ChangeLog exists in the toplevel directory of your sandbox, this file will be loaded and you have the possibility to edit it. To this end, at the top of the file, an entry with the current date and your user name (which can be configured as described in the section called “Customizing various commands”) is inserted. When you finish the dialog this dialog by clicking OK, the next commit dialog you open will have the log message set to the message you last entered in the change log.

KDE Logo
Resolving conflicts

Resolving conflicts

Resolving conflicts

Conflicts may occur whenever you have made changes to a file which was also modified by another developer. The conflict is detected by CVS when you update the modified file. CVS then tries to merge the modifications commited by the other developer into your working copy. The merge fails if both your and his modifications are in overlapping parts of the file, and the CVS server issues and error message.

It is your job now to resolve these conflicts before you commit the file. CVS will refuse to commit any files with conflicts until they have been edited. Of course, you have a great amount of freedom when resolving a set of conflicts: you can for each conflict decide to take one of the two alternative versions. You can also decide that both approaches are are broken and rewrite a whole routine or the complete file from scratch.

In Cervisia's main view, files with conflicts are indicated with "Conflict" in the status column and with a red color. From the main view, you can of course resolve conflicts the traditional way: just doubleclick the file in question and edit it with your favourite editor. But you can also choose to use the dialog available via File->Resolve....

Figure 2.2. A screenshot of Cervisia's resolve dialog

On the top of the dialog, you see your version the file on the left hand side and the version in the repository on the right hand side. The differences between them are marked in red color. Below these two versions, you can see the merged version which will be saved as soon as you click the Save button.

You can switch between the differing sections by pressing << and >>. In the lower middle of the dialog you can see which section is currently marked. For example, 2 of 8 means that you are currently at the second differing section of 8 total. Now can can decide section by section which of the both versions you want to have in the merged file. By pressing A, you take over the version you edited. By pressing B, you take over the version from the repository.

KDE Logo
KDE Logo
Chapter 3. Obtaining information about files

Obtaining information about files

Chapter 3. Obtaining information about files

Browsing cvs logs

When you mark a file in the main view and choose Browse log from the View menu, a

cvs log filenames

command is issued and a dialog is shown which reflects the version history of the marked file.

Figure 3.1. A screenshot of Cervisia's browse logs dialog

You can choose to see the history as a tree or in list form. What you prefer is of course a matter of taste and it depends on what information you are interested in. The tree is an intuitive representation of what has been done on different branches by which authors. As tooltips, you can see the according log messages. The list is by its nature linear and therefore does not give an immediate view of branches. On the other hand, it concentrates more otherwise relevant information on less screen estate, namely the time of each change of the file and the first part of the log message.

To obtain more information about a certain revision, you can click on it either in the list or the tree view. The fields in the middle of the dialog are then filled with the complete information provided by cvs log. You can mark two revisions, called 'A' and 'B', which are relevant if you make use of further features provided by the push buttons. Revision 'A' can be chosen with the left mouse button, revision 'B' with the middle one. In the list view, you can also navigate with with your cursor keys. In order to mark revisions 'A' and 'B', use the keybindings Ctrl-A, Ctrl-B, resp.

If you press the button Annotate, you get a dialog showing the text of file belonging to the revision marked as 'A'. Every line is prefixed with the information about who edited this last time, and at which revision this happened.

If you press the button Diff, a cvs diff call is issued and you get a dialog in which all the modifications between the two marked revisions are shown. To make it easy to see the changes, different colors are used to mark lines which have been added, removed or simply changed.

Browsing the history

Browsing the history

Browsing the history

If the used repository has logging enabled, Cervisia can present you a history of certain events like checkouts, commits, rtags, updates and releases. Choose History from the View menu, and Cervisia will issue the command

cvs history -e -a

Note

This fetches the complete logging file from the server, i.e. a list of the events for all users and all modules. This can be a huge amount of data!

Now you can see the list of events, sorted by date. In the second column, the type of the event is shown:

  • Checkout - The user who is displayed in the 'Author' column has checked out a module

  • Tag - A user has used the command cvs rtag. Note that the usage of cvs tag (as done by Cervisia's Advanced->Tag/Branch... command) is not recorded in the history database. This has historical reasons (see the CVS FAQ).

  • Release - A user has released a module. Actually, this command is rarely used and not of much value.

  • Update, Deleted - A user has made an update on a file which was deleted in the repository. As a consequence, the file was deleted in his working copy.

  • Update, Copied - A user has made an update on a file. A new version was copied into working directory.

  • Update, Merged - A user has made an update on a file. The modifications in the repository version on the file were merged into his working copy.

  • Update, Conflict - A user has made an update on a file, and a conflict with his own modifications was detected.

  • Commit, Modified - A user commited a modified file.

  • Commit, Added - A user added a file and commited it.

  • Commit, Removed - A user removed a file and commited it.

Figure 3.2. A screenshot of Cervisia's history dialog

You can sort the list by other criteria simply by clicking on the respective column header. In order to sort out the history entries you are interested in, there are various filter options activated by check boxes:

  • Show commit events - shows commits

  • Show checkout events - shows checkouts

  • Show tag events - shows taggings

  • Show other events - shows events not included in the above

  • Only user - shows only events caused by a certain usere

  • Only filenames matching - filters file names by a regular expression

  • Only dirnames matching - filters directory names by a regular expression

Special characters recognized by the regular expression matcher are:
  • x* matches any number of occurences of the character x.

  • x+ matches one or more of occurences of the character x.

  • x? matches zero or one occurences of the character x.

  • ^ matches the start of the string.

  • $ matches the end of the string.

  • [a-cx-z] matches a set of characters, e.g. here the set consisting of a,b,c,x,y,z.

KDE Logo
Watching differences between revisions

Watching differences between revisions

Watching differences between revisions

There are several places in Cervisia where you can ask for a window showing the differences between revisions of a file:

  • In the main view, you can choose View->Difference to repository.... This is based on the command cvs diff and shows you the differences between the version in your sandbox and the version to which you last updated (also known as BASE). This is in particular useful just before you commit a file, so you can find an appropriate log message.

  • In the dialog that is shown when a you commit a set of files, you can request a difference window by selecting a file name in the selection list, either by double-clicking it or by pressing Return. This is quite similar to using View->Difference to repository... with the respective file in the main view.

  • In the Browse logs dialog, you can mark two revisions of a file and request a dialog showing the differences between them (see the section the section called “Browsing cvs logs”).

As you may have expected, Cervisia does not just dump the output of the diff command into your terminal, but shows you a graphical view as seen in Figure 3.3.

Figure 3.3. A screenshot of Cervisia's diff dialog

The text in the dialog is an improved variant of the text given by the diff command with the -u option. You can see the differing versions in two windows, with lines arranged such that you can do a side-by-side comparison. That means, where text has been added or deleted, the respective window shows empty lines with the marker +++++ at the left hand side. Elsewhere, you can see the running number of each line in the left column.

In the second column in the right window, you can see which kind of change has been made. Possible types are Add, Delete and Change. The respective lines are marked in blue, green and red color. In the middle of the dialog a compressed image of the color markers is shown. In this way, you can get a quick overview of the overall changes to the file. You can also use the position of the colored regions in the compressed image as an orientation when you using the scroll bars.

Normally, the scrollbars at the left and the right window are synchronized, i.e. if you scroll on the left hand side, the right hand side is scrolled by the same amount. You can change this by checking the box Synchronize scroll bars.

For information about how to customize the diff dialog, see the section called “Customizing various commands”.

KDE Logo
Watching an annotated view of a file

Watching an annotated view of a file

Watching an annotated view of a file

Cervisia's annotate view is currently is simple frontend to the respective CVS command. It will be improved beyond these capabilities after the 1.0 release. For a preview, look at the script kdesdk/scripts/cvsblame in the KDE repository.

You can get to the annotate view either by choosing View->Annotate from the main view or from the Browse logs dialog. Then you see in a window the latest version of the selected file. In the columns before the text, you get some information related to the latest change in each line. In the first column the revision number is displayed. In the second column you see the name of the author of that revision. Finally, in the third column you see the date of the latest change in the line.

KDE Logo
KDE Logo
Chapter 4. Advanced usage

Advanced usage

Chapter 4. Advanced usage

Tagging and branching

We discuss here only the technical aspects of tagging and branching. If you are only a user, not the administrator of the repository, you will probably not be confronted with the problem. If however you are your own administrator, you should first read about the non-technical problems that accompany branching, in order to get an impression of how time-consuming and error-prone maintaining different branches of a project can be. The appendix includes some references about this topic.

Simple tagging is something you usually do when a release is made, so that you can at any time easily get back to the project state at that time. Tags are usually given a name consisting of the project name and the version number. For example, Cervisia 1.0 is available under the tag CERVISIA_1_0. Cervisia enforces CVS's strict rules about what constitutes valid tag name. It must begin with a letter and may contain letters, digits, hypens and underscores.

Normally, you will want to tag the whole project (although CVS of course allows you to tag only a subset). To this end, mark the toplevel directory in the view and choose Advanced->Tag/Branch. Now enter the name of the tag, press Return and you are done!

Creating a branch is not significantly more difficult: In the tag dialog, check the box Create branch with this tag. You can also delete an existing tag: Choose Advanced->Delete tag in the main view.

There are several ways to update to a certain state of the project:

  • You can update to a certain tag. Use Advanced->Update to tag/date for this. The same procedure is used for updating to a branch. The command issued by Cervisia is

    cvs update -r tag

  • You can update to a certain date. This may be useful if an error was introduced in the project between two releases, you know approximately between, and have an opinion on when that was. You can go to some date by choosing Advanced->Update to tag/date and checking the box Update to date. In the field below, you can enter a wide variety of date formats. One possible format is yyyy-mm-dd where yyyy is the year, mm is the month (numerically) and dd is the day. Alternatives are some english phrases like yesterday or 2 weeks ago. When you use this option, Cervisia uses the command

    cvs update -D date

  • Both options above make a tag or date 'sticky', i.e. you can not commit further modifications on that files (unless the tag is a branch tag). In order to get back to the trunk, also known as the branch with the name HEAD, use the menu item Advanced->Update to HEAD. This results in a command

    cvs update -A

Figure 4.1. A screenshot of Cervisia's update to tag dialog

Another aspect of branching is the merging of modifications from a branch to the current branch. If you are going to do this, choose Advanced->Merge.... The dialog that appears now gives you two options:

Either you may merge all modifications done on a branch to the current branch. In that case, check the box Merge from branch and fill in the branch you want to merge from. Cervisia will then execute the command

cvs update -j branchtag

The other possibility is that you want to merge only the modifications made between two tags on a branch. This usually happens when you merge from the same branch to the trunk several times. In that case, check the box Merge modifications and enter (in the correct order) the two relevant tags. This will result in a command

cvs update -j branchtag1 -j branchtag2

Using watches

Using watches

Using watches

A watch is the conventional name for CVS's feature to notify users of the repository whenever a file has been changed. The usage of watches requires that the file $CVSROOT/CVSROOT/notify has been set up properly. This is not discussed here; if you need further information on the setup from the administrator's point of view, read one of the books listed in the appendix.

Cervisia's main support of watches are three menu items. In order to add a watch to one or several files, use Advanved->Add watch.... In the dialog you get, you can choose to get notified for any of the types of events that CVS supports. For example, if you only want to get notified when a file is commited, check the boxes Only and Commits. If you want to get notified about any event related to the marked files, check the box All. The command line used when you accept the dialog is

cvs watch add -a commit filenames

or with a similar option, depending on the events you chose to watch.

If you not interested into some files anymore, you can remove your watches on them. To this end, use Advanved->Remove watch.... In the dialog you get here, the same options are offered as in the form you filled out when adding the watch. When you confirm this dialog, Cervisia issues the command

cvs watch remove filenames

possibly with an option -a for the chosen events.

Finally, you can get a list of the people who are watching a couple of files. Choose Advanved->Show watchers. Using this menu item will result in a command

cvs watchers filenames

Cervisia's editor interface helps you with projects that use watches. In such projeccts, files that are watched are checked out readonly. If you would just start an editor with such a readonly file, you cannot save your modifications later. This has of course a reason: Whenever you want to change a file, you should run cvs edit before, so that all people watching the file get a notification that you are working on it.

If you are working with watched files, it is advisable to check the option Settings->Do cvs edit automatically when necessary. Now, whenever you edit a file by double-clicking it, Cervisia will run cvs edit before the editor is actually executed. Then you can edit your file as usual. When you have finished your work, commit your files, and the commited files are readonly again.

KDE Logo
KDE Logo
Chapter 5. Customizing Cervisia

Customizing Cervisia

Chapter 5. Customizing Cervisia

Cervisia can be customized in various ways to your needs and preferences. Some options which you may want to change regularly are directly available in the Option menu. Others are united in a common dialog which is available via Option->Settings....

Customizing various commands

Timeout after which a progress dialog appears.  Practically all CVS commands started in a sandbox which belongs to a remote repository need a connection to the CVS server. This is affected by delays from the network connection or a high load on the server. For this reason, for commands like View->Difference to repository... Cervisia opens a dialog which indicates that the command is still running and which allows you to abort it. Furthermore, this dialog is used to show you error messages from CVS. As this dialog may become annoying after some time, it is shown only after a certain timeout which is 4 seconds by default. Here you can change this value.

User name for the ChangeLog editor.  Whenever you use the menu item File->Insert ChangeLog entry..., a new ChangeLog entry is generated with the current date and your username. Normally, it is considered good style to insert your full name and your email address into each of your ChangeLog entries. Here you can configure this.

Number of context lines in the diff dialog.  For the diff dialog, Cervisia uses the option -U to diff. This lets diff show only a limited number of lines around each difference region. Here you can set the argument to -U.

Additional options for cvs diff.  Here you can add additional arguments to the diff. A popular example is -b which lets diff ignore changes in the amount of whitespace.

Start File->Status automatically.  When you check this option, the File->Status command is started whenever you open a sandbox. As this command may need some time and also needs a connection to the server for remote repositories (making it unusable for offline usage), you can set this option separately for local and remote repositories.

Editor.  Here you can configure which editor is called when a file in the main view is doubleclicked. To execute the editor, the entry made here is concatenated with the file name and given to a shell. So it is acceptable to use programs like gnuclient here. You can also enter the string $EDITOR if your environment variable $EDITOR points to an editor which opens an X11 window itself.

Customizing Cervisia's look'n'feel

Customizing Cervisia's look'n'feel

Customizing Cervisia's look'n'feel

Split main window horizontally.  Cervisia's main window is normally splitted vertically into a window with the file tree and one with the output. Alternatively, you can arrange them horizontally.

Font for protocol window.  This is the font used in the protocol window. This is the window showing the output of the cvs client.

Font for annotate view.  This is the font used in the annotate view.

Font for diff view.  This is the font used in diff dialogs.

KDE Logo
KDE Logo
Chapter 6. Appendix

Appendix

Chapter 6. Appendix

Ignored files

In its main file tree, Cervisia does not display all files which are actually there. This is analogue to cvs itself and helps to avoid clutter caused by uninteresting stuff like object files. Cervisia tries to mimic cvs's behaviour as close as possible, i.e. it gets ignore lists from the following sources:

  • A static list of entries which includes things like *.o and core. For details, see the CVS documentation.

  • The file $HOME/.cvsignore.

  • The environment variable $CVSIGNORE

  • The .cvsignore file in the respective directory

cvs itself additionally looks up entries in $CVSROOT/CVSROOT/cvsignore, but this is a file on the server, and Cervisia should be able to start up offline. If you are working with a group that prefers to use an ignore list on the server, it's probably a good idea to take a look which patterns are listed there and to put them into the .cvsignore file in your home directory.

Further information and support

Further information and support

Further information and support

  • CVS comes with a complete set of documentation in the form of info pages, known as "The Cederqvist". If it is properly installed, you get browse it by typing in info:/cvs into the locationbar of kdehelp, khelpcenter resp. Alternative, you can just choose Help->CVS Info in Cervisia. An online HTML version of the Cederqvist is available on the web.

    As this book is maintained together with CVS, it is normally the most up-to-date reference. Nevertheless I recommend considering other documentation for learning to use CVS, in partical the following.

  • Karl Fogel has written the excellent book Open Source Development with CVS. About half of this book is about the development process of Open Source software. The other half is a technical documentation of CVS. Thankfully, the technical part of the book has been made freely redistributable under the GPL, so that you can download a HTML version of it. A list of errata is available on the webpage mentioned above.

  • CVS issues are discussed on a dedicated mailing list.

  • There is USENET group comp.software.config-mgmt dedicated to configuration management in general. CVS is only marginally a topic in this group, but nevertheless it may be interesting for discussing merits of various revision control systems compared to CVS.

  • Last but not least, there is a (low traffic) Cervisia mailing list.

KDE Logo
Command Reference

Command Reference

Command Reference

File (Alt-F)

File->Open Sandbox...

Opens a sandbox in the main window.

File->Open recent...

Opens one of the sandboxes that were in use recently.

File->Insert ChangeLog entry...

Opens the ChangeLog editor, prepared such that you can add a new entry with the current date.

File->Update (Ctrl-U)

Runs 'cvs update' on selected files and changes the status and revision numbers in the listing accordingly.

File->Status (F5)

Runs 'cvs -n update' on selected files and changes the status and revision numbers in the listing accordingly.

File->Open... (Ctrl-O)

Opens the selected file in your editor.

File->Resolve...

Opens a dialog for the selected file which allows you to resolve merge conflicts in it.

File->Commit...

Allows you to commit the selected files.

File->Commit... (#)

Allows you to commit the selected files.

File->Add... (+)

Allows you to add the selected files to the repository.

File->Add binary...

Allows you to add the selected files to the repository as binaries (cvs add -kb).

File->Remove... (-)

Allows you to remove the selected files from the repository.

File->Exit (Ctrl-Q)

Quits Cervisia.

View (Alt-V)

View->Browse Log... (Ctrl-L)

Shows the revision tree of the selected file.

View->Annotate... (Ctrl-A)

Shows an annotated view of the selected file, i.e. a view where you can for each line see which author modified it last.

View->Difference to repository... (Ctrl-D)

Shows the differences between the selected file in the sandbox and the revision you last updated (BASE).

View->Last Change...

Shows the differences between the revision of the selected file you last updated (BASE) and the revision before.

View->History...

Shows the CVS history as reported by the server.

View->Unfold file tree

Opens all branches in the file tree so that you can see all files and directories.

View->Deselect all

Deselects all files in the file tree. Only in the KDE1 version.

Advanced (Alt-A)

Advanced->Tag/Branch...

Tags or branches the selected files.

Advanced->Delete tag...

Removes a given tag from the selected files.

Advanced->Update to Tag/Date...

Brings the selected files to a given tag or date, making it sticky.

Advanced->Update to HEAD...

Brings the selected files to the respective HEAD revision.

Advanced->Merge...

Merges either a given branch or the modifications between two tags into the selected files.

Advanced->Add watch...

Adds a watch for a set of events on the selected files.

Advanced->Remove watch...

Removes a watch for a set of events from the selected files.

Advanced->Show watchers...

Lists the watchers a the selected files.

Advanced->Create patch...

Creates a patch from the modifications in your sandbox.

Repository (Alt-R)

Repository->Checkout...

Opens a dialog which allows you to checkout a module from a repository.

Repository->Import...

Opens a dialog which allows you to import a package into the repository.

Repository->Repositories...

Configures a list of repositories you often use and how to access them.

Settings (Alt-S)

Settings->Create directories on update

Determines whether updates create directories in the sandbox which weren't there before (Option -d to cvs update).

Settings->Prune empty directories on update

Determines whether updates remove empty directories in the sandbox. (Option -P to cvs update).

Settings->Update recursively

Determines whether updates are recursive (Option -r to cvs update).

Settings->Commit and remove recursively

Determines whether commits and removes are recursive (Option -r to cvs add, cvs remove resp.).

Settings->Do cvs edit automatically when necessary

Determines whether cvs edit is executed automatically whenever you edit a file.

Settings->Configure Cervisia...

Opens a dialog for customizing Cervisia.

Settings->Configure keybindings...

Opens a dialog for configuring keybindings.

Help (Alt-H)

Help->Contents... (F1)

Invokes the KDE Help system starting at the Cervisia help pages. (this document).

Help->What's This? (Shift+F1)

Changes the mouse cursor to a combination arrow and question mark. Clicking on items within Cervisia will open a help window (if one exists for the particular item) explaining the item's function.

Help->Report Bug...

Opens the Bug report dialog where you can report a bug or request a “wishlist” feature.

Help->About Cervisia

This will display version and author information.

Help->About KDE

This displays the KDE version and other basic information.

KDE Logo
KDE Logo
Chapter 7. Credits And Licenses

Credits And Licenses

Chapter 7. Credits And Licenses

This documentation is licensed under the terms of the GNU Free Documentation License.

KDE Logo
KDE Logo