4 ms·

When FreeBSD switched from CVS to SVN, git wasn't able to handle repositories the size of the FreeBSD tree. Significant improvements have been made over the pa

When FreeBSD switched from CVS to SVN, git wasn't able to handle repositories the size of the FreeBSD tree. Significant improvements have been made over the past decade.

cnst 6y ago
Is it really the improvements, though, or is just that Git has less resistance now in 2020 than it did in 2008? DragonFly BSD has a smaller src, but it's been using Git since November 2008, converting away from CVS directly into Git, only a few months after FreeBSD moved from CVS into SVN in May 2008.
- cperciva 6y ago
  Dragonfly has a smaller tree and also a far less active one. Also, I think ports might have been a worse problem than sec -- not sure about that, just a vague memory.
- dkdk8283 6y ago
  Git has a steep learning curve especially when coming from long time svn users. At least that’s what happened to me. It took some mentorship to unfuck my brain and become acclimated to DVCS. Git is still hard to use in some circumstances.
  - lloeki 6y ago
    > Git is still hard to use in some circumstances. It's not like SVN was easy all the time either like some would like you to think. https://stackoverflow.com/questions/3941291/a-sane-way-to-rename-a-directory-in-subversion-working-copy https://stackoverflow.com/questions/3941291/a-sane-way-to-re...
    - dkdk8283 6y ago
      Sure, we color our own experiences. All different. I think commit conflicts in svn are a lot easier than git conflict resolution.
      - lloeki 6y ago
        I think you misread the issue; it's not a commit conflict. There was no second party. It's just a `svn mv` of a directory. I agree that is anecdata, yet I've had 10y of extensive experience with subversion and 10y of extensive experience with git (plus a sprinkle of cvs and rcs to boot), both used on FOSS and company contexts. I've regularly teached both to beginners ans seasoned developers alike over the years. I've had the occasion to do things with both that would make many blemish and faint. Dismissing the counterexample with "everyone's different" is a bit hard of a handwave. I stand by my assessment: subversion looks easy on the surface but is fatally flawed down to the most simple actions, to the point of being able to cause data loss.
moviuro 6y ago
It also has to do with licensing around the tool itself (git(1))[0]. FreeBSD is licensed under BSD-compatible licenses, and will avoid reliance on tools that are licensed in an incompatible way. The advent of git-compatible alternatives[1] with BSD/ISC licenses make the move easier. NB: the git format itself is not licensed, so only the tooling needs to have a "correct" license. [0] https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/COPYING is GPL2 [1] https://gameoftrees.org/ https://gameoftrees.org/
- pwdisswordfish4 6y ago
  BitKeeper has been available under Apache license for several years now. It's interesting that they didn't choose it. Not enough third-party use to justify adoption?
- cnst 6y ago
  I can't imagine that OpenBSD's got has anything to do with FreeBSD's transition. Replacing GPL'ed Git with a BSD alternative sounds interesting -- if not for anything else, then simply to combat the monoculture -- but assuming that developers are too stupid or stubborn to learn how to use a new VCS, and absolutely MUST have a `got checkout` in place of `git clone`, just because that's how CVS calls it, seems kind of silly. Of course, you can't achieve world domination if you aren't any different, but having a brand-new `checkout` command -- is that really what's missing from Git?
oblio 6y ago
I think the main barrier was the human factor. Workflows had to change and I imagine most contributors didn't want that. https://wiki.freebsd.org/GitDrawbacks https://wiki.freebsd.org/GitDrawbacks

When FreeBSD switched from CVS to SVN, git wasn't able to handle repositories the size of the FreeBSD tree. Significant improvements have been made over the past decade.

cnst 6y ago

Is it really the improvements, though, or is just that Git has less resistance now in 2020 than it did in 2008? DragonFly BSD has a smaller src, but it's been using Git since November 2008, converting away from CVS directly into Git, only a few months after FreeBSD moved from CVS into SVN in May 2008.

cperciva 6y ago
Dragonfly has a smaller tree and also a far less active one. Also, I think ports might have been a worse problem than sec -- not sure about that, just a vague memory.
dkdk8283 6y ago
Git has a steep learning curve especially when coming from long time svn users. At least that’s what happened to me. It took some mentorship to unfuck my brain and become acclimated to DVCS. Git is still hard to use in some circumstances.
- lloeki 6y ago
  > Git is still hard to use in some circumstances. It's not like SVN was easy all the time either like some would like you to think. https://stackoverflow.com/questions/3941291/a-sane-way-to-rename-a-directory-in-subversion-working-copy https://stackoverflow.com/questions/3941291/a-sane-way-to-re...
  - dkdk8283 6y ago
    Sure, we color our own experiences. All different. I think commit conflicts in svn are a lot easier than git conflict resolution.
    - lloeki 6y ago
      I think you misread the issue; it's not a commit conflict. There was no second party. It's just a `svn mv` of a directory. I agree that is anecdata, yet I've had 10y of extensive experience with subversion and 10y of extensive experience with git (plus a sprinkle of cvs and rcs to boot), both used on FOSS and company contexts. I've regularly teached both to beginners ans seasoned developers alike over the years. I've had the occasion to do things with both that would make many blemish and faint. Dismissing the counterexample with "everyone's different" is a bit hard of a handwave. I stand by my assessment: subversion looks easy on the surface but is fatally flawed down to the most simple actions, to the point of being able to cause data loss.

moviuro 6y ago

It also has to do with licensing around the tool itself (git(1))[0]. FreeBSD is licensed under BSD-compatible licenses, and will avoid reliance on tools that are licensed in an incompatible way. The advent of git-compatible alternatives[1] with BSD/ISC licenses make the move easier. NB: the git format itself is not licensed, so only the tooling needs to have a "correct" license. [0] https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/COPYING is GPL2 [1] https://gameoftrees.org/ https://gameoftrees.org/

pwdisswordfish4 6y ago
BitKeeper has been available under Apache license for several years now. It's interesting that they didn't choose it. Not enough third-party use to justify adoption?
cnst 6y ago
I can't imagine that OpenBSD's got has anything to do with FreeBSD's transition. Replacing GPL'ed Git with a BSD alternative sounds interesting -- if not for anything else, then simply to combat the monoculture -- but assuming that developers are too stupid or stubborn to learn how to use a new VCS, and absolutely MUST have a `got checkout` in place of `git clone`, just because that's how CVS calls it, seems kind of silly. Of course, you can't achieve world domination if you aren't any different, but having a brand-new `checkout` command -- is that really what's missing from Git?

oblio 6y ago

I think the main barrier was the human factor. Workflows had to change and I imagine most contributors didn't want that. https://wiki.freebsd.org/GitDrawbacks https://wiki.freebsd.org/GitDrawbacks