Hi everybody
I followed the conversation about the SF CVS problem and noticed all the suggestions for switching to SVN, to another server or even to move away from SourceForge. Just to make clear, I'm aware of the current CVS problems and I'm interested in better solution as well as you all are.
The reason why I chose SF was the availability of tools without having to configure them by myself. This is something I still don't want to do and what I don't have time for.
In October 2005 we discussed about setting up a Trac system which would combine a wiki for documentation, a bug tracker and a SVN server together in one box. We all agreed that this would be a very nice tool for further development. Then somebody offered to install Trac on his server (I don't have a server with Python available) and started setting up the service. Due lack of time, this was not finished and somebody else offered to take care of that and set up a new Trac installation. This was in December 2005. The result of that can be seen at http://trac.roundcube.net/. He imported a snapshot from the CVS and all SF tracker data and I added some styling to the new platform. We discussed some details about user management and some configuration changes and the Trac installation got finished for about 90%. February 26 was the last time I heard from Steeve and asked him for a target date when we can move data from SF to our new platform. Unfortunately an answer is still missing...
As you can see, serious attempts were made to move away from SF but the main problem of open source projects is the quick loss of interest and the missing reliability of some project members. I can understand that since I have very little time for the project myself.
After almost half a year, I call again for somebody who is willing to install and to maintain a Trac system, which is still a very good solution for our project, I guess. I can provide DNS entries, styles for the Trac site and some adapted Python scripts for importing data from SF.
In the mean time, I published another CVs snapshot and we could move to the SF SVN server until we (hopefully) have our Trac platform ready.
Comments are welcome...
Thomas
On Fri, 5 May 2006, Thomas Bruederli wrote:
I followed the conversation about the SF CVS problem and noticed all the suggestions for switching to SVN, to another server or even to move away from SourceForge. Just to make clear, I'm aware of the current CVS problems and I'm interested in better solution as well as you all are.
Thanks for replying, and showing that you have been working on
this - I think it probably felt to many that no one was paying attention.
In the mean time, I published another CVs snapshot and we could move to the SF SVN server until we (hopefully) have our Trac platform ready.
Given the history of this process, it seems like this would be a
good idea.
Jon Daley http://jon.limedaley.com/
Happiness is not a station you arrive at, but a manner of traveling. -- Margaret Lee Runbeck
Hi all,
We are using SVN and Trac for our own software development. I can setup a VDS for you (Debian) where the main developer(s) get(s) root access. We pay the bill for the VDS, and you guys have full control. Probably a volunteer on this list can handle the installation and configuration of SVN and Trac. I can do it, but wouldn't recommend that ;)
We are planning on using RoundCube for some of our products and are happy to be able to contribute something to the project. ___ Dreas van Donselaar Director & co-founder
SpamExperts B.V. Postbus 309 6200 AH Maastricht The Netherlands
T: +31 (0)626202808 F: +31 (0)842203930 E: aj.vandonselaar@spamexperts.com W: http://www.spamexperts.com/
MSN: dreas@emailaccount.nl AIM: dreas1983 Y!: dreasvandonselaar Skype: dreasvandonselaar ICQ: 108756
-----Original Message----- From: Thomas Bruederli [mailto:roundcube@gmail.com] Sent: vrijdag 5 mei 2006 21:11 To: RoundCube Dev Subject: CVS, SVN, Wiki, Trac
Hi everybody
I followed the conversation about the SF CVS problem and noticed all the suggestions for switching to SVN, to another server or even to move away from SourceForge. Just to make clear, I'm aware of the current CVS problems and I'm interested in better solution as well as you all are.
The reason why I chose SF was the availability of tools without having to configure them by myself. This is something I still don't want to do and what I don't have time for.
In October 2005 we discussed about setting up a Trac system which would combine a wiki for documentation, a bug tracker and a SVN server together in one box. We all agreed that this would be a very nice tool for further development. Then somebody offered to install Trac on his server (I don't have a server with Python available) and started setting up the service. Due lack of time, this was not finished and somebody else offered to take care of that and set up a new Trac installation. This was in December 2005. The result of that can be seen at http://trac.roundcube.net/. He imported a snapshot from the CVS and all SF tracker data and I added some styling to the new platform. We discussed some details about user management and some configuration changes and the Trac installation got finished for about 90%. February 26 was the last time I heard from Steeve and asked him for a target date when we can move data from SF to our new platform. Unfortunately an answer is still missing...
As you can see, serious attempts were made to move away from SF but the main problem of open source projects is the quick loss of interest and the missing reliability of some project members. I can understand that since I have very little time for the project myself.
After almost half a year, I call again for somebody who is willing to install and to maintain a Trac system, which is still a very good solution for our project, I guess. I can provide DNS entries, styles for the Trac site and some adapted Python scripts for importing data from SF.
In the mean time, I published another CVs snapshot and we could move to the SF SVN server until we (hopefully) have our Trac platform ready.
Comments are welcome...
Thomas
Dreas van Donselaar wrote:
We are using SVN and Trac for our own software development. I can setup a VDS for you (Debian) where the main developer(s) get(s) root access. We pay the bill for the VDS, and you guys have full control. Probably a volunteer on this list can handle the installation and configuration of SVN and Trac. I can do it, but wouldn't recommend that ;)
I'd be willing to help out with the day-to-day running of such an environment, but I don't have the time take on a project lead type of role.
If someone competent steps forward to take charge, I'll try to help whenever I can.
Bob
I thought I had sent this out on the list, but I replied in a rush and goofed up. Anyway, here is what I sent:
I would be willing to help out with this, too. I am currently installing a Trac/Subversion server on my dedicated Debian server to see how it is all done (I have run a Subversion server before, but not Trac). It has about 900 GB of transfer left over every month, which should be enough for this project. I also have an extra IP address I could use for it. The server has been rock solid for 240+ days so far.
Let me know if I can be of service.
Thanks, Adam
On 5/6/06, B. Johannessen bob@db.org wrote:
Dreas van Donselaar wrote:
We are using SVN and Trac for our own software development. I can setup
a
VDS for you (Debian) where the main developer(s) get(s) root access. We
pay
the bill for the VDS, and you guys have full control. Probably a
volunteer
on this list can handle the installation and configuration of SVN and
Trac.
I can do it, but wouldn't recommend that ;)
I'd be willing to help out with the day-to-day running of such an environment, but I don't have the time take on a project lead type of role.
If someone competent steps forward to take charge, I'll try to help whenever I can.
Bob
Thomas Bruederli wrote:
Hi everybody
I followed the conversation about the SF CVS problem and noticed all the suggestions for switching to SVN, to another server or even to move away from SourceForge. Just to make clear, I'm aware of the current CVS problems and I'm interested in better solution as well as you all are.
The reason why I chose SF was the availability of tools without having to configure them by myself. This is something I still don't want to do and what I don't have time for.
In October 2005 we discussed about setting up a Trac system which would combine a wiki for documentation, a bug tracker and a SVN server together in one box. We all agreed that this would be a very nice tool for further development. Then somebody offered to install Trac on his server (I don't have a server with Python available) and started setting up the service. Due lack of time, this was not finished and somebody else offered to take care of that and set up a new Trac installation. This was in December 2005. The result of that can be seen at http://trac.roundcube.net/. He imported a snapshot from the CVS and all SF tracker data and I added some styling to the new platform. We discussed some details about user management and some configuration changes and the Trac installation got finished for about 90%. February 26 was the last time I heard from Steeve and asked him for a target date when we can move data from SF to our new platform. Unfortunately an answer is still missing...
As you can see, serious attempts were made to move away from SF but the main problem of open source projects is the quick loss of interest and the missing reliability of some project members. I can understand that since I have very little time for the project myself.
After almost half a year, I call again for somebody who is willing to install and to maintain a Trac system, which is still a very good solution for our project, I guess. I can provide DNS entries, styles for the Trac site and some adapted Python scripts for importing data from SF.
In the mean time, I published another CVs snapshot and we could move to the SF SVN server until we (hopefully) have our Trac platform ready.
Comments are welcome...
Thomas
While I don't have experience administering Trac, and no SVN beyond my own, I do have plenty of server space and BW. If mirroring, or any other need arises I would be happy to lend a hand. Anything that would benefit RC is more than welcome.
I have put up what I have so far on my server: http://trac.grelck.net/roundcube . The SVN server is at https://svn.grelck.net/public/roundcube I'm still playing with the user administration, etc.
Thomas: let me know if you would like me to continue.
Thanks, Adam
On 5/5/06, Thomas Bruederli roundcube@gmail.com wrote:
Hi everybody
I followed the conversation about the SF CVS problem and noticed all the suggestions for switching to SVN, to another server or even to move away from SourceForge. Just to make clear, I'm aware of the current CVS problems and I'm interested in better solution as well as you all are.
The reason why I chose SF was the availability of tools without having to configure them by myself. This is something I still don't want to do and what I don't have time for.
In October 2005 we discussed about setting up a Trac system which would combine a wiki for documentation, a bug tracker and a SVN server together in one box. We all agreed that this would be a very nice tool for further development. Then somebody offered to install Trac on his server (I don't have a server with Python available) and started setting up the service. Due lack of time, this was not finished and somebody else offered to take care of that and set up a new Trac installation. This was in December 2005. The result of that can be seen at http://trac.roundcube.net/. He imported a snapshot from the CVS and all SF tracker data and I added some styling to the new platform. We discussed some details about user management and some configuration changes and the Trac installation got finished for about 90%. February 26 was the last time I heard from Steeve and asked him for a target date when we can move data from SF to our new platform. Unfortunately an answer is still missing...
As you can see, serious attempts were made to move away from SF but the main problem of open source projects is the quick loss of interest and the missing reliability of some project members. I can understand that since I have very little time for the project myself.
After almost half a year, I call again for somebody who is willing to install and to maintain a Trac system, which is still a very good solution for our project, I guess. I can provide DNS entries, styles for the Trac site and some adapted Python scripts for importing data from SF.
In the mean time, I published another CVs snapshot and we could move to the SF SVN server until we (hopefully) have our Trac platform ready.
Comments are welcome...
Thomas
Adam Grelck wrote:
I have put up what I have so far on my server: http://trac.grelck.net/roundcube . The SVN server is at https://svn.grelck.net/public/roundcube https://svn.grelck.net/public/roundcube . I'm still playing with the user administration, etc.
Thomas: let me know if you would like me to continue.
Well, if you already got that far, I would appreciate it. As you posted before, you have enough capacity and BW on your server, right? I hope that you will be able to complete this installation :-)
Try to import the CVS tarball which contains all the revisions. I've put the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
An interesting point might be the import of the current tracker data from SourceForge. I guess there's a script to do that and I found this wiki page about it: http://trac.grelck.net/roundcube/wiki/TracImport
Regarding the post of Randy Noval (http://lists.roundcube.net/mail-archive/roundcube.dev/2006/05/79/) we could talk about mirrored SVN repositories (such as the one from Jon Daley) later, once the "official" one is running. I now see the advantages of those and please forgive me for my ignorance, I was just anxious to lose control when having several repositories around.
Thanks so far! Thomas
Thanks, Adam
On Mon, 8 May 2006, Thomas Bruederli wrote:
Try to import the CVS tarball which contains all the revisions. I've put the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
I was hoping this was the current dev CVS version - I tried to use
this tarball as a local cvsroot, but either I did it wrong, or nothing has been updated in it, since sf went down, or this is an old version.
Regarding the post of Randy Noval (http://lists.roundcube.net/mail-archive/roundcube.dev/2006/05/79/) we could talk about mirrored SVN repositories (such as the one from Jon Daley) later, once the "official" one is running. I now see the advantages of those and please forgive me for my ignorance, I was just anxious to lose control when having several repositories around.
Was this conversation ever resolved? I don't think having
multiple writable repositories is a good idea. For myself, I was suggesting a read-only mirror.
Jon Daley wrote:
On Mon, 8 May 2006, Thomas Bruederli wrote:
Try to import the CVS tarball which contains all the revisions. I've put the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
I was hoping this was the current dev CVS version - I tried to use
this tarball as a local cvsroot, but either I did it wrong, or nothing has been updated in it, since sf went down, or this is an old version.
Well, I just downloaded the "Nighty tarball" from SF which should contain a copy from last night. It's possible that this service does not work either :-) Haven't checked the contents so far.
Regarding the post of Randy Noval (http://lists.roundcube.net/mail-archive/roundcube.dev/2006/05/79/) we could talk about mirrored SVN repositories (such as the one from Jon Daley) later, once the "official" one is running. I now see the advantages of those and please forgive me for my ignorance, I was just anxious to lose control when having several repositories around.
Was this conversation ever resolved? I don't think having multiple
writable repositories is a good idea. For myself, I was suggesting a read-only mirror.
OK, then I misunderstood your suggestion. I agree, that a mirrored read-only repository would be a good idea. Once we have a "reliable" SVN rep running, an anonymous checkout for sync should be possible at every time.
Regards, Thomas
On Mon, 8 May 2006 10:18:25 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
On Mon, 8 May 2006, Thomas Bruederli wrote:
Try to import the CVS tarball which contains all the revisions. I've put the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
I was hoping this was the current dev CVS version - I tried to use this tarball as a local cvsroot, but either I did it wrong, or nothing has been updated in it, since sf went down, or this is an old version.
It converts just fine to subversion for me - 175 total commits. I can put up the resulting SVN tarball up somewhere for grabs if you want me to.
Cheers,
Auke
At the end of the day the trac and the writeable SVN repository is still going to be hosted at www.roundcube.net right? I would certainly prefer that we use roundcube.net instead of spreading to personal domains.
-Charles
On Mon, 8 May 2006 15:22:33 +0000, Auke Kok sofar@foo-projects.org wrote:
On Mon, 8 May 2006 10:18:25 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
On Mon, 8 May 2006, Thomas Bruederli wrote:
Try to import the CVS tarball which contains all the revisions. I've
put
the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
I was hoping this was the current dev CVS version - I tried to use this tarball as a local cvsroot, but either I did it wrong, or nothing
has
been updated in it, since sf went down, or this is an old version.
It converts just fine to subversion for me - 175 total commits. I can put up the resulting SVN tarball up somewhere for grabs if you want me to.
latest svn log on the converted trunk:
r175 | roundcube | 2006-03-27 13:00:25 -0800 (Mon, 27 Mar 2006) | 2 lines
Fixed XHTML validation issue
oops - it seems that the SF backup procedure also suffers from the date lag - this is severely outdated as well.
Auke
You can just add "trac" and "svn" as A record for roundcube.net right? Then Adam just has to make sure that roundcube.net is working. ___ Dreas van Donselaar Director & co-founder
SpamExperts B.V. Postbus 309 6200 AH Maastricht The Netherlands
T: +31 (0)626202808 F: +31 (0)842203930 E: aj.vandonselaar@spamexperts.com W: http://www.spamexperts.com/
MSN: dreas@emailaccount.nl AIM: dreas1983 Y!: dreasvandonselaar Skype: dreasvandonselaar ICQ: 108756
-----Original Message----- From: Charles McNulty [mailto:charles@charlesmcnulty.com] Sent: maandag 8 mei 2006 17:28 To: RoundCube Dev Subject: Re: CVS, SVN, Wiki, Trac
At the end of the day the trac and the writeable SVN repository is still going to be hosted at www.roundcube.net right? I would certainly prefer that we use roundcube.net instead of spreading to personal domains.
-Charles
Dreas van Donselaar wrote:
You can just add "trac" and "svn" as A record for roundcube.net right? Then Adam just has to make sure that roundcube.net is working.
No problem, this is what I intended to do...
~Thomas
-----Original Message----- From: Charles McNulty [mailto:charles@charlesmcnulty.com] Sent: maandag 8 mei 2006 17:28 To: RoundCube Dev Subject: Re: CVS, SVN, Wiki, Trac
At the end of the day the trac and the writeable SVN repository is still going to be hosted at www.roundcube.net right? I would certainly prefer that we use roundcube.net instead of spreading to personal domains.
-Charles
The code that is in my repository is from a CVS checkout done a couple nights ago from SourceForge (it worked for me then)- is that different from the tarball?
I'm looking into importing the tracker data from SF right now.
How much bandwidth would you anticipate all of this using? I have roughly 900 GB unused each month, with an additional 500 GB/month that I can add to that for $20 (one time fee). Why don't they have Rollover data transfer??
Adam
On 5/8/06, Thomas Bruederli roundcube@gmail.com wrote:
Adam Grelck wrote:
I have put up what I have so far on my server: http://trac.grelck.net/roundcube . The SVN server is at https://svn.grelck.net/public/roundcube https://svn.grelck.net/public/roundcube . I'm still playing with the user administration, etc.
Thomas: let me know if you would like me to continue.
Well, if you already got that far, I would appreciate it. As you posted before, you have enough capacity and BW on your server, right? I hope that you will be able to complete this installation :-)
Try to import the CVS tarball which contains all the revisions. I've put the current version to http://demo.roundcube.net/dl/roundcubemail-cvsroot.tar.bz2
An interesting point might be the import of the current tracker data from SourceForge. I guess there's a script to do that and I found this wiki page about it: http://trac.grelck.net/roundcube/wiki/TracImport
Regarding the post of Randy Noval (http://lists.roundcube.net/mail-archive/roundcube.dev/2006/05/79/) we could talk about mirrored SVN repositories (such as the one from Jon Daley) later, once the "official" one is running. I now see the advantages of those and please forgive me for my ignorance, I was just anxious to lose control when having several repositories around.
Thanks so far! Thomas
Thanks, Adam
Adam Grelck wrote:
How much bandwidth would you anticipate all of this using? I have roughly 900 GB unused each month, with an additional 500 GB/month that I can add to that for $20 (one time fee). Why don't they have Rollover data transfer??
9TB is likely to go by quite quickly the next time RoundCube finds itself on the front page of Slashdot.
A public CVS/SVN server really shouldn't be put on a connection with a transfer cap (as opposed to a bandwidth cap).
Bob
At 10 Mbps, it would take a bit over 8 days of 100% utilization to use up all of the transfer (add another 4.6 if I upgraded the server) - if 10 Mbps isn't enough, then my server may not be adequate. I'll be happy to hand over what I have set up to someone if they have better facilities, I just decided to give it a shot since I like the project.
Adam
On 5/9/06, B. Johannessen bob@db.org wrote:
Adam Grelck wrote:
How much bandwidth would you anticipate all of this using? I have roughly 900 GB unused each month, with an additional 500 GB/month that I can add to that for $20 (one time fee). Why don't they have Rollover data transfer??
9TB is likely to go by quite quickly the next time RoundCube finds itself on the front page of Slashdot.
A public CVS/SVN server really shouldn't be put on a connection with a transfer cap (as opposed to a bandwidth cap).
Bob
On 5/10/06, B. Johannessen bob@db.org wrote:
Adam Grelck wrote:
How much bandwidth would you anticipate all of this using? I have roughly 900 GB unused each month, with an additional 500 GB/month that I can add to that for $20 (one time fee). Why don't they have Rollover data transfer??
9TB is likely to go by quite quickly the next time RoundCube finds itself on the front page of Slashdot.
A public CVS/SVN server really shouldn't be put on a connection with a transfer cap (as opposed to a bandwidth cap).
Keep in mind that a Slashdotting isn't likely to impact that much on a SVN server. For the most part that sort of crowd would be hitting the website, demo site, and the releases. Is there any reason to not keep storing the releases on SF.net?
Cheers Derek
Derek Hinchliffe wrote:
On 5/10/06, B. Johannessen bob@db.org wrote:
Adam Grelck wrote:
How much bandwidth would you anticipate all of this using? I have roughly 900 GB unused each month, with an additional 500 GB/month
that I
can add to that for $20 (one time fee). Why don't they have Rollover data transfer??
9TB is likely to go by quite quickly the next time RoundCube finds itself on the front page of Slashdot.
A public CVS/SVN server really shouldn't be put on a connection with a transfer cap (as opposed to a bandwidth cap).
Keep in mind that a Slashdotting isn't likely to impact that much on a SVN server. For the most part that sort of crowd would be hitting the website, demo site, and the releases. Is there any reason to not keep storing the releases on SF.net?
We never spoke about removing the website and the releases from SF. I'd like to keep them there because they can handle such traffic and the mirroring system is quite useful and seems to work fine.
I agree, that a Slashdot "attack" will not primarily hit the SVN server.
~Thomas
Cheers Derek