Switching to subversion for version control
Mauro and I are considering the move from CVS to subversion for Wget's version control. Although switching to subversion is not entirely uncontroversial, it has advantages that make it great food for thought. CVS's network usage is appalling. I have a fairly slow upload link on my ADSL (the measly 384/64 kbps is the norm here), and committing the ChangeLog or any larger source file is a nightmare. Subversion is apparently smart enough to only upload the differences. `cvs update' is, for whatever reason abysmally slow, even when there are no changes to merge. Having to go to network for `cvs diff' is simply atrocious (subversion keeps around a pristine copy of the source and simply diffs against it) and seriously slows me down. Then there are modern features like atomic commits/updates, revisions that automatically span over the whole source tree, sane handling of file renames, sane(r) handling of branches, secure client authentication, etc., that point to subversion. There are other VC's to choose from, but the enticing things about subversion are: * It seems to be fairly stable and is now being used by some very large projects, including Apache, Samba, Mono, Zope, and (as of today) KDE. So far they don't seem to be regretting the move. * Its UI intentionally mimics CVS, while fixing the bogusness. This is a boon for those of us used to CVS, those of us including the vast majority of free software developers. * It is my impression that subversion is boring and conservative in the same sense in which Linux is boring -- it is striving not to implement the latest in academic research, but to have the features that are understood and have been tried elsewhere. I appreciate that, and I believe it sets subversion apart from the more ambitious of the competing projects, the proponents of which are very loud on slashdot, but that seemed to be much less used in practice. * It is apparently possible to migrate the entire CVS history of an existing project to subversion. That way our history will not be lost. I'd like to hear arguments pro and con. I'm also interested in information about free svn hosting. sunsite/dotsrc and savannah.gnu.org currently don't seem to be offering subversion hosting. There is www.berlios.de, but I have no experience with them.
RE: wget 1.10 beta 1
Windows MSVC6 binary for testing purposes here: http://xoomer.virgilio.it/hherold/ Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax -Original Message- From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 8:41 PM To: wget@sunsite.dk Subject: wget 1.10 beta 1 dear friends, i have just released the first beta version of wget 1.10: ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-beta1.tar.gz ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-beta1.tar.bz2 you are encouraged to download the tarballs, test if the code works properly and report any bug you find. i am still doing tests on this code, but it seems to work fine, so i think we'll be able to release wget 1.10 in 7-10 days. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human Machine Cognition http://www.ihmc.us GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: Switching to subversion for version control
I switched to Subversion for all my projects in July last year and haven't looked back. Wholeheartedly recommend it. Cheers, Wincent El 12/05/2005, a las 12:24, Hrvoje Niksic escribió: Mauro and I are considering the move from CVS to subversion for Wget's version control. Although switching to subversion is not entirely uncontroversial, it has advantages that make it great food for thought. CVS's network usage is appalling. I have a fairly slow upload link on my ADSL (the measly 384/64 kbps is the norm here), and committing the ChangeLog or any larger source file is a nightmare. Subversion is apparently smart enough to only upload the differences. `cvs update' is, for whatever reason abysmally slow, even when there are no changes to merge. Having to go to network for `cvs diff' is simply atrocious (subversion keeps around a pristine copy of the source and simply diffs against it) and seriously slows me down. Then there are modern features like atomic commits/updates, revisions that automatically span over the whole source tree, sane handling of file renames, sane(r) handling of branches, secure client authentication, etc., that point to subversion. There are other VC's to choose from, but the enticing things about subversion are: * It seems to be fairly stable and is now being used by some very large projects, including Apache, Samba, Mono, Zope, and (as of today) KDE. So far they don't seem to be regretting the move. * Its UI intentionally mimics CVS, while fixing the bogusness. This is a boon for those of us used to CVS, those of us including the vast majority of free software developers. * It is my impression that subversion is boring and conservative in the same sense in which Linux is boring -- it is striving not to implement the latest in academic research, but to have the features that are understood and have been tried elsewhere. I appreciate that, and I believe it sets subversion apart from the more ambitious of the competing projects, the proponents of which are very loud on slashdot, but that seemed to be much less used in practice. * It is apparently possible to migrate the entire CVS history of an existing project to subversion. That way our history will not be lost. I'd like to hear arguments pro and con. I'm also interested in information about free svn hosting. sunsite/dotsrc and savannah.gnu.org currently don't seem to be offering subversion hosting. There is www.berlios.de, but I have no experience with them.
Re: SSL option documentation
Doug Kaufman [EMAIL PROTECTED] writes: That sounds like a good plan. I'll try to make such a change. If we do call SSL_CTX_set_default_paths, should we document SSL_CERT_* env variables as you originally suggested? I think so. I did send a message to the openssl-dev list about this. Let's wait to see what the openssl developers say. Any news on this? A side-effect of this development is that wget-1.10-beta1 refuses to download from any SSL server if the certificate authorities aren't locally configured. Since OpenSSL doesn't come with a preinstalled CA certificate bundle and Wget doesn't come with a preinstalled bundle either, where is the user to get a bundle from? (On my Debian installation the certificates come with the ca-certificates package and are apparently assembled from different sources, the most significant being Mozilla. On SuSE 9.2 the CA certificates come with the openssl package.) The users will complain about this, and I'd like to know what to tell them other than use --no-check-certificate.
Re: SSL option documentation
On Thu, 12 May 2005, Hrvoje Niksic wrote: (On my Debian installation the certificates come with the ca-certificates package and are apparently assembled from different sources, the most significant being Mozilla. On SuSE 9.2 the CA certificates come with the openssl package.) There are no license restrictions that prevent you from using/bundling/include the Mozilla one (if you want to). I have a little service up and running for those who wants the latest Mozilla ca cert bundle in PEM format: http://curl.haxx.se/docs/caextract.html The Debian wget packager will of coure be encouraged to make wget use the already installed cacert file. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: SSL option documentation
Daniel Stenberg [EMAIL PROTECTED] writes: There are no license restrictions that prevent you from using/bundling/include the Mozilla one (if you want to). I have a little service up and running for those who wants the latest Mozilla ca cert bundle in PEM format: http://curl.haxx.se/docs/caextract.html Thanks for pointing this out. I now tested Wget on an OpenSSL installation without a site bundle and the extracted bundle works flawlessly. The Debian wget packager will of coure be encouraged to make wget use the already installed cacert file. Yes, wget should suggest (or possibly even recommend) the package with the CA certificates.
RE: Switching to subversion for version control
You might want to give Ibiblio a try (www.ibiblio.org). They host my Slack/390 web/FTP site at no cost. They host a _bunch_ of sites at no cost. Mark Post -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 5:24 AM To: wget@sunsite.dk Subject: Switching to subversion for version control -snip- I'm also interested in information about free svn hosting. sunsite/dotsrc and savannah.gnu.org currently don't seem to be offering subversion hosting. There is www.berlios.de, but I have no experience with them.
Re: Switching to subversion for version control
Post, Mark K [EMAIL PROTECTED] writes: You might want to give Ibiblio a try (www.ibiblio.org). They host my Slack/390 web/FTP site at no cost. They host a _bunch_ of sites at no cost. But do they host subversion? I can't find any mention of it with google.
RE: Switching to subversion for version control
I really don't know, but they seem very accommodating to people, especially Open Source projects such as wget. It's certainly worth an email to find out. Send your request to help at ibiblio.org. Mark Post -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 3:46 PM To: Post, Mark K Cc: wget@sunsite.dk Subject: Re: Switching to subversion for version control Post, Mark K [EMAIL PROTECTED] writes: You might want to give Ibiblio a try (www.ibiblio.org). They host my Slack/390 web/FTP site at no cost. They host a _bunch_ of sites at no cost. But do they host subversion? I can't find any mention of it with google.
