Actually what Todd is suggesting is fraught with perils. Making disk backups of a live CVS repository using Disk based backup tools (cpio/dd/tar etc) OR using tools like rsync etc has the issue of copying a CVS repository whose files could be changing/renamed. You can end up with an in-coherent backup. The other issue is while making the delta or full copy you could have your server connection go down or server crash.
If you look at the CVS Faq that Todd is pointing to :
"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. "
Now I wouldn't want to lock down my CVS repository especially if it is being used by many developers. In addition creating these locks in multiple directories "atomically" is also an interesting issue in itself. Yes you can choose to take a cavalier attitude but then you have your self to blame if you ever have to restore from a backup whose integrity is questionable. That begs the question why create a backup if it runs the risk of being inconsistent.
As an experienced CVS administrator I have seen too many fun issues when you take the short cuts. Remember the Parkinson rule - If some thing can go wrong, it will.
After a lot of researching the one tool we have found that cuts it is Wandisco. It deals with failure scenarios and provides "atomic" commits and backups. While its not free but then if data integrity is important, you need to analyze your requirements and choose carefully the right tool.
Todd Denniston wrote:
> ferozahmed wrote:
> > Hi All
> >
> > My requirement is to store the monthly backup in the repository
>
> a monthly backup of what?
> source code, your home directory tree, the repository itself, what?
>
> > and when i have to store future months backups i have to store
> > the delta values in the repository ( which the cvs tool does by itself)
>
> So why mention that you need to store delta values, we all know CVS does that
> for us with out having to think about it, talking about it only adds to the
> confusion of what you are asking.
>
> > and while taking the backups i need only to backup the delta value,
> > how to do this
> > please mention the commands to do this
> >
> > Thanks & Regards
> >
> I am going to take a wild leap here and think that what you are trying to ask
> in something other than your native language[1] is:
> Q. How do I make a backup of the repository to some other media?
> A.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_2.html#SEC24>
> If you additionally want to know how to make incremental backups of the
> repository, that is a question you need to ask your backup software maker. For
> an example with gnu tar the info page shows:
> "`--listed-incremental=SNAPSHOT-FILE'
> `-g SNAPSHOT-FILE'
> During a `--create' operation, specifies that the archive that
> `tar' creates is a new GNU-format incremental backup, using
> SNAPSHOT-FILE to determine which files to backup. With other
> operations, informs `tar' that the archive is in incremental
> format."
>
> [1] Actually does anyone including the English actually use the language
> correctly? I know I don't.