4. Developer Sandbox
The developer "sandbox" is where each developer keeps his or her working copy of the code base. In CVS this is referred to as the working directory. This is where they build, test and debug the modules that they are working on. A sandbox can also be the area where the staging build or the production build is done. Changes made in the work area are checked into the CVS repository. In addition, changes made in the repository by others have to be updated in the sandbox on a regular basis.
The best practices related to developers sandbox are:
4.1. Keep System clocks in Sync
CVS tracks change to source files by using the timestamp on the file. If each client system date and time is not in sync, there is a definite possibility of CVS getting confused. Thus system clocks must be kept in sync by use of a central time server or similar mechanism.
CVS is designed from ground up to handle multiple timezones. As long as the host operating system has been setup and configured correctly, CVS will be able to track changes correctly.
4.2. Do not share the sandbox
Sandboxes have to be unique for each developer or purpose. They should not be used for multiple things at the same time. A sandbox can be a working area for a developer or the build area for the final release. If such sandboxes are shared, then the owner of the sandbox will not be aware of the changes made to the files resulting in confusion.
In CVS, the sandbox is created automatically when a working copy is checked out for a CVS project using the cvs checkout {project-name} command.
In very large projects, it does not make sense for the developers to check-out the entire source into the local sandbox. In such cases, they can take the binaries generated by the build team on a regular basis for all those components of the application that is not changed by them and only check-out the parts that are built by the developer.
For example, in a Java project, the build team can keep the results of their last successful build in a standard location in the form of JAR files on the network file servers. Individual developers will use a standard classpath setup that has the network drives mounted on standard paths. Thus, the developers will automatically get the latest version of the files as required by them.
4.3. Stay in sync with the repository
To gain the benefits of working within a sandbox as mentioned above, the developer must keep his or her sandbox in sync with the main repository. A regular cvs update with the appropriate tag or branch name will ensure that the sandboxes are kept up to date.
4.4. Do not work outside the sandbox
The sandbox can be thought of as a controlled area within which CVS can track for changes made to the various source files. Files belonging to other developers will be automatically updated by CVS. Thus the developer who lives within the sandbox will stand to gain a lot of benefits of concurrent development. This benefit cannot be achieved for work done outside a sandbox.
4.5. Cleanup after Completion
Make sure that the sandbox is cleaned up after completion of work on the files. Cleanup can be done in CVS by using the cvs release command. This ensures that no old version of the files exists in the development sandbox. As explained previously, pre-built binaries from the build team can be used to ensure that all the parts of the application are available to the developer without the need for a complete compilation in the sandbox.
4.6. Check-in Often
To help other developers keep their code in sync with your code, you must check-in your code often into the CVS repository. The best practice would be to check-in soon as a piece of code is completed, reviewed and tested, check-in the changes with cvs commit to ensure that your changes are committed to the CVS repository.
CVS promotes concurrent development. Concurrent development is possible only if all the other developers are aware of the ongoing changes on a regular basis. This awareness can be termed as "situation awareness"
 | One of the "bad" practices that commonly occur is the sharing of files between developers by email. This works against most of the best practices mentioned above. To share updates between two developers, CVS must be used as the communication medium. This will ensure that CVS is "aware" of the changes and can track them. Thus, audit trail can be established if necessary. |