On Mon, Dec 31, 2012 at 6:05 AM, Stefan Sperling <s...@apache.org> wrote: > You should be engaging with the llvm community > and get commit access, rather than maintaining an isolated fork.
I'll point out the irony here and I offer my apologies to Stefan if you feel that this is targeting you. While I'm replying to your comment, I'm really replying to the overall problem in the project where this workflow isn't supported. One of the reasons llvm has gotten the traction that is has it that it's not licensed with a copyleft license. Subversion is licensed with the Apache license which is also not a copyleft license. Git, Mercurial and Bazaar all are copyleft licenses. The ability to have your own local copy that you track against an upstream version is fundamentally helpful to the desired purpose of not using a copyleft license. Yet as the only major Open Source version control system[1] that isn't copyleft we don't have a good workflow for this. llvm is really intended as an infrastructure to build a compiler with or do research on compilers. It's entirely plausible to be building something on top of llvm that you want to pull in llvm code to but has no value in contributing back. Right now the best way to do what he wants is git-svn[2]. Fortunately the llvm folks have already made that relatively easy: http://llvm.org/docs/GettingStarted.html#git-mirror For those that don't want to read that link they have git mirrors for some projects and instructions on using git-svn when working with the project. As a project our attitude has always been use the tool that works. I fully support this and really have no problem with suggesting git-svn here. However, in order for Subversion to stay relevant we need to solve this problem. The obvious question I'd be asking if I was the llvm admins is why am I running git mirrors for our Subversion repositories when git has a better workflow for our licensing choices? There are a couple things to remember here: * Subversion was never intended to really break new ground when it was designed. * The other major Open Source version control systems are all distributed (which by its very nature supports this well). Despite our history I don't think we can really continue giving answers like this. We obviously realize that this sort of workflow is important since we mention in the book and point out the vendor branch workflow. As has been already pointed out well in this thread we don't need to be distributed to support this. I think it's time that we took a serious look at making branch and merging between repositories relatively easy. [1] I'm sure someone will come along and point at some other version control system I'm not thinking of, claim it is major and Open Source and isn't copyleft. You can save your breath it's not particularly important because the whole point of this post is that we need to make this easy as a project. What other projects are doing isn't particularly relevant. [2] http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
