April 30, 2006 - A Plot for CVS -> SVN Migrations?

Anyone who's active on a SourceForge project is probably well aware of the lengthy CVS outage that started over a month ago...
(2006-03-31 07:00:01 - Project CVS Service ) On 2006-03-30 the developer CVS server had a hardware issue that required us to take the service offline. We are actively working on this problem and hope to have it back up soon. There is not a current estimate for the duration of this outage, but when we get one, it will be posted on the site status page (this page). We currently expect this outage to last 48 hours, at minimum.

It is good that they added that minimum at the end there because it was more like 96 hours before developers were able to begin using the system again. But what about all of the non-committers on the project?

(2006-04-04 15:09:16 - Project CVS Service ) On 2006-04-04 at 14:15 Pacific developer CVS services were re-enabled after replacement of the failed hardware, successful completion of a full host backup, and a cursory data validity check on the host. As a precaution, we have not re-enabled the sync between anonymous pserver/ViewCVS and the developer CVS host. We anticipate that the sync's along with tarball generation will be re-enabled on Friday. Any issues found with CVS services over the following 7 days should be reported to the Confidential Support Queue.

Re-enabled on Friday? That doesn't sound so bad... and it wouldn't have been if it had been true. Instead:

(2006-04-14 11:18:04 - Project CVS Service ) As of 2006-04-14 we have an estimate on when the replacement CVS hardware for the new infrastructure will arrive. As soon as we get in into our hands, we'll actively work on it, with a goal of having it online by the end of the month of April. This is a best guess, and may not get hit due to the aggressive timeline we have placed on this project. However, be assured that recovery of this service in full is our highest priority. The sync process between developer and anonymous CVS (ViewCVS, etc.) is disabled now until the new infrastructure is in place, to ensure we have maximum coverage for the small number of data corruption issues that have been detected. We understand this is sub-optimal, but strongly believe that the protection of the data is paramount.

Now anyone who understands planning understand that "aggressive schedule" and "best guess" are mutually exclusive concepts, so it is of little surprise that here at the end of the month that CVS access isn't back to normal. It should also be of little surprise that for projects with an active non-committer community this isn't situation isn't acceptable, and thus CruiseControl has now joined the ranks of projects using Subversion instead of CVS.

I'm sure the SourceForge people have been doing their best in this situation, but doesn't it make you wonder if they had FEMA assistance in their emergency planning, or if pehaps this was all just an elaborate plot to "encourage" this sort of migration?


Posted by Jeffrey Fredrick at April 30, 2006 04:57 PM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/212


Comments

Don't forget that you will want to examine how SVN meets your goals if you are a distributed project. SVN works great on a fast link, but for my time I would look at SVK in addition to SVN.

Posted by: Karl Pauls [TypeKey Profile Page] on June 27, 2006 11:36 AM