I'm considering writing perl scripts or modifying cvs giving support
for keeping backups in the best possible way. However, I don't want to
reinvent the wheel - so I'm wondering if this, or something similar
might exist. I'd also like some feedback; Is there anybody else that
might be interested if I write those scripts? Do you have opinion on
my ideas? Is this just a waste of time, or are those ideas so
brilliant they should even be incorporated in the next version of CVS?
Very shortly, I want to write something like:
cvs rawbackup - | gzip -c9 > /dev/tapedevice
cvs restorebackup - < /dev/tapedevice
cvs chksumtst chksumfile
cvs outdateundo <backup-repository> <revision(s)(range)>
More detailed, my proposal is to create commands (or scripts) doing:
* Chksum export
Creates a control file with all revisionnumbers and checksums.
* Chksum check
Checks if "immutable" data (log-entries and old revisions) are
currupted. Might or might not react at outdated (deleted) revisions.
(the chksumtst command as used above is ment to first check, then export)
* Exporting backup files (as in "rawbackup" above)
Creates a differential file containing data that might be used to
update the ,v-files.
* Importing backup files (as in "restorebackup" above)
Reads files of the format above, and builds an up-to-date repository
My idea is to either stream compressed backup files to a proper
storage media (like a tape), or to have a backup CVS repository (at a
backup server or at another disk) - or both. A backup/mirror cvs
pserver should never allow anything else than importing backup
The concept having a backup repository might also be used to provide
mirroring of CVS-sites. The mirrors would be read-only, though. The
concept could however be extended to a truely distributed, global CVS
environment. In a truely distributed, global CVS environment each cvs
server would have a repository of projects beeing followed locally -
and the development in the repository would be a local branch. At
regular intervals, the branches should be merged with neighbouring CVS
* Undo outdates (deletements) of old revisions
The usefulness of this command is obvious in a distributed environment
- we like to have some of the advantages by having a repository
locally, but we don't want to pay the price regarding disk space, so
we keep outdating anything but the latest versions of the files. But
suddently we'd really like to have revision 1.14 anyway.
TobiX In a world without fences, who needs gates?