From: Dieter <Die...@ha...> - 2003-06-23 17:00:41
|
These sourceforge "backup" server move is very annoying. It's hindering open source so much. Do we have other options? Regards, Dieter |
From: F. <jrf...@tu...> - 2003-06-23 18:25:00
|
On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: > These sourceforge "backup" server move is very annoying. > It's hindering open source so much. > > Do we have other options? I've never tried but isn't possible for non-developers also access the SF CVS repository via SSH (read-only, of course)? If not then the solution would imply moving the CVS repository to a new machine, but where would that be? XFree86.org? Some SF look-a-like? Or in alternative, my University's network is not reliable enough for hosting the CVS repository on my workstation, but perhaps I could host there a mirror. It could even be synced using CVS commit scripts so that there wouldn't be a delay. But I don't know if one can access the CVS repository in SF directly (except for the nightly cvs tarballs...). José Fonseca |
From: Dieter <Die...@ha...> - 2003-06-23 20:01:36
|
Am Montag, 23. Juni 2003 20:24 schrieb Jos=E9 Fonseca: > On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter N=FCtzel wrote: > > These sourceforge "backup" server move is very annoying. > > It's hindering open source so much. > > > > Do we have other options? > > I've never tried but isn't possible for non-developers also access the > SF CVS repository via SSH (read-only, of course)? SSH member access. Which project status must someone have to get that access? I am a sf member but a "nobody" at DRI ;-) > If not then the solution would imply moving the CVS repository to a new > machine, but where would that be? XFree86.org? Some SF look-a-like? > > Or in alternative, my University's network is not reliable enough for > hosting the CVS repository on my workstation, but perhaps I could host > there a mirror. It could even be synced using CVS commit scripts so that > there wouldn't be a delay. But I don't know if one can access the CVS > repository in SF directly (except for the nightly cvs tarballs...). Another option of course. =2DDieter |
From: Martin S. <Mar...@un...> - 2003-06-23 21:04:22
|
Jos? Fonseca <jrf...@tu...> wrote: > If not then the solution would imply moving the CVS repository to a new > machine, but where would that be? XFree86.org? Some SF look-a-like? As far as I know BerliOS is hosting quite a few OpenSource projects. This is intended to be some SF alternative. I might not be up to date, but it shurely is worth a look: http://www.berlios.de/index.php.en Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Alex D. <ag...@ya...> - 2003-06-24 13:30:16
|
what about https://savannah.nongnu.org/ Alex --- Martin Spott <Mar...@un...> wrote: > Jos? Fonseca <jrf...@tu...> wrote: > > > If not then the solution would imply moving the CVS repository to a > new > > machine, but where would that be? XFree86.org? Some SF look-a-like? > > As far as I know BerliOS is hosting quite a few OpenSource projects. > This is > intended to be some SF alternative. I might not be up to date, but it > shurely is worth a look: > > http://www.berlios.de/index.php.en > > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Dieter <Die...@ha...> - 2003-06-25 17:26:20
|
Am Montag, 23. Juni 2003 22:31 schrieb Martin Spott: > Jos? Fonseca <jrf...@tu...> wrote: > > If not then the solution would imply moving the CVS repository to a new > > machine, but where would that be? XFree86.org? Some SF look-a-like? > > As far as I know BerliOS is hosting quite a few OpenSource projects. This > is intended to be some SF alternative. I might not be up to date, but it > shurely is worth a look: > > http://www.berlios.de/index.php.en Good point. Regards, Dieter |
From: Michel <mi...@da...> - 2003-06-24 14:11:37
|
On Mon, 2003-06-23 at 20:24, José Fonseca wrote: > On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: > > These sourceforge "backup" server move is very annoying. > > It's hindering open source so much. > > > > Do we have other options? [...] > If not then the solution would imply moving the CVS repository to a new > machine, but where would that be? XFree86.org? I've tried to get a discussion going about migrating to XFree86 (and Mesa, ...) before, without success. Maybe we'll have more luck this time. :) -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2003-06-24 14:27:01
|
Michel Dänzer wrote: > On Mon, 2003-06-23 at 20:24, José Fonseca wrote: > >>On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: >> >>>These sourceforge "backup" server move is very annoying. >>>It's hindering open source so much. >>> >>>Do we have other options? > > > [...] > > >>If not then the solution would imply moving the CVS repository to a new >>machine, but where would that be? XFree86.org? > > > I've tried to get a discussion going about migrating to XFree86 (and > Mesa, ...) before, without success. Maybe we'll have more luck this > time. :) The migration to mesa is in progress. To XFree86? Well, that's another question. Keith |
From: Keith W. <ke...@tu...> - 2003-06-24 14:34:08
|
Keith Whitwell wrote: > Michel Dänzer wrote: > >> On Mon, 2003-06-23 at 20:24, José Fonseca wrote: >> >>> On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: >>> >>>> These sourceforge "backup" server move is very annoying. >>>> It's hindering open source so much. >>>> >>>> Do we have other options? >> >> >> >> [...] >> >> >>> If not then the solution would imply moving the CVS repository to a new >>> machine, but where would that be? XFree86.org? >> >> >> >> I've tried to get a discussion going about migrating to XFree86 (and >> Mesa, ...) before, without success. Maybe we'll have more luck this >> time. :) > > > The migration to mesa is in progress. To XFree86? Well, that's another > question. That sounds more negative than I wanted. Basically, after the drivers are living in Mesa cvs, we could well end up just submitting patches to XFree86 for the rest - but that would be giving up a significant amount of control. Probably we'd always want to maintain an xc/ tree somewhere for infrastructure work. Keith |
From: F. <jrf...@tu...> - 2003-06-24 15:38:03
|
On Tue, Jun 24, 2003 at 03:34:24PM +0100, Keith Whitwell wrote: > Keith Whitwell wrote: > >Michel Dänzer wrote: > >>On Mon, 2003-06-23 at 20:24, José Fonseca wrote: > >>>On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: > >>>>These sourceforge "backup" server move is very annoying. It's > >>>>hindering open source so much. > >>>> > >>>>Do we have other options? > >> > >>>If not then the solution would imply moving the CVS repository to a > >>>new machine, but where would that be? XFree86.org? > >> > >>I've tried to get a discussion going about migrating to XFree86 (and > >>Mesa, ...) before, without success. Maybe we'll have more luck this > >>time. :) > > > >The migration to mesa is in progress. To XFree86? Well, that's > >another question. > > That sounds more negative than I wanted. Basically, after the drivers > are living in Mesa cvs, we could well end up just submitting patches > to XFree86 for the rest - but that would be giving up a significant > amount of control. Probably we'd always want to maintain an xc/ tree > somewhere for infrastructure work. I mentioned XFree86.org because (supposedly) it has the bandwith and machine resources to host the DRI repository, and obviously XFree86 and DRI are two very close entities. That being said, it would have to be in a seperate CVS repository so that DRI project administrators could have the same flexibility as in the SF project. Having the DRI repository as branches in the main XFree86 CVS is an utopia, now and the foreseenable future, IMO. But we really need to get a solution around the backup CVS server as it really damages the beneficial intervention of non-commiters can have since they are days behind what the commiters are doing. Is it possible that SourceForge may reconsider that policy on a indivual project basis, i.e., would'nt it be a good idea for the DRI project admins to present this issue to the SF maintainers? They usually are flexible and even if not solving the problem completly maybe they can point workable solutions. José Fonseca |
From: Michel <mi...@da...> - 2003-06-24 18:51:50
|
On Tue, 2003-06-24 at 16:34, Keith Whitwell wrote: > Keith Whitwell wrote: > > Michel Dänzer wrote: > > > >> On Mon, 2003-06-23 at 20:24, José Fonseca wrote: > >> > >>> On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: > >>> > >>>> These sourceforge "backup" server move is very annoying. > >>>> It's hindering open source so much. > >>>> > >>>> Do we have other options? > >> > >> [...] > >> > >>> If not then the solution would imply moving the CVS repository to a new > >>> machine, but where would that be? XFree86.org? > >> > >> I've tried to get a discussion going about migrating to XFree86 (and > >> Mesa, ...) before, without success. Maybe we'll have more luck this > >> time. :) > > > > The migration to mesa is in progress. Which is great, I'm looking forward to having a single libGL which works optimally no matter what you throw it at. :) BTW, isn't Mesa affected by these sf.net changes? > > To XFree86? Well, that's another question. > > That sounds more negative than I wanted. Basically, after the drivers are > living in Mesa cvs, we could well end up just submitting patches to XFree86 > for the rest - but that would be giving up a significant amount of control. > Probably we'd always want to maintain an xc/ tree somewhere for infrastructure > work. Some of us have write access there already, but I agree that access for all active developers would be very important if not a requirement. Also, as I have mentioned before, I think it might be a good idea to keep the DRM separate from the rest, but sf.net might do for that. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Dieter <Die...@ha...> - 2003-06-26 11:54:31
|
Am Montag, 23. Juni 2003 20:24 schrieb Jos=E9 Fonseca: > On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter N=FCtzel wrote: > > These sourceforge "backup" server move is very annoying. > > It's hindering open source so much. > > > > Do we have other options? > > I've never tried but isn't possible for non-developers also access the > SF CVS repository via SSH (read-only, of course)? > > If not then the solution would imply moving the CVS repository to a new > machine, but where would that be? XFree86.org? Some SF look-a-like? Maybe at www.berlios.de? mesa3D (cvs.mesa3d.sourceforge.net) seems to be affected, too. Regards, Dieter |
From: Michel <mi...@da...> - 2003-06-24 18:44:34
|
On Tue, 2003-06-24 at 17:37, José Fonseca wrote: > On Tue, Jun 24, 2003 at 03:34:24PM +0100, Keith Whitwell wrote: > > Keith Whitwell wrote: > > >Michel Dänzer wrote: > > >>On Mon, 2003-06-23 at 20:24, José Fonseca wrote: > > >>>On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: > > >>>>These sourceforge "backup" server move is very annoying. It's > > >>>>hindering open source so much. > > >>>> > > >>>>Do we have other options? > > >> > > >>>If not then the solution would imply moving the CVS repository to a > > >>>new machine, but where would that be? XFree86.org? > > >> > > >>I've tried to get a discussion going about migrating to XFree86 (and > > >>Mesa, ...) before, without success. Maybe we'll have more luck this > > >>time. :) > > > > > >The migration to mesa is in progress. To XFree86? Well, that's > > >another question. > > > > That sounds more negative than I wanted. Basically, after the drivers > > are living in Mesa cvs, we could well end up just submitting patches > > to XFree86 for the rest - but that would be giving up a significant > > amount of control. Probably we'd always want to maintain an xc/ tree > > somewhere for infrastructure work. > > I mentioned XFree86.org because (supposedly) it has the bandwith and > machine resources to host the DRI repository, and obviously XFree86 and > DRI are two very close entities. That being said, it would have to be in > a seperate CVS repository so that DRI project administrators could have > the same flexibility as in the SF project. Having the DRI repository as > branches in the main XFree86 CVS is an utopia, now and the foreseenable > future, IMO. Why, what else do we have now but branches of XFree86 CVS, except that they're in a different repository? > But we really need to get a solution around the backup CVS server as it > really damages the beneficial intervention of non-commiters can have > since they are days behind what the commiters are doing. I wonder if it's really such a pressing problem though. How many people have complained? > Is it possible that SourceForge may reconsider that policy on a indivual > project basis, i.e., would'nt it be a good idea for the DRI project > admins to present this issue to the SF maintainers? They usually are > flexible and even if not solving the problem completly maybe they can > point workable solutions. That would be good, but somehow I doubt it. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: F. <jrf...@tu...> - 2003-06-24 19:20:10
|
On Tue, Jun 24, 2003 at 08:44:32PM +0200, Michel Dänzer wrote: > On Tue, 2003-06-24 at 17:37, José Fonseca wrote: > > I mentioned XFree86.org because (supposedly) it has the bandwith and > > machine resources to host the DRI repository, and obviously XFree86 and > > DRI are two very close entities. That being said, it would have to be in > > a seperate CVS repository so that DRI project administrators could have > > the same flexibility as in the SF project. Having the DRI repository as > > branches in the main XFree86 CVS is an utopia, now and the foreseenable > > future, IMO. > > Why, what else do we have now but branches of XFree86 CVS, except that > they're in a different repository? You know very well that's not the issue. Which of the long inconclusive threads on the XFree86 forum about CVS commit access did you forgot? > > But we really need to get a solution around the backup CVS server as it > > really damages the beneficial intervention of non-commiters can have > > since they are days behind what the commiters are doing. > > I wonder if it's really such a pressing problem though. Imagine you're working with somebody testing some code, but that person has no CVS write access. After you checkin your changes what will you gonna do: tell him to wait two or three days until the SF anonymous CVS backup updates, or email him patches. Either way it sucks since it slows development. > How many people have complained? I which it had been many - it would be sign of a lot people helping - but the number it's nor everything. The current situation renders the CVS useless for any serious testing. > > Is it possible that SourceForge may reconsider that policy on a indivual > > project basis, i.e., would'nt it be a good idea for the DRI project > > admins to present this issue to the SF maintainers? They usually are > > flexible and even if not solving the problem completly maybe they can > > point workable solutions. > > That would be good, but somehow I doubt it. José Fonseca |
From: F. <jrf...@tu...> - 2003-06-24 19:33:11
|
On Tue, Jun 24, 2003 at 08:19:33PM +0100, José Fonseca wrote: > On Tue, Jun 24, 2003 at 08:44:32PM +0200, Michel Dänzer wrote: > > I wonder if it's really such a pressing problem though. > > Imagine you're working with somebody testing some code, but that person > has no CVS write access. After you checkin your changes what will you > gonna do: tell him to wait two or three days until the SF anonymous CVS > backup updates, or email him patches. Either way it sucks since it slows > development. > > > How many people have complained? > > I which it had been many - it would be sign of a lot people helping - > but the number it's nor everything. The current situation renders the > CVS useless for any serious testing. See what I mean [below]? Jose Fonseca Alex Deucher <ag...@ya...> wrote: > >CVS at sourceforge is using the backup server which has data that is >24+ hours old. I wasn't able to get it either. > >--- Maximo <ma...@ma...> wrote: >> Just a little question, Why can't a get the Savage-1_0_0-branch? I >> cat get >> the trunk, the savage-0-0-1-branch but i can't get this new one. CVS >> shows >> as if it was going to get but i keep waiting and i don't get anything >> except the directory xc/xc/CVS that's all I got. Did i miss >> something? |
From: Michel <mi...@da...> - 2003-06-24 23:26:24
|
On Tue, 2003-06-24 at 21:19, José Fonseca wrote: > On Tue, Jun 24, 2003 at 08:44:32PM +0200, Michel Dänzer wrote: > > On Tue, 2003-06-24 at 17:37, José Fonseca wrote: > > > I mentioned XFree86.org because (supposedly) it has the bandwith and > > > machine resources to host the DRI repository, and obviously XFree86 and > > > DRI are two very close entities. That being said, it would have to be in > > > a seperate CVS repository so that DRI project administrators could have > > > the same flexibility as in the SF project. Having the DRI repository as > > > branches in the main XFree86 CVS is an utopia, now and the foreseenable > > > future, IMO. > > > > Why, what else do we have now but branches of XFree86 CVS, except that > > they're in a different repository? > > You know very well that's not the issue. Which of the long inconclusive > threads on the XFree86 forum about CVS commit access did you forgot? None, I hope. There seemed to be an agreement that more committers would be good, and a couple have been added already, including me. So I doubt it would be impossible if we can come up with a good plan. > > > But we really need to get a solution around the backup CVS server as it > > > really damages the beneficial intervention of non-commiters can have > > > since they are days behind what the commiters are doing. > > > > I wonder if it's really such a pressing problem though. > > Imagine you're working with somebody testing some code, but that person > has no CVS write access. After you checkin your changes what will you > gonna do: tell him to wait two or three days until the SF anonymous CVS > backup updates, or email him patches. Either way it sucks since it slows > development. Remote development is slow by definition. When I work on something I can't test myself, I usually have people test patches first and only then commit anything. Anyway, I'm not denying there's a problem, nevertheless I think we shouldn't rush for the first best alternative. We should take the time to determine the best solution. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Dieter <Die...@ha...> - 2003-06-28 14:18:55
|
Mesa3d seems to be affected, too. No mesa CVS update for 10 days, now ;-( My DRI CVS is 12 days old... No chance from "old Europe" anymore? Greetings, Dieter |
From: F. <jrf...@tu...> - 2003-06-28 21:31:02
|
On Sat, Jun 28, 2003 at 04:18:15PM +0200, Dieter Nützel wrote: > Mesa3d seems to be affected, too. > > No mesa CVS update for 10 days, now ;-( > My DRI CVS is 12 days old... > > No chance from "old Europe" anymore? I've just checked and the tarballs in http://cvs.sourceforge.net/cvstarballs/projectname-cvsroot.tar.gz for DRI and Mesa3d are just as old as the anonymous CVS server, and from the SF documents there is no other way to directly access the repository (except contact the SF team, but you can't put that in a cron job, can you? ;-) Basically this means that CVS mirroring is impossible and the only solution to the current problem is to move the repository elsewhere. I don't know why the silence from the DRI SF project admins - I'm CC'ing to them now (at least those currently in the active) in the hope to hear what they have to say about this. I remind again that this issue should be presented to the SF team to know what's their position and what to expect from the future. This issue [of the unreliable CVS anonymous serving] together with the recent news of closing inactive and old projects may well be a sign that SF is saturating again, but this time the saturation appears to be fought not by further investment, but degrading the quality of the services. If true then it's a matter of time to collapse, or at least be unusable for big projects such as DRI. In my opinion we should consider alternatives for CVS hosting. It's not such a big deal after all (except for the hassle of setting up a new project and accounts) and we can always go back without loss of data. My 2c anyway... José Fonseca |
From: Keith W. <ke...@tu...> - 2003-06-29 22:03:50
|
José Fonseca wrote: > On Sat, Jun 28, 2003 at 04:18:15PM +0200, Dieter Nützel wrote: > >>Mesa3d seems to be affected, too. >> >>No mesa CVS update for 10 days, now ;-( >>My DRI CVS is 12 days old... >> >>No chance from "old Europe" anymore? > > > I've just checked and the tarballs in > http://cvs.sourceforge.net/cvstarballs/projectname-cvsroot.tar.gz for > DRI and Mesa3d are just as old as the anonymous CVS server, and from the > SF documents there is no other way to directly access the repository > (except contact the SF team, but you can't put that in a cron job, can > you? ;-) > > Basically this means that CVS mirroring is impossible and the only > solution to the current problem is to move the repository elsewhere. Is there a solid alternative to sourceforge? One with better backing that will keep it going if large numbers of projects start using it? > I don't know why the silence from the DRI SF project admins - I'm CC'ing > to them now (at least those currently in the active) in the hope to hear > what they have to say about this. Not so much silence as a lack of answers... > I remind again that this issue should be presented to the SF team to > know what's their position and what to expect from the future. This > issue [of the unreliable CVS anonymous serving] together with the recent > news of closing inactive and old projects may well be a sign that SF is > saturating again, but this time the saturation appears to be fought not > by further investment, but degrading the quality of the services. If > true then it's a matter of time to collapse, or at least be unusable for > big projects such as DRI. This is a reasonable proposition -- let's start putting a draft together, then. ------- SF admins, We're concerned about the recent changes to anonymous cvs access, in particular the way in which changes committed by developers take an extended period (upto days) to become visible to anonymous cvs users. As we rely heavily on a test/debug/fix cycle that includes input and interaction from anonymous cvs users, this delay represents a real roadblock for our development efforts. Can you outline the reasons that this has started happening, whether it will be resolved and if so on what timescale? DRI project developers Keith Whitwell ... |
From: Alan H. <al...@fa...> - 2003-06-30 00:04:38
|
On Sun, Jun 29, 2003 at 11:04:47PM +0100, Keith Whitwell wrote: > Jos=E9 Fonseca wrote: > >On Sat, Jun 28, 2003 at 04:18:15PM +0200, Dieter N=FCtzel wrote: > > > >>Mesa3d seems to be affected, too. > >> > >>No mesa CVS update for 10 days, now ;-( > >>My DRI CVS is 12 days old... > >> > >>No chance from "old Europe" anymore? > > > > > >I've just checked and the tarballs in > >http://cvs.sourceforge.net/cvstarballs/projectname-cvsroot.tar.gz for > >DRI and Mesa3d are just as old as the anonymous CVS server, and from t= he > >SF documents there is no other way to directly access the repository > >(except contact the SF team, but you can't put that in a cron job, can > >you? ;-) > > > >Basically this means that CVS mirroring is impossible and the only > >solution to the current problem is to move the repository elsewhere. >=20 > Is there a solid alternative to sourceforge? One with better backing t= hat=20 > will keep it going if large numbers of projects start using it? >=20 > >I don't know why the silence from the DRI SF project admins - I'm CC'i= ng > >to them now (at least those currently in the active) in the hope to he= ar > >what they have to say about this.=20 >=20 > Not so much silence as a lack of answers... >=20 > >I remind again that this issue should be presented to the SF team to > >know what's their position and what to expect from the future. This > >issue [of the unreliable CVS anonymous serving] together with the rece= nt > >news of closing inactive and old projects may well be a sign that SF i= s > >saturating again, but this time the saturation appears to be fought no= t > >by further investment, but degrading the quality of the services. If > >true then it's a matter of time to collapse, or at least be unusable f= or > >big projects such as DRI. >=20 > This is a reasonable proposition -- let's start putting a draft togethe= r,=20 > then. >=20 > ------- >=20 > SF admins, >=20 > We're concerned about the recent changes to anonymous cvs access, in=20 > particular the way in which changes committed by developers take an=20 > extended period (upto days) to become visible to anonymous cvs users. = As=20 > we rely heavily on a test/debug/fix cycle that includes input and=20 > interaction from anonymous cvs users, this delay represents a real=20 > roadblock for our development efforts. Can you outline the reasons tha= t=20 > this has started happening, whether it will be resolved and if so on wh= at=20 > timescale? Reading the SF master bug database, the only workaround for this problem is to create nightly CVS snapshots of the trunk for people to download who are not members of the project.=20 That's the SF admins response on the master bug database for now anyway. Alan. |
From: F. <jrf...@tu...> - 2003-06-30 11:07:22
|
On Mon, Jun 30, 2003 at 01:04:18AM +0100, Alan Hourihane wrote: > On Sun, Jun 29, 2003 at 11:04:47PM +0100, Keith Whitwell wrote: > > This is a reasonable proposition -- let's start putting a draft together, > > then. > > > > ------- > > > > SF admins, > > > > We're concerned about the recent changes to anonymous cvs access, in > > particular the way in which changes committed by developers take an > > extended period (upto days) to become visible to anonymous cvs users. As > > we rely heavily on a test/debug/fix cycle that includes input and > > interaction from anonymous cvs users, this delay represents a real > > roadblock for our development efforts. Can you outline the reasons that > > this has started happening, whether it will be resolved and if so on what > > timescale? > > Reading the SF master bug database, the only workaround for this problem > is to create nightly CVS snapshots of the trunk for people to download > who are not members of the project. > > That's the SF admins response on the master bug database for now anyway. > > Alan. I've searched for the master bug Alan mentions and I suppose it's this one: http://sourceforge.net/tracker/index.php?func=detail&aid=721915&group_id=1&atid=200001 According to that the situation is provisory and should be resolved in August with new hardware. The bug answers to most questions we have and that Keith outlined in his draft, and since the SF team's position appears to be inflexible so I don't know whether there is any point in contact them. I'm going to follow Alan suggestion and setup a rsync mirror of the CVS trunk checkout on my machine at the Uni. I just don't know wether I'll do the update from a cronjob (if so how frequent?), or if trigered by the commits (e.g., using a CVS script, or by making a procmail rule for dri-patches). I'll let everybody know when this is available. José Fonseca |
From: F. <jrf...@tu...> - 2003-06-30 20:41:43
|
On Mon, Jun 30, 2003 at 12:06:05PM +0100, José Fonseca wrote: > I'm going to follow Alan suggestion and setup a rsync mirror of the CVS > trunk checkout on my machine at the Uni. I just don't know wether I'll > do the update from a cronjob (if so how frequent?), or if trigered by > the commits (e.g., using a CVS script, or by making a procmail rule for > dri-patches). I'll let everybody know when this is available. Half done. For everybody eager to get the latest DRI trunk do something like: rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/ HEAD/ At the moment this is being updated nightly (4 o'clock UK time), but I'll see if I can find a way to update a little more often as mentioned above. José Fonseca |
From: Linus T. <tor...@os...> - 2003-07-01 00:15:13
|
On Mon, 30 Jun 2003, [iso-8859-15] Jos=E9 Fonseca wrote: >=20 > Half done. For everybody eager to get the latest DRI trunk do something > like: >=20 > rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/ HEAD/ Thanks. CVS was getting to be useless. Linus |
From: F. <jrf...@tu...> - 2003-07-16 11:07:03
|
I've put more branches in my rsync mirror, namely: config-0-0-1-branch mach64-0-0-6-branch newdrm-0-0-1-branch savage-0-0-1-branch savage-1_0_0-branch To download a branch do something like: rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/branch/ branch/ where 'branch' is one of the branches above. Be careful with the trailing '/' or you might end erasing your home directory or whateever direcotory you're doing this. Use the '-n' (dry-run) option if you're not confident. For those already previous rsync'ing with the trunk please change your scripts to something like: rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/HEAD/ HEAD/ The branches are all updated nightly (4:00AM BST) and I think that at this point it's not worth to increase the update rate. Please let me know privately if you have any problem with this. José Fonseca |
From: F. <jrf...@tu...> - 2003-07-16 11:33:32
|
On Wed, Jul 16, 2003 at 12:06:20PM +0100, José Fonseca wrote: > Be careful with the > trailing '/' or you might end erasing your home directory or whateever > directory you're doing this. Forget this nonsense. I had little sleep today and it shows. Still the '/' are important, otherwise in the next update you'll download the whole tree again into a subdirectory. José Fonseca |