To manage my sources for the robot software I installed a CVS server. CVS is a version control system to record the history of source files. The CVS server stores all files in a centralized "repository". To edit a file, it must be "checked out" to copy it to your local system. Then you can modify and test it in anyway you want. When you're satisfied with the changes, you "commit" it (copy it back) to the repository. If somebody else also changed the same file, the CVS server will try to merge the changes. If that fails, it will report so and give you a chance to merge the two versions by hand. The CVS server remembers all committed versions of a file and it is easy to go back to any previous version if you want to start over again. Files in the repository are bundled in sets called modules. (Don't confuse this with the modules from Pieters paper!) When a module is ready for general use (i.e. the set is stable), you can "tag" them to give the current versions of the files in the module a symbolic name.
An important feature of CVS is the abiltiy to work on a module with a team. The CVS server prevents team members overwriting each others versions. Team members can independently edit their local copies of a module. When a team member commits a file to the CVS server, it tries to merge the local changes with the current file in the repository. This current file may be different from the checked-out version, because other team members commited changes already. If the CVS server can't merge the local and repository versions, it will report an error and not commit the file. So changes will never get lost. Consult the CVS info files (info cvs) for more information about CVS and its usage.
The repository for the RoboSoccer project is control-lab.et.tudelft.nl:/user0/home/will_cvs. The basic module, which includes all sub-modules is "apps". The "apps" module itself consists of just a Makefile. Use this file to (re)build the object files and executables in all sub-modules after retreiving the latest version from the repository.
Every sub-module should have its own Makefile. The Makefile file should have an entry for "wrapper" to build object files and libraries, an entry "module" for executables, an entry for "install" for commands to execute as the root user, and an entry "clean" to remove all generated files (object files, executables, bitmap files etc.) Makefiles for sub-modules should use relative paths to other modules, i.e. "../msg/Msg.o" in stead of "/home/will_g/apps/msg/Msg.o".
A module and a directory are two different things. A module is a list of files in the repository. Although checking out a module will copy all files into one directory-tree, not all files in a directory-tree are in a module. Files must explicitly be added to a module. Do not add binary files, like object files or executables, to a module. These files should be generated by the Makefile. When you add a subdirectory to a module, it will become a module in its own.