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 Several developers simultaneously attempting to run CVS, 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.
