5 ms·
FreeBSD starts switch from CVS to Subversion
- jrockway 18y agoWhy 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?
- mark-t 18y agoThey'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.
- teamonkey 18y agoYeah, 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_software http://en.wikipedia.org/wiki/Comparison_of_revision_control_...
- nertzy 18y agoThe 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.
- cperciva 18y agoThey'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.
- Andys 18y agoWell, its still a nice upgrade from CVS. (Atomic transactions!)
- jrockway 18y agoIt's also a downgrade. No branches or tags.
- cperciva 18y agoMaybe 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.
- cperciva 18y agocould 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.
- swombat 18y agoWe 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.
- cperciva 18y agoWe 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? :-)
- gcv 18y ago
- swombat 18y agoBreaking news in 2015: FreeBSD switches to Git!