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

Bryan Petty bryan at ibaku.net
Sun May 27 22:16:35 PDT 2007


On 5/26/07, David Elliott <dfe at cox.net> wrote:
>
> On May 26, 2007, at 12:45 AM, Robin Dunn wrote:
>
> > 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."

As wxWebSite and wxWidgets are modules in CVS, I don't see why it
wouldn't be natural to make these as separate repositories in SVN. I'm
quite used to the convention of having the 'trunk', 'branches', and
'tags' folders in the repository's root directly, and this is the
layout that I've seen most open source projects use. It's less
confusing to new users if they are familiar with this tradition.
Anyway, separate repositories would basically lay out the folders in
exactly the same way you're suggesting.

As Vaclav pointed out, all of this can be moved around after a
conversion fairly easily without losing history.

There's something more important that I think needs to be discussed
though that hasn't been brought up yet: Do we really want to move to
SVN, or should we consider the possibility of using a distributed SCM
instead?

I'm a huge fan of SVN, and would be extremely grateful for the ability
to use TortoiseSVN with wxWidgets where I need to do any work, but as
this is an open source project, it could benefit immensely from a
distributed SCM. I've done a lot of research into this a couple weeks
ago actually since I had recently watched the Google Tech Talk about
git with Linus Torvalds [1] released back on May 3rd. Being that Linus
is basically a "patch wrangler", I trust that he knows what he's
talking about when it comes to source code management, especially with
open source projects.

[1] http://www.youtube.com/watch?v=4XpnKHJAok8

I'm not saying that wxWidgets should use git. In fact, this just won't
be possible since git has very little support on Windows (one of the
"features" that Linus loves so much about it). However, as Linus
mentions in the video, Mercurial is the next best distributed SCM in
regards to performance, disk space usage, and overall features. In my
opinion, it's the SCM wxWidgets should use if we want to use a
distributed system.

I'm probably shooting myself in the foot here since I really wish
wxWidgets would use SVN, but I'm just tossing this out there for the
good of the project.

Though if wxWidgets were to move to a distributed system, we should
expect to run into a number of hiccups with it being such a
significantly different system from what everyone here is used to
working with, whereas SVN is probably something most of us are more
familiar with.

Regards,
Bryan Petty

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





More information about the wx-discuss mailing list