( Backing up

Info Catalog ( Creating a repository ( Repository ( Moving a repository
 2.7 Backing up a repository
 There is nothing particularly magical about the files in the
 repository; for the most part it is possible to back them up just like
 any other files.  However, there are a few issues to consider.
    The first is that to be paranoid, one should either not use CVS
 during the backup, or have the backup program lock CVS while doing the
 backup.  To not use CVS, you might forbid logins to machines which can
 access the repository, turn off your CVS server, or similar mechanisms.
 The details would depend on your operating system and how you have CVS
 set up.  To lock CVS, you would create `#cvs.rfl' locks in each
 repository directory.  See  Concurrency, for more on CVS locks.
 Having said all this, if you just back up without any of these
 precautions, the results are unlikely to be particularly dire.
 Restoring from backup, the repository might be in an inconsistent
 state, but this would not be particularly hard to fix manually.
    When you restore a repository from backup, assuming that changes in
 the repository were made after the time of the backup, working
 directories which were not affected by the failure may refer to
 revisions which no longer exist in the repository.  Trying to run CVS
 in such directories will typically produce an error message.  One way
 to get those changes back into the repository is as follows:
    * Get a new working directory.
    * Copy the files from the working directory from before the failure
      over to the new working directory (do not copy the contents of the
      `CVS' directories, of course).
    * Working in the new working directory, use commands such as `cvs
      update' and `cvs diff' to figure out what has changed, and then
      when you are ready, commit the changes into the repository.
Info Catalog ( Creating a repository ( Repository ( Moving a repository
automatically generated byinfo2html