From: Alistair Y. <ali...@sm...> - 2006-05-12 07:02:05
|
did you folks get this too? note the requirement to checkout new working copies as they're changing the root. Alistair Begin forwarded message: > From: "SourceForge.net Team" <no...@so...> > Date: 12 May 2006 02:14:38 BDT > To: <ali...@sm...> > Subject: SUBJECT: SourceForge.net: CVS service offering changes > > 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:ano...@cv...:/cvsroot/gaim co gaim > > would be changed to > > cvs -d:pserver:ano...@ga...:/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 > > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > > > > |
From: Andrew B. <a.g...@le...> - 2006-05-12 08:11:06
|
Yes, thanks. Small price to pay if they finally get the bloody thing working. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Alistair Young Sent: 12 May 2006 08:01 To: bod...@li... Subject: [Bodington-developers] Fwd: SUBJECT: SourceForge.net: CVS service offering changes did you folks get this too? note the requirement to checkout new working copies as they're changing the root. Alistair Begin forwarded message: From: "SourceForge.net Team" <no...@so...> Date: 12 May 2006 02:14:38 BDT To: <ali...@sm...> Subject: SUBJECT: SourceForge.net: CVS service offering changes 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:ano...@cv...:/cvsroot/gaim co gaim would be changed to cvs -d:pserver:ano...@ga...:/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 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline |
From: Adam M. <ada...@co...> - 2006-05-12 08:54:40
|
No I didn't - and I'm admin on 2 projects! adam _____ From: bod...@li... [mailto:bod...@li...] On Behalf Of Alistair Young Sent: 12 May 2006 08:01 To: bod...@li... Subject: [Bodington-developers] Fwd: SUBJECT: SourceForge.net: CVS service offering changes did you folks get this too? note the requirement to checkout new working copies as they're changing the root. Alistair Begin forwarded message: From: "SourceForge.net Team" <no...@so...> Date: 12 May 2006 02:14:38 BDT To: <ali...@sm...> Subject: SUBJECT: SourceForge.net: CVS service offering changes 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:ano...@cv...:/cvsroot/gaim co gaim would be changed to cvs -d:pserver:ano...@ga...:/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 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline |
From: Alexis O'C. <ale...@ou...> - 2006-05-12 09:05:48
|
Adam Marshall wrote: > No I didn’t – and I’m admin on 2 projects! > The basic impact for bodington is that the bodington host name is changing from cvs.sourceforge.net to bodington.cvs.sourceforge.net. They're doing it "this afternoon" (US presumably) so working day wise it won't affect UK users until next Monday. It effectively means that you have to check out bodington afresh with the new host name (or if you have uncommitted changes in Eclipse doing something like "Disconnect" and then "Team -> Share" against the new location). Alexis |
From: Alexis O'C. <ale...@ou...> - 2006-05-12 15:09:02
|
Adam Marshall wrote: > No I didn’t – and I’m admin on 2 projects! > The basic impact for bodington is that the bodington host name is changing from cvs.sourceforge.net to bodington.cvs.sourceforge.net. They're doing it "this afternoon" (US presumably) so working day wise it won't affect UK users until next Monday. It effectively means that you have to check out bodington afresh with the new host name (or if you have uncommitted changes in Eclipse doing something like "Disconnect" and then "Team -> Share" against the new location). Alexis -- Hmmm... I initially sent this at 09.30am today. What's the reckoning that this turns up straight away then the original one 5 minutes later eh!? |
From: Alistair Y. <ali...@sm...> - 2006-05-16 13:49:42
|
it's already changed for Guanxi On 12 May 2006, at 16:08, Alexis O'Connor wrote: > Adam Marshall wrote: >> No I didn=92t =96 and I=92m admin on 2 projects! > > The basic impact for bodington is that the bodington host name is > changing from cvs.sourceforge.net to bodington.cvs.sourceforge.net. > They're doing it "this afternoon" (US presumably) so working day =20 > wise it > won't affect UK users until next Monday. > > It effectively means that you have to check out bodington afresh with > the new host name (or if you have uncommitted changes in Eclipse doing > something like "Disconnect" and then "Team -> Share" against the new > location). > > Alexis > > --=20 > Hmmm... I initially sent this at 09.30am today. What's the =20 > reckoning that this turns up straight away then the original one 5 =20 > minutes later eh!? > > > > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, =20 > security? > Get stuff done quickly with pre-integrated technology to make your =20 > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache =20 > Geronimo > http://sel.as-us.falkag.net/sel?=20 > cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Alexis O'C. <ale...@ou...> - 2006-05-16 14:33:24
|
Alistair Young wrote: > it's already changed for Guanxi > Check the date sunshine ;-). My effort to be useful proved fruitless as I sent my mail (and it's duplicate) last Friday, but most people (including myself) didn't get either until today. Oh well ... Alexis |