To understand the idea of this part, you need to learn something about the way CVS is storing data.

Unlike some other version control systems, CVS stores the data you put under its control in a usual file system. It has a "repository" which basically is a directory on the server. No database is used so don't expect atomicity or transactions... However, this might be a reason why CVS does not have a "project" term. The only grouping term it uses is "module". A module is a logical group of directories or files or other modules. The module descriptions are stored in a special file called "modules" which is located in the CVSROOT folder of each repository. Furthermore, you have three different kinds of modules: regular that represent one directory or several files inside a directory, alias which simply stand for other modules/directories and ampersand which contain of other modules. (If you need additional information on modules and their usage have a look at the CVS book by Per Cederqvist mentioned here before)

The only way to create/edit/browse/delete modules CVS (and WinCVS) provide is editing the modules file manually. Not acceptable in year 2002! (Imagine you have hundreds of modules and a complicated hierarchy...)

That's why the modules browser was born. (I have to admit that the idea and first implementation of such a tool wasn't my own; a guy in our company wrote a Java application which does all this. However, it is a stand-alone application and I wanted an integrated solution.)

So what is the modules browser?

It

• is a graphical Explorer-like browsing interface for CVS modules
• allows the user to edit, create and delete modules
• is integrated into WinCVS
• hides the process of checking out/committing the modules file and more...

The way it works is quite simple: it checks out the modules file from the current CVS repository and parses it into a graphical view; after you made your changes it saves the modules file and commits it.

There is an other interesting feature: you can define module categories in order to group your modules. You could have categories like "Applications", "Libraries" and so on and the modules browser would create nodes for each category and attach the modules to them, like this:

How does it work? Well, once more we have a XML file which contains templates. Each template contains a category name, a pattern which would match the module's name, and an icon file path:

Again, we use regular expressions to describe the pattern of a module's name. In the above example, any module name starting with "Srv_" would match the pattern and the module would be attached to the "Services" category which gets the icon "Modcat_Service.ico". Any module which doesn't belong to a defined category goes into the unknown one.

This functionality is designed to be used in a rather large CVS environment where a standard for module naming is established. It might not be that useful if you work with different repositories using different naming conventions.