File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes General Computing and the fly likes Recovering CVS Repository Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » General Computing
Bookmark "Recovering CVS Repository" Watch "Recovering CVS Repository" New topic

Recovering CVS Repository

David O'Meara

Joined: Mar 06, 2001
Posts: 13459

This is a hypothetical question, but I was wondering if anyone had encountered it or had existing procedures in place they would like to share.

We have a CVS repository for our source code. Surprising. Anyhoo, we have a nightly backup for it, but the problem is that we tend to 'batch commit' rather than having multiple small commits. This is caused by the nature of the project, a reasonably large team so we have to make sure a fix is complete before pushing it to CVS.

The problem is that if the repository fails and gets recovered from the backup, the various clients can create the situation where you are guaranteed to lose changes if you update from CVS.

We use Eclipse and TortoiseCVS, but depending on the client, commiting a change and replacing the repository with a previous version can cause the change to be rolled back on the client - the change no longer exists anywhere! The same is true for added files. If you add a file to CVS (so that the client knows it is in CVS), recover the repository from a version without that file and then update in the client, some clients will soilently delete the local file...

I'm considering the following process, but it needs fleshing out. It is designed so that deleted files may turn up again, but new files and file changes will not be lost.

  • Call a code freeze. Each machine must be updated manually, one at a time
  • Recover the repository, chgrp the recovered files so that noone can access them. For each person:
  • - add them to the new group.
  • - get their local repository and make a copy
  • - delete all CVS folders from the copied version
  • - check out a new version of the repository
  • - copy the CVS cleaned copy of the local repository over the top of the fresh checkout
  • - manually inspect and commit changes
  • Change the remote repository back to the old group.
  • run regression tests (we all have these, right?)
  • remove code-freeze

  • Our CVS repository has many many thousands of files so it is not possible to manage them individually. The clean-checkout-overwrite is designed to reduce the change set to managable levels and counts on the local repositories being more trustworthy than the remove one until it is cleaned.
    Ernest Friedman-Hill
    author and iconoclast

    Joined: Jul 08, 2003
    Posts: 24199

    Yep, that's pretty much all you can do, as far as I know.

    [Jess in Action][AskingGoodQuestions]
    David O'Meara

    Joined: Mar 06, 2001
    Posts: 13459

    Nice to have it confirmed, thanks.
    I agree. Here's the link:
    subject: Recovering CVS Repository
    jQuery in Action, 3rd edition