7 ms·

I do find it strange that such a large project isn't using a better VCS. SVN seems to be very antiquated.

by mp3geek 10y ago

wyldfire 10y ago
It's its size that makes it difficult to move. Some major ecosystem stuff is designed around the svn infrastructure. When the will arrived to make a change, it seemed natural to migrate not just to a different VCS but a different host. And this seemed to spawn a new debate: monorepo vs multi-repo. [still open AFAIK] At the recent 2016 US Dev Conf, there was a consensus to move to git and that the new host would be github. Really subjective IMO part: In general, there's tons of really smart folks working on really awesome stuff in LLVM+clang+etc. There's a handful of folks also focusing on the general "plumbing" software within and among those projects. The meta-plumbing job of the dev infrastructure is "kinda interesting" to several folks who want to improve the way the project is developed. But "kinda interesting" doesn't pay the bills and so it's a second (or nth responsibility) for the folks volunteering to work on it. Add to that the "no good deed goes unpunished" rule that they'll get the responsibility/blame after making a sweeping change, it means it will require extreme patience and caution.
- Joky 10y ago
  Yes! Such work is all done on a volunteering basis, when we find time for it on top of the "real work" (bug fixes, features, ...). All the infrastructure work is not always rewarding, you just get the upset people yelling at you :) Current status: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109015.html http://lists.llvm.org/pipermail/llvm-dev/2017-January/109015...
Groxx 10y ago
Until semi-recently, Git[1] wouldn't let you do a shallow checkout and still do useful things. For a large project, for most purposes, downloading all of history is pointless and immensely wasteful. SVN handles that just fine, and people who want git locally can use git-svn. (edit: LLVM is surprisingly small, actually - a git clone comes in at just under 900MB. for more painful examples tho, see repos that commit(ted) binaries, or the scale of Android's repos) [1]: AFAIK Mercurial still has no built-in support, though extensions exist. Which is probably the right choice for Mercurial.
- tux3 10y ago
  >LLVM is surprisingly small, actually - a git clone comes in at just under 900MB That's a little bit on the small side, but it's still very manageable. For comparison Linux's .git folder comes in at 1.3GB on my computer, and LibreOffice's repo which has git history going back to the year 2000 weights some 3.6 GB. I can happily say that I haven't had any performance or space problem dealing with either full repos, even on my fairly weak laptop.
DannyBee 10y ago
For a project like LLVM, it just doesn't matter too much. git-svn or plain svn works pretty well for most people. Certainly it matters, and it'll move eventually, but i'd rather see time spent on better testing tools than a "better" vcs. When i moved GCC from CVS to SVN, it made life a bit easier but it's not revolutionary change. Which is funny, considering how often people argue about VCS systems.
- paulddraper 10y ago
  Not a big surprise, considering that SVN is "CVS done right". Compare that to Git's author: "Subversion has been the most pointless project ever started. There is no way to do cvs right." Git and Hg (+ the many tools that surround them: GitHub, Bitbucket, Gerrit, GitLab, etc.) have a model that makes community contribution far easier than CVS and SVN.
  - saurik 10y ago
    The community contribution concepts in git are great, but it is confusing to then mention GitHub: their modus operandi is to provide tooling to make things easier that are only hard if you insist on misusing git as if it were Subversion (by for example having a single centralized repository with multiple committers, requiring complex and annoying access control and public key management). If someone had built tooling like GitHub around Subversion and then encouraged use of svk (note the "k"; this was a replacement client for Subversion that supported offline operation and had better merging support, but which worked with any svn server), things would have felt much more reasonable before; the irony is that if you follow the actual git workflow used by Linus for Linux (where everyone has their own repository, rather than at best their own branch and at worst trying to share master), you shouldn't even need any of that for git :/.
    - paulddraper 10y ago
      > actual git workflow used by Linus for Linux When I install Linux 2.4, that centralized version comes from somewhere. I agree that svk could have made for a serviceable GitHub, but the fact that Git had such things natively supported is a big advantage.

I do find it strange that such a large project isn't using a better VCS. SVN seems to be very antiquated.

by mp3geek 10y ago

I do find it strange that such a large project isn't using a better VCS. SVN seems to be very antiquated.

It's its size that makes it difficult to move. Some major ecosystem stuff is designed around the svn infrastructure. When the will arrived to make a change, it seemed natural to migrate not just to a different VCS but a different host. And this seemed to spawn a new debate: monorepo vs multi-repo. [still open AFAIK] At the recent 2016 US Dev Conf, there was a consensus to move to git and that the new host would be github. Really subjective IMO part: In general, there's tons of really smart folks working on really awesome stuff in LLVM+clang+etc. There's a handful of folks also focusing on the general "plumbing" software within and among those projects. The meta-plumbing job of the dev infrastructure is "kinda interesting" to several folks who want to improve the way the project is developed. But "kinda interesting" doesn't pay the bills and so it's a second (or nth responsibility) for the folks volunteering to work on it. Add to that the "no good deed goes unpunished" rule that they'll get the responsibility/blame after making a sweeping change, it means it will require extreme patience and caution.

Joky 10y ago
Yes! Such work is all done on a volunteering basis, when we find time for it on top of the "real work" (bug fixes, features, ...). All the infrastructure work is not always rewarding, you just get the upset people yelling at you :) Current status: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109015.html http://lists.llvm.org/pipermail/llvm-dev/2017-January/109015...

Groxx 10y ago

Until semi-recently, Git[1] wouldn't let you do a shallow checkout and still do useful things. For a large project, for most purposes, downloading all of history is pointless and immensely wasteful. SVN handles that just fine, and people who want git locally can use git-svn. (edit: LLVM is surprisingly small, actually - a git clone comes in at just under 900MB. for more painful examples tho, see repos that commit(ted) binaries, or the scale of Android's repos) [1]: AFAIK Mercurial still has no built-in support, though extensions exist. Which is probably the right choice for Mercurial.

tux3 10y ago
>LLVM is surprisingly small, actually - a git clone comes in at just under 900MB That's a little bit on the small side, but it's still very manageable. For comparison Linux's .git folder comes in at 1.3GB on my computer, and LibreOffice's repo which has git history going back to the year 2000 weights some 3.6 GB. I can happily say that I haven't had any performance or space problem dealing with either full repos, even on my fairly weak laptop.

DannyBee 10y ago

For a project like LLVM, it just doesn't matter too much. git-svn or plain svn works pretty well for most people. Certainly it matters, and it'll move eventually, but i'd rather see time spent on better testing tools than a "better" vcs. When i moved GCC from CVS to SVN, it made life a bit easier but it's not revolutionary change. Which is funny, considering how often people argue about VCS systems.

paulddraper 10y ago
Not a big surprise, considering that SVN is "CVS done right". Compare that to Git's author: "Subversion has been the most pointless project ever started. There is no way to do cvs right." Git and Hg (+ the many tools that surround them: GitHub, Bitbucket, Gerrit, GitLab, etc.) have a model that makes community contribution far easier than CVS and SVN.
- saurik 10y ago
  The community contribution concepts in git are great, but it is confusing to then mention GitHub: their modus operandi is to provide tooling to make things easier that are only hard if you insist on misusing git as if it were Subversion (by for example having a single centralized repository with multiple committers, requiring complex and annoying access control and public key management). If someone had built tooling like GitHub around Subversion and then encouraged use of svk (note the "k"; this was a replacement client for Subversion that supported offline operation and had better merging support, but which worked with any svn server), things would have felt much more reasonable before; the irony is that if you follow the actual git workflow used by Linus for Linux (where everyone has their own repository, rather than at best their own branch and at worst trying to share master), you shouldn't even need any of that for git :/.
  - paulddraper 10y ago
    > actual git workflow used by Linus for Linux When I install Linux 2.4, that centralized version comes from somewhere. I agree that svk could have made for a serviceable GitHub, but the fact that Git had such things natively supported is a big advantage.