SourceForge to Release SVN in Feb. 2006

[Game_Ender]

They are currently beta testing Subversion at SourceForge.  They are going to release it to everyone else in Febuary.  The news is here: https://sourceforge.net/docs/A03#january-2006.

Does this mean Code::Blocks will move back to SourceForgre?

[Ceniza]

Don't think so. Most ppl has complaint about speed access to SF's repositories and say berliOS is faster for them.

[Game_Ender]

The web access on the Berlios through WebSVN/ViewCVS is quite slow though.

[Ceniza]

Well, you don't checkout thru WebSVN/ViewCVS

I wouldn't mind getting back to SF when SVN be ready, for me it's just the same.

[thomas]

It's not slower than web CVS access at Sourceforge. But we aren't interested in that as much as in the checkout/update/commit times via SSH which are about a third of what they used to be at Sourceforge.

Besides, Sourceforge has been announcing that they are "preparing to plan to beta test" Subversion support for several years now. Since Subversion is perfectly stable and whole bunch easier to install and manage than cvs, I really wonder what they need to prepare for.

They obviously have a working set of servers with a working authentication system. Subverison uses exactly the same services and technologies as cvs does, so if they have cvs running, they really only need to install one rpm to have svn running, too. For some reason, however, this seems to be really complicated.
I do not doubt that it requires an awful lot of work and many months of planning and development to get a site such as Sourceforge up and running, but that work has already been done a long time ago. The amount of work needed to add Subversion to that working system is quite ridiculous compared to that.

[mandrav]

The web access on the Berlios through WebSVN/ViewCVS is quite slow though.

I 'd say it depends. For me, there is no comparison whatsoever on the speeds of the two sites. BerliOS is very fast, at least for us Europeans.
The only time I have to deal with SF anymore is for bugs/patches and I really hate it when I have to. The speed is worse than a 33.6K modem...

SF speeds used to be normal, not really fast, but normal. But somewhere in mid-2005 speed went under...

[artoj]

The only time I have to deal with SF anymore is for bugs/patches and I really hate it when I have to. The speed is worse than a 33.6K modem...

Why the bug and patch trackers are on SF.net (and not in Berlios)?

[thomas]

If you know a way of migrating them, please tell. They'll be gone tomorrow

[mandrav]

The only time I have to deal with SF anymore is for bugs/patches and I really hate it when I have to. The speed is worse than a 33.6K modem...

Why the bug and patch trackers are on SF.net (and not in Berlios)?

Because we can't find a reliable way to transfer the existing tracker data. If someone knows about the process, please step forward

[artoj]

Because we can't find a reliable way to transfer the existing tracker data. If someone knows about the process, please step forward

But could you slowly migrate to Berlios e.g. all new bugs/patches should be filed there?

[yop]

Because we can't find a reliable way to transfer the existing tracker data. If someone knows about the process, please step forward

But could you slowly migrate to Berlios e.g. all new bugs/patches should be filed there?

Generally it's not a good practice to split your bug reports. Consider them to have the same significance as the source repository, you wouldn't want to lose the older revisions of your code would you? The same applies for the reports.

[takeshimiya]

I've found this bash script to webcrawl the bugs of sourceforge: http://casper.ghostscript.com/~raph/crawl-sf-bugs
If anyonecan write a script to adapt it to a new bug tracking system (either berlios tracker, or bugzilla, or trak, etc) would be great.

Seems that sf may have an XML export option, too: http://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1#xml_export

Additional links:
http://www.advogato.org/article/357.html
http://mail.wikipedia.org/pipermail/wikitech-l/2004-August/024517.html