[wx-discuss] new project hosting provider... me?

[David Elliott]

Hi Robin,

On May 26, 2007, at 12:45 AM, Robin Dunn wrote:

> Which brings me to my question for the community.  How many of you  
> feel that it'd be worth donating a few bucks to get, among other  
> things, faster source code checkouts and SVN support? (Finally!)   
> If we also move the mail lists and archives then we can switch back  
> to Mailman and dump *@^$# ezmlm.
>

If you plan on moving the source tree to a reasonably quick svn  
server I'll be more than happy to donate $50 right now to get the  
ball rolling.  Not only is the slowness and downtime of the CVS  
server ridiculous but after having used svn for several projects I am  
really sick of fighting with CVS.  I realize there are CVS front-ends  
out there that help with this but ultimately you still have to fight  
CVS to some extent.

Newer versions of the svn client take up much less space when  
checking out a tree so the major complaint of a few years ago (huge  
checkout size) doesn't apply anymore.

As for Mailman instead of EZMLM, I don't know.  There are some things  
I don't like about EZMLM like the archives (they are horrible) and  
the installation which is much harder than Mailman.  However, there  
are some pretty key things I don't like about Mailman.  Take for  
instance bounces.  EZMLM sets Return-Path to include the message  
number and the e-mail address that it is sending the mail to.  That  
means that when a bounce occurs, EZMLM immediately knows all of the  
subscriber,message tuples that bounced.  By contrast, Mailman uses  
listname-admin at listdomain for all Return-Path.  That means that  
Mailman then has to parse the bounce to figure out which subscriber  
it came from.  If you are the mailman admin you then get messages  
when Mailman is unable to parse the bounce which in my experience  
happens pretty frequently.

So, if I were you, I'd start small with the source tree and leave the  
mailing lists as is for now.  The source tree is pretty easy to  
maintain since only a few of us have any sort of write access to it  
and all access happens either through ssh, https, http, or some  
combination of them.  E-mail administration is a whole different ball  
game that requires dealing with all sorts of really broken mail  
servers and as of late broken spam filters that send bounce messages  
in a very strange format.

> In the meantime, I'll see if I can do a test run of converting a  
> snapshot of the CVS repository and setting up the server, so that  
> we can get a better feel for resource utilization and response  
> times.  The last time I played with converting from CVS to SVN a  
> couple years ago, I remember it taking a few hours, but most of  
> that was scripts crunching data.  When it was finished, the SVN  
> repo had over 45K revisions in it.  So doing it again will be good  
> practice for the real thing.
>
This is going to be the hard part.  I tried this a couple of years  
ago with a reasonably small tree.  One thing I didn't like was that  
the conversion script wrote everything as /trunk/ProjectName, / 
branches/BranchName/ProjectName, and /tags/TagName/ProjectName.  I  
suppose this makes sense when you have tags or branches that span  
multiple projects but our only projects are wxWidgets and wxWebsite.   
The tags and branches are not common between them so this type of svn  
structure tends to be confusing.  The /ProjectName/trunk, / 
ProjectName/branches/BranchName, and /ProjectName/tags/TagName  
structure seems to work much better in most cases even though some  
svn developer decided from on high that this is somehow "wrong."

One potential way around this is to do two completely separate svn  
roots.  Have one for the source tree (or source trees if we ever  
split wxWidgets into separate projects) and another for wxWebsite (or  
websites if we ever maintained multiple websites.  This would require  
splitting the one CVS root into two svn roots but that shouldn't be  
very difficult.  This probably interacts better with svn because I  
don't believe there is any case where we'd want to copy a file from  
the source tree to the website tree.  The downside is that it makes  
the URLs longer as you cannot use / as the svn root but you'll have  
to use /wxWebsite and /wxWidgets as the roots or perhaps /websites  
and /sources as the roots.  That would make paths for the website  
look like /websites/trunk/wxWebsite, /websites/tags/TagName/ 
wxWebsite, and /websites/branches/BranchName/wxWebsite and paths for  
the source tree look like /sources/trunk/wxWidgets, /sources/tags/ 
TagName/wxWidgets, and /sources/branches/BranchName/wxWidgets.  That  
would actually be acceptable to me.

On top of those important layout decisions, there is the issue of  
manually copied ,v files.  When I ran it a couple of years ago the  
conversion script seemed to have trouble dealing with these.  We've  
done that a lot so I'd be somewhat concerned about what is going to  
happen with those files.  Sometimes it works, but other times the ,v  
file is much older than the directory it is in and this confuses the  
conversion script.

Anyway, I am all for converting to SVN.  I completely disagree with  
Vadim's assessment that "things seem to work now."  For me, accessing  
the CVS tree is hit and miss.  Most of the time, the speed is  
mediocre.  Occasionally, it's unbearably slow.  And on top of all  
that, CVS needs to do network access a lot more than svn which  
further exacerbates the problem.

-Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org