On Mon, Dec 31, 2012 at 6:05 AM, Stefan Sperling <stsp_at_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
Received on 2013-01-01 03:24:22 CET