CVS saves its version-control information in RCS files stored in a directory hierarchy, called the Repository, which is separate from the user's working directory.Files in the Repository are stored in a format dictated by the RCS commands CVS uses to do much of its real work. RCS files are standard byte-stream files with an internal format described by keywords stored in the files themselves.To begin work, you execute a "checkout" command, handing it a module name or directory path (relative to the $CVSROOT variable)you want to work on. CVS copies the latest revision of each file in the specified module or directory out of the Repository and into a directory tree created in your current directory. You may specify a particular branch to work on by symbolic name if you don't want to work on the default (main or trunk) branch.You may then modify files in the new directory tree, build them into output files and test the results.When you want to make your changes available to other developers, you "commit" them back into the Repository.Other developers can check out the same files at the same time.To merge the committed work of others into your working files you use the "update" command. When your merged files build and test correctly, you may commit the merged result. This method is referred to as "copy-modify-merge", which does not require locks on the source files.At any time, usually at some milestone, you can "tag" the committed files, producing a symbolic name that can be handed to a future "checkout" command. A special form of "tag" produces a branch in development, as usually happens at "release" time. When you no longer plan to modify or refer to your local copy of the files, they can be removed.