FreeBSD starts switch from CVS to Subversion | Hacker News Reader

FreeBSD starts switch from CVS to Subversion

freebsd.org

13 pointsnickb20 comments

Why Subversion? The only reason for using Subversion is that you're already using Subversion; for "new conversions" it's widely agreed that anything but Subversion is the right thing to use.

I don't want to sound cynical, but could FreeBSD be avoiding Git because Linus wrote it?

could FreeBSD be avoiding Git because Linus wrote it?

No. FreeBSD is avoiding Git because Git isn't capable of handling a project the size of FreeBSD.

As I see it, the major reasons for choosing SVN were (a) it was possible to convert FreeBSD's 14 year old, 1.8GB src repository to SVN and have things mostly work (there are a few bits which didn't convert properly, but nothing major), (b) there are SVN gurus willing to do the work necessary to fix the bits which didn't work, and (c) SVN is the most CVS-like option available.

That last part is quite important, incidentally -- there has been an experiment with using Perforce for a while, but it has been limited by the fact that FreeBSD developers want to code, not waste time learning new VCS systems. SVN looks and acts like a better version of CVS -- for a community of experienced CVS users, it's a very easy tool to learn.

We had a repository that grew to about 1.5 gig on github recently (due to hundreds of copies of SWF binaries). Neither git nor github even hinted at having any issues with large repos.

I'm down-modding the above because it sounds like FUD. Git has no issues with large repos as far as i'm aware, and based on my own experience.

We had a repository that grew to about 1.5 gig on github recently (due to hundreds of copies of SWF binaries)...

I'm guessing that you have a fairly large average file size here, so your 1.5GB Git repository contains far fewer files than FreeBSD's 1.8GB CVS repository.

That said, the strongest evidence that Git can't handle a project the size of FreeBSD comes from Linus himself in a discussion last year about KDE: '"Quite frankly, the way git works (tracking whole trees at a time, never single files), that ends up being very painful, because it's an "all or nothing" approach.' Linus' answer was that KDE should split up their repository into lots of small git repositories; that's not an option for FreeBSD.

If Linus himself doesn't think that Git works well for a unified project the size of FreeBSD or KDE, who are we to argue? :-)

That sounds reasonable, even to a Subversion-hater like me.

That said, I just took a quick look at the web-based CVS browser for the FreeBSD source repository, and I wonder if splitting the project up into a few smaller should have been considered more carefully? For example, ports go into one repository, the kernel goes in another, documentation into a third, and so on.

I'm not a FreeBSD guy, so it's easy for me to make outrageous claims, but I just wonder if inertia was in play here. Reorganizing the source repository to perhaps clarify it and also take advantage of everything git (or Mercurial, for that matter) has to offer, might have made sense. CVSup and the related toolchain will probably need substantial changes to support anything which isn't CVS anyway. In any case, could you give some supporting evidence for your statement that splitting up the repository is not an option for FreeBSD?

For example, ports go into one repository, the kernel goes in another, documentation into a third, and so on.

In fact, that's almost what FreeBSD has done for years. Until recently, there were separate src, ports, doc, www, and projects CVS repositories; the only change now is that the src repository is SVN -- the others are still CVS. As for why the kernel isn't a separate repository: FreeBSD, unlike linux, considers the kernel to be an integral part of a larger whole -- not a completely separate entity. We find that developing the kernel alongside userland utilities and libraries is a very Good Thing.

CVSup and the related toolchain will probably need substantial changes to support anything which isn't CVS anyway.

Nope. All the commits to SVN-src are being replicated to CVS-src (and will be for years to come) -- SVN is basically being used as a new way of doing CVS commits.

"If Linus himself doesn't think that Git works well for a unified project the size of FreeBSD or KDE, who are we to argue?"

Sure is a big departure from that git presentation he gave at Google were he was basically saying anyone who doesn't use git is necessarily a clueless retard.

I watched it on google video and even then he admitted that large projects need to be split. Funny part is that Mercurial is int he same boat - they also do not allow partial checkouts.

Where I work we 80Gb trees (sans history, that is) and idea of everyone syncing the whole 80Gb on all of their machines quickly kills any discussions around alternative source controls.

I'm not convinced about the perceived difficulty to learn git et al. You and the other FreeBSD developers are OS hackers. You're telling me it's hard for them to learn a dvcs in a few days? Look at all the Rails developers and users. They seem to have few problems switching to git.

I don't think that cperciva said that it is difficult to use it. It's not just because DVCS are in fashion that they must be adopted, that's his point.

I'm a happy mercurial user, but that does not make me look down on someone who uses CVS/SVN/Perforce and is okay with it.

Neither do i. And i'm not arguing that FreeBSD should adopt git or another dvcs. But the time to learn them is imo not an argument against them.

Agreed. It took me all of an hour to learn to use git. We switched our project over one Saturday morning, haven't looked back.

They're probably avoiding git because it's GPL. They're awfully picky about that sort of thing. But yes, I had the same reaction. There's bound to be some modern VCS that would be better for them.

They're probably avoiding git because it's GPL.

I wasn't involved in all of the VCS discussions, but from what I remember, the license question wasn't brought up at all -- I didn't realize until five minutes ago that SVN was Apache licensed, and we've been using CVS for many many years despite it being GPL licensed.

FreeBSD developers want to produce BSD licensed code, of course, but we're not zealots about the tools we use -- we'll use GPLed tools (e.g., CVS and GCC) if they're the best available, and we've even used commercial software (perforce) where it serves a useful purpose.

There's bound to be some modern VCS that would be better for them.

There were advocates within the FreeBSD community for each of SVN, Git, Mercurial. Really, we were all aware of the options.

Yeah, a quick look at Wiki shows that there aren't many VCS compatible with the BSD license.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_...

The license of the tools you use does not affect the license of the products you produce, so this is irrelevant.

I can use Photoshop to make a graphic, and then release that graphic as part of a BSD-licensed package without any trouble, since I own the copyright on that graphic.

Well, its still a nice upgrade from CVS.

(Atomic transactions!)

It's also a downgrade. No branches or tags.

Maybe you have a different definition of "branches or tags", but in the new SVN repository we have separate "head", "stable/7", "stable/6", "releng/7.0", "release/7.0.0", etc. trees -- so whether SVN calls them "branches" or not, we have the same functionality with respect to stable and release branches as we had with CVS.

Breaking news in 2015: FreeBSD switches to Git!

Reply on news.ycombinator.com