CVS or Subversion? (Also, hosting sites and licenses)

[jducoeur]

So I'm prepping to get the Querki project up and running -- the next couple of weeks are going to be heavily focused on laying the groundwork. I'd promised myself that I would get the project started this summer, and I'm running out of that, so it's time to deal. Which means that I need to make a lot of decisions that I've been putting off. One of these is: what do I use to do the versioning, publishing and management of this project?

The first part of this is which package I use to manage the files. There are really only two contenders here, CVS and Subversion: I'm not going to use a commercial option to manage an open-source project, and those are the two "brand name" open-source choices. I know CVS moderately well, and am familiar with its quirks and failings -- in particular, the fact that it doesn't do atomic checkins, which has annoyed me for many years. I don't know Subversion nearly as well, but it generally seems to be the choice for newer projects, so it's probably the default choice. Do folks here have experience and opinions? I'm particularly interested in hearing from people who have experience with both, about whether they see any gotchas in Subversion that might be an issue for me.

The second part is where to host the project. For something like this, using an open project host seems like a good idea -- it means I don't have to wrestle with the management, backups, and so on. SourceForge is the obvious choice, but I know there are others. Anyone have any reason to believe one of the alternatives would be superior?

Any input here would be greatly welcomed, so long as it's soon. Sometime soon (possibly as soon as late this afternoon) I'm likely to sign the project up on SourceForge under Subversion, unless I find reason to do otherwise.

Also of interest is the question of which open source license to use. If anyone has passionate opinions, I'd be interested to hear them, but I have pretty strong views on this topic myself.

Oh, and I also had better park the domain for the project -- someone's already squatted the .com version, so I think I need to claim the .org, even though it'll be some months before I'm ready to use it. Any opinions about good web hosts for parking? It's fairly likely that I'll eventually host the site out of my living room (if Comcast is allowing HTTP traffic out of my node, which I'm not sure about), so I'm mainly interested in an easy-to-deal-with site that I can put a parking page up on, and later swap away from. (Edit: actually, looking into this a little more, I suspect that simply putting the parking page on SourceForge itself may be the easiest option...)

Comments

[goldsquare.livejournal.com]

I'd go for sourceforge and subversion - but I have not the great open source mojo. :-)

I believe I can park and host on the same domain where I host my email, for a nominal fee. If you can't find something you like, why not either borrow mine, or use where you keep your family domain? At least with my host, a second domain is something like 10 dollars annually.

[jducoeur]

The family domain is with Forevermail, and my feelings about them are mixed. They do a good, uncontroversial job of forwarding our stuff, but they have a bad tendency to wind up on blacklists frequently, resulting in brief outages and bouncing until they manage to clear it up. Definitely an option, but far enough from optimal for me to be considering others...

[goldsquare.livejournal.com]

Let me know if you want to park on my stuff at pair.com, then. (With whom I have been very happy since I started, these many years ago.)

[jdulac.livejournal.com]

FWIW, I vote for SVN on Sourceforge...

I use GoDaddy for domains, even if they do have tacky advertising.

[tpau]

cvs. definitly.

i host on dreamhost and love them.

Why CVS?

[metageek.livejournal.com]

Why CVS over Subversion? The only advantage I can think of for CVS is that the code is simpler.

Re: Why CVS?

[yakshaver.livejournal.com]

I've been watching from the sidelines (instant messaging conversations among my friends at MIT whose companies are using subversion), and have the sense that when something goes wrong with subversion, the skill required to fix it is much higher than with CVS.

[keshwyn]

If you're starting a clean repository, go for SVN. We're in the progress of trying to migrate our CVS repository and it's been a moderate headache. Start cleanly if you can.

[jducoeur]

Useful to know. I do know about the hassle of porting -- my company has been contemplating SVN for a couple of years now, but the nuisance of switching from our CVS repository has been high enough to keep us from doing so. (Along with some questions about how SVN does branching, IIRC -- we branch a lot, and I seem to recall that we weren't sure we were comfortable with the SVN approach to it...)

[hascouf.livejournal.com]

I'll join the crowd and say sourceforge and subversion.

[dsrtao]

Whatever license you pick, you will pretty much need to stick with it forever for this project.

What are your goals?

[jducoeur]

Lofty, frankly. Querki is the rewrite of ProWiki into something I really *like*; given my attitudes, that means that the architecture needs to be at least *capable* of scaling to enterprise-grade, in case the project takes off. I want a project I can be proud of.

Basically, I have spec'ed out stories that would lead to it being one of the two or three most powerful wiki systems out there if they were all done. (The functionality is *different* from either MediaWiki or TWiki, since this is much more than just a wiki, but the level of ambition is similar.) I'm not at all sure that they *will* all be implemented, but I want to take this seriously and structure the project in such a way that it could possibly become a contender in the wiki space.

I have a mild personal bias *against* the GPL, which I find a tad excessive (not to mention I think it's some of the worst legal writing I've ever come across), but I probably want something stronger than, eg, the zlib license. So I'm considering things along the lines of the Mozilla license and other middle-of-the-road options...

[dsrtao]

MPL seems like a good choice, then. It's certainly respectable enough.

GPL compatibility

[metageek.livejournal.com]

Even if you don't pick the GPL, I strongly recommend picking one that's compatible with the GPL, so that, if need be, you can link in GPL code from other projects. There's just so much of it out there.

[yakshaver.livejournal.com]

Having watched a lot of people go through a lot of hair-pulling over the license for their project, here's my advice: Pick one of "popular and widely used" licenses (http://www.opensource.org/licenses/category). To some extent it doesn't matter which one, but for christ's sake don't roll your own. In addition to scaring off nine out of ten prospective paying customers, it just adds to the general confusion around open source.

[jducoeur]

Oh, yeah -- that was the plan. I know enough about law to know that writing good legal language is hard work, and I have no need to reinvent that particular wheel. It's mainly a matter of whether I go with something elaborate like the Mozilla License, or something simple like the MIT one...

[yakshaver.livejournal.com]

Wow, the Mozilla License (http://www.opensource.org/licenses/mozilla1.0.php) sure looks like it was written by a lawyer being paid by the word. The MIT and BSD licenses (the current BSD license is essentially the same as the MIT license) are a lot more comprehensible, and have served well enough for some of the most significant open source projects out there. One argument I've heard friends make for the MIT/BSD license — quietly, and out of earshot of open source zealots — is that so long as you get clean paperwork from all your contributors, if there's a business case for branching and keeping the branch closed, you can do so without any legal hassles. All other things being equal, keeping your options open sure seems like a better plan to me.

[jducoeur]

Interesting, and useful to know. I actually like that particular characteristic (I like the general principle of open source, but only on a voluntary basis -- I don't care for the coercive approach of the GPL), so that's another plus for the MIT license, which was one of the favored options anyway. Thanks...

[crschmidt.livejournal.com]

Subversion.

Sourceforge bugs me -- I'd probably go with Google code, if I was doing something small, or set up SVN + Trac on my own server, if I was doing something larger.

Strong supporter of BSD-style licenses: MIT or BSD both fit my bill.

After reading http://nodaddy.com/ yesterday, I would recommend something not-godaddy, even though it's the cheapest.

Sourceforge, Savannah

[metageek.livejournal.com]

Sourceforge bugs me

There's also Savannah.

[jducoeur]

Any particular reasons for the dislike of SourceForge? That would be useful to factor in...

[crschmidt.livejournal.com]

The download/release management system is horribly complex/convoluted.
The project approval time is long.
The code for SourceForge is not open source: despite being GPL, there have been modifications made to it which are not publicly available.
The environment is not particularly developer friendly: it's hard to use, tends to be slow, and sourceforge itself is run, so far as I can tell, as a commercial business, which means you suffer under things like ads on your mailing lists.
Oh, and if you want mailing lists, the sourceforge archives are practically unusable due to both speed and have a serious lack of google-fu compared to standard mailman archives because of all the extra crap in the page.

[jducoeur]

Innnteresting. Okay -- while I'm still going to consider them, these are all good reasons to take a serious look at the competition as well. Thanks!

I've used them both, and I say subversion

[metageek.livejournal.com]

I've used both CVS and Subversion—in fact, I've transitioned from one to the other, at Endeca—and Subversion was much better. Renames, atomic checkins, typed files, listing the contents of the directory without checking it all out, cleaner branching...it was a joy.

I still run CVS on my home box, but that's just from inertia. I can live with it when I'm the only one checking into the repository; but, if I were starting a new repository, or especially a new project where other people would be working, I would go for Subversion without a second thought.

Re: I've used them both, and I say subversion

[jducoeur]

Okay, useful to know. That had been my impression, but I want to make sure I go into this with my eyes open...

Parking

[metageek.livejournal.com]

Strictly speaking, you don't need a web host for parking; you just need DNS service. I'd be willing to add you to my DNS servers until you need actual web hosting.

Re: Parking

[jducoeur]

Interesting offer -- thank you. Let me think about whether I want to simply host it at SourceForge or wherever I keep the project repository; if not, I may well take you up on that...

[mneme]

Subversion does have some irritations (branching being optimized for trees, not files is a biggie, though cheap copies make this less problematic than it might be).

I'm tolk that SVK (as a frontend to svn) papers over a lot of the interface issues with Subversion, so you might want to try using Subversion and using SVK as the primary client.

Branching trees

[metageek.livejournal.com]

Subversion does have some irritations (branching being optimized for trees, not files is a biggie

Yeah, but that turns out to be a win when some branches have a particular file and others don't—CVS doesn't deal cleanly with that case.

Re: Branching trees

[mneme]

Oh, sure -- there are -many- ways the subversion "branch by copy" approach is strong. But the proliferation of empty branches the Subversion approach encourages can be cumbersome (because among other things, as little space as they take in the repository, they mean you can't simply check out the branches tree, but have to know which branch you need) -- though I think some of the better front-end tools can help deal with that.

Re: Branching trees

[metageek.livejournal.com]

I'll take your word for it—I haven't run into that problem myself. I will, however, point out that CVS also requires you to know which branch you need; there's no such thing as the branches tree.

Re: Branching trees

[mneme]

Well, sort of. In CVS, you can look at the file you want to get a branch on and see what branches have been made on it. In Subversion, you have to know which branch you need (unless you really want to check out -all- branches...which isn't a good idea on a decent-sized project) from among the branches that have been made on the project, rather than those made on the file.

Of course, some of this is cultural -- there's nothing stopping someone from coming up with a structure for single-file branches in subversion. And in general, Subversion's still superior. But the fact that branches are really second-class operations in Subversion (deriving from the way copying and merging works, rather than having its own defined existence) does have some consequences.

[jducoeur]

Okay, cool -- I'll take a look at SVK. Thanks!

[mindways]

I vastly prefer Subversion to CVS. Admittedly, I've only used CVS for one major project - but part of that is because it annoyed me so much that one time that I've had minimal desire to ever work with it again.

I've been using Subversion for close to 2 years at work now. There are some things it doesn't handle on its own (eg, keeping prima facie knowledge about which revisions from branch A have been merged into branch B), and there are some things which are done in slightly non-obvious ways, but for the most part I'm quite happy with it.