Working with CVS

From Dokeos

The CVS is the code repository and version management system for Dokeos development. All of the core developers have read and write access to the CVS, the general public has read access. Our CVS is currently hosted at SourceForge. This means the whole world can read our code, and that's exactly what we want.

For the technical aspects of using the CVS, please read the FAQ page.

Which approach for using the CVS

The developers are encouraged to use the CVS as their working place, using it as a central development place for all their work. The stable branches (such as the current 1.6 branch) should only receive code that is bug-free (meaning it has a high probability of being bug-free). The unstable development branches can also hold code that is not stable or bug-free yet. There is only one requirement: all code in the CVS has to respect the coding conventions.

Using a CVS helps cooperation between developers, but a CVS is not the perfect guarantee. In order to keep the cooperation possible, code should be checked in at least every day, and more often when you are making many updates. If you hold back code, nobody else can use it, no one can read it and offer suggestions or make improvements. Even worse, the longer you hold code back the bigger the chance is that someone else has modified the files in the mean time, causing conflicts which can take some time to resolve.

A practical tip: you can use your CVS repository as a web folder, so you can have an installed Dokeos version that is the CVS. You modify files, test the result, and commit immediately afterwards. However, you have to be extremely careful not to submit any of your configuration files as this can mess the whole Dokeos project up.

Dealing with conflicts

When using the same repository with multiple developers, conflicts will happen. Once we accept this we can learn how to deal with it. CVS tries to merge files together, but when it fails to do this automatically you'll have to manually solve the conflicts.

• When you expect you are going to make several large updates to a file or folder, use the developer mailing list to inform the others. E.g. like what happened during the Dokeos 1.55 --> 1.6 database refactoring: the developer in question emails the team and asks them to leave the database part alone for a day. Such requests will almost always be honoured.
• Combine this with a nearly constant committing: as soon as you've updated a file, commit it. The sooner you commit, the less conflicts you will have to resolve.
• CVS has a strictly enforced policy of never losing data. If a conflict occurs, a copy of your original file is saved with a different name. In the code file itself, on every place of conflict, both your code and that of the person who committed before you is stated. You choose what piece of code fits best and delete the other piece of code. This is usually enough. Or you can rework the code a little so it combines better.

Using a local CVS

You can also set up a CVS for yourself, using it locally on your computer. This may help you organise your code and keep it updated and as bug free as possible. If you make a mistake it's also much easier to see where you went wrong. It also improves your CVS skills so you'll be better at it when you use a public Dokeos CVS.