When you’re ready to compile and test a program, to send a book to an editor, or to post a web site to the server, you will want a copy of the project that doesn’t have the CVS administrative files. You could use cvs checkout and remove the CVS subdirectories, but that’s tedious and unnecessary. Use cvs export instead. It works exactly the same as checkout, but doesn’t create the administrative files necessary for a sandbox.
If you need to compile a program, distribute the project’s files, or otherwise modify the results of the export, I recommend using a build tool such as make on the exported project. Unfortunately, the use of make is beyond the scope of this book, but
Figure 2-11. Removing a file with gCVS
I recommend the article “Introduction to Make” at http://www.linuxdevcenter.com/ pub/a/linux/2002/01/31/make_intro.html.
Quick Tips for Success
CVS is a tool for improving project development and system maintenance. Like all tools, there are ways to use it most efficiently:
Synchronize the clocks of computers sharing a repository to the same universal time. CVS relies on file timestamps to determine which files have changed. NTP (Network Time Protocol) is a very useful tool for time synchronization.
Give each developer his own sandbox, and communicate all file changes through CVS. This method maintains change tracking and prevents developers from irretrievably overwriting each other’s work.
Update frequently, at least before starting work every day, to keep your sandbox current.
Commit frequently to keep your repository current. Programmers typically commit every time their code compiles cleanly; other people may commit after completing each block of work.
Programming teams: use build-management tools and ensure that all files in the build are committed to the repository. Ensure that builds for testing or release come from the repository rather than a sandbox, but allow sandbox builds for programmers to do prealpha tests.
Site Administration 
