• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Recovering CVS Repository

 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    author and iconoclast
    Posts: 24207
    46
    Mac OS X Eclipse IDE Chrome
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Yep, that's pretty much all you can do, as far as I know.
     
    David O'Meara
    Rancher
    Posts: 13459
    Android Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Nice to have it confirmed, thanks.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic