i think we should not commit pending fixes, since for that you still have to do a fresh checkout first anyway. So why not do a fresh svn checkout and be done with it..
On Fri, 2006-05-12 at 14:14 +0200, Philippe Valembois - Phil wrote: > I totally agree with you... > As soon as CVS is back (maybe let us commit pending fixes) and hop ! > Migration > to SVN... > Phil > > Le Friday 12 May 2006 08:31, Youness Alaoui a écrit : > > It seems we'll need to be changing everything to move to the new CVS > > infrastructure... > > for that specific reason, I propose we move to SVN right NOW... > > GMTA : Sander had the same idea, so I guess he agrees. > > what do you guys think ? i think we should just do it... cvs will be back > > tomorrow, so answer should get in max tomorrow.. once cvs is back up and > > if no real good reason for not doing it is provided, then I'll start the > > migration process... 24 hours later (max), our svn should be up and > > running, and from their, we'll do our commits... > > > > KKRT > > > > On Thu, 11 May 2006 22:19:12 -0400, Youness Alaoui > > > > <[EMAIL PROTECTED]> wrote: > > > there you go! > > > seems interesting.. we'll need to update our procedures and docs... > > > > > > > > > ------- Forwarded message ------- > > > From: "SourceForge.net Team" <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: SUBJECT: SourceForge.net: CVS service offering changes > > > Date: Thu, 11 May 2006 20:36:30 -0400 > > > > > > Greetings, > > > > > > You are receiving this mail because you are a project admin for > > > a SourceForge.net-hosted project. One of our primary services, > > > CVS, suffered a series of interrelated, critical hardware failures > > > in recent weeks. We understand how frustrating this CVS outage > > > must be to you and your users; however, our top priority remains > > > preservation of the integrity of your data. > > > > > > The series of CVS hardware failures prompted us to expedite the > > > deployment of planed improvements to our CVS infrastructure, > > > drawing upon much of the knowledge that we gained from our > > > Subversion deployment. Our improved CVS service architecture, > > > which we plan to deploy tomorrow afternoon (2006-05-12), will > > > offer greater performance and stability and will eliminate several > > > single points of failure. > > > > > > The Site Status page (https://www.sf.net/docs/A04) will be > > > updated as soon as the new infrastructure is rolled out. In the > > > interim, please read the important information provided below > > > to learn about how these changes will affect your project. > > > > > > > > > Summary of changes, effective 2006-05-12: > > > > > > > > > 1. Hostname for CVS service > > > > > > Old: cvs.sourceforge.net > > > > > > New: PROJECT_UNIX_NAME.cvs.sourceforge.net > > > > > > This change will require new working copies to be checked out of all > > > repositories (so control files in the working copy will point to the > > > right place). We will be updating the instructions we supply, but > > > instructions that your team has written within documentation, etc. will > > > need to be updated. > > > > > > cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/gaim co gaim > > > > > > would be changed to > > > > > > cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/gaim co gaim > > > > > > > > > > > > 2. ViewCVS > > > > > > We are moving from ViewCVS to its successor, ViewVC. ViewVC is > > > currently in use for our Subversion service. > > > > > > > > > > > > 3. Sync delay > > > > > > Old: CVS pserver, tarballs and ViewCVS provided against a separate > > > server which is a minimum of three hours behind developer CVS. > > > > > > New: ViewVC will be provided against developer CVS (it will be current). > > > CVS pserver will be provided against a secondary server (not developer > > > server) with a maximum expected delay of two hours. > > > > > > Follow-up work is planned (this infrastructure takes us 80% of the way) > > > to essentially eliminate the sync delay. > > > > > > > > > > > > 4. Read-only rsync service > > > > > > As a new service offering, we are now providing read-only rsync access > > > against developer CVS. This allows projects to efficiently make > > > on-demand backups of their entire CVS repository. > > > > > > All projects should be making regular backups of their CVS repository > > > contents using this service. > > > > > > > > > > > > 5. Nightly tarball service > > > > > > Nightly tarball service is being dropped in lieu of read-only rsync > > > service. Projects which currently depend on nightly tarballs for > > > repository backups will need to begin using rsync to make a backup copy > > > of their repository contents. > > > > > > We see this as a major functional improvement. For a number of reasons, > > > tarballs have fallen out of sync with the data in the repository at > > > times in the past few years. Tarballs required a substantial amount of > > > additional disk, and I/O to generate. The move to read-only rsync > > > allows backups to be produced on-demand, with an update frequency chosen > > > by the project. > > > > > > > > > > > > 6. Points of failure > > > > > > In the past, developer CVS service for all projects was provided from a > > > single host. CVS pserver service was provided from individual backend > > > heads based on a split of the data. > > > > > > Under our new design, developer CVS and most of our CVS-related services > > > are provided from one of ten CVS hosts (count subject to increase with > > > growth). Each host is independent, and makes a backup copy of the > > > repository data of another host (which is used to provide the pserver > > > CVS service). > > > > > > Failure of a single host will impact only the availability of data on > > > that host. Since the data is split among a larger number of hosts, the > > > size of data impacted by an individual host outage is substantially > > > smaller, and the time required for us to restore service will be > > > substantially shorter. > > > > > > This rapid architecture change has been made possible specifically using > > > the research we performed for our recent launch of Subversion service. > > > We've applied our best practices, produced a substantial amount of > > > internal documentation, and kept an eye toward maintainability. > > > This effort has allowed us to deploy this new architecture quickly > > > once hardware was received, and will permit us to quickly scale > > > this service horizontally as growth and demand requires. > > > > > > > > > > > > Many other minor improvements have also been made to improve the service > > > offering and make it less trouble-prone. The most important of which are > > > listed above. For a full description of the new service offering, and > > > for information on how to use the services described above, please refer > > > to the site documentation for the CVS service after the service has been > > > launched: https://www.sf.net/docs/E04 > > > > > > > > > Thank you, > > > > > > The SourceForge.net Team > > > > > > . > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 > _______________________________________________ > Amsn-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
