Previous Next
Working without a Shared Source (module-based approach)

When using CVS, it is not necessary to use shared workspaces to share source and object files. The sharing of source files can also be done by just checking out the necessary modules into the Private Working Environment. The main advantage is that it is not necessary to create and maintain (update) Shared Working Environments; instead, cvs update can be used which requires less network bandwidth.

The main disadvantage is that object files can not be shared by CVS itself, therefore no sharing of object files will be possible. Furthermore just source files of checked out modules are visible within the SNiFF+ browsers - no browsing information about non checked out source files is available. Therefore it is necessary to check out all files which are of interest for the development work or necessary for building a target. This may lead to a large number of checked out modules in the Private Working Environments.

Advantages Disadvantages
  • No Shared Working Environment required.
  • No update of shared WE's is necessary
  • Less adminstrative work (no WE administrator required).
  • Less network bandwidth requirements.
  • No sharing of object files.
  • Increased compilation time.
  • Only checked out modules are visible in SNiFF+
  • Decreased Browsing Information.
  • Check-Out Modules must be done from the Command Line.

The typical development cycle when working without a shared source is like this:

Adding and Removing Files
Since both SNiFF+ and CVS keep record of what files belong to a specific project or a specific configuration, the SNiFF+ Project > Add/Remove Files to/from projectname... dialog should NOT be used for removing files. Instead, you should use the corresponding CVS custom menu entry CVS > Remove file(s).

Note that your Project Description File must be writable in order for thise command to work.
Changing Project Attributes
It is important that no CVS update conflicts occur in the SNiFF+ project description files, because the CVS conflict lines would confuse the SNiFF+ project loading mechanism. Therefore, Project Description files should be made writable only for a short time and commited after any modifications. Moreover, CVS update should be executed on the SNiFF+ project description files with great care. Use File > Update instead to make sure no conflicts occur.
Setting tags (freezing configurations)
You should set tags by using the cvs custom menus; this is much faster than the SNiFF+ Configuration Manager.

To freeze a current checked-out configuration, check out or update all files to the configuration you would like to freeze; then, select all files and execute CVS > tag selected file(s) to tag the current checked-out version.

To freeze the overall HEAD, the HEAD of a branch, rename or delete configurations, you should use the CVS Modules > define tag and CVS Modules > delete tag custom menu entries. They work directly on the repository without taking you current checked-out versions into account and are therefore even faster.
Working with Branches
To create a new branch, you can either use the SNiFF+ file-based commands or the CVS module-based commands.

The file-based commands are simple to handle and work as known from RCS; but they are slow, since for every File/Check in, SNiFF+ needs to execute up to 4 cvs commands ( cvs tag for creating a branch tag, cvs commit for committing, cvs tag for setting a change set name and cvs edit for setting a lock).

For module-based branching, you first need to define a branch tag, and then execute the CVS Modules > Commit Module into branch custom menu. The branch sticky tag will be set for all files of the module, but only changed files will be really checked in. All further modifications will be commited to the same branch.
To revert your branch to the main trunk, execute CVS Modules > Update Module Tree and update to the default branch (
cvs update -A ).
Other Actions
For all other actions, see the Command Reference.

Previous Next