[LLVMdev] git Status Update?

Justin Holewinski justin.holewinski at gmail.com
Fri Sep 9 05:05:38 PDT 2011


To add to the social aspect, I can say from personal experience (as a
student/enthusiast developer) that contributing to open source projects that
use a decentralized SCM model (e.g. git) is easier than a centralized (e.g.
subversion) model.  I can create a clone on github (or local, or wherever),
commit all that I want, then send pull requests or patches to the upstream
maintainers.  With a subversion repository, I have to create a separate
local checkout for each "feature," and code sharing between them is very
difficult, not to mention if I want to transfer some changes from my laptop
to my desktop, or vice versa.  Whether this matters for LLVM or not, I do
not know.  The subversion model may make more sense for the more "corporate"
users where a completely linearized history may be preferable.  But my point
is that the barrier for entry is lower when using a decentralized repository
model for open-source developers that are familiar with both SCM models.

I know my opinion means next to nothing considering my very minor
contributions to the project (PTX back-end, for those who don't know me),
but as a student who uses LLVM on a near-daily basis, I feel that I
represent a "typical" academic user.  I work off of the git-svn bridge, and
maintain a centralized "working copy" on github to manage all of my feature
branches.  I keep it up to date with LLVM ToT, and that works, but
dcommit'ing changes back to subversion is definitely not my idea of a good
end-user experience!

I like to think of the three options in terms of the following analogy.
 Subversion is like a hand saw.  It'll cut down a tree, but requires
significant effort.  Git is like a chainsaw.  It'll make short work of a
tree by giving you lots of power, at the price of a slightly higher learning
curve (safety and all that).  Git-svn is like a circular saw.  It does its
job, but its not really what you want to be using to cut down a tree.  It
has its place, but this is not its best fit.  At the end of the day, both
the hand saw and chainsaw will get the job done quite effectively, but you
have to wonder if the chainsaw wouldn't make you more efficient.


On Fri, Sep 9, 2011 at 7:11 AM, David A. Greene <greened at obbligato.org>wrote:

> Bill Wendling <wendling at apple.com> writes:
>
> >>> It's my understanding that the upcoming new version of SVN will have
> >>> off-line commits available.
> >>
> >> Frankly, that's the least important feature git has.
> >>
> > And yet it's the first one that people point out. :-)
>
> It is?  I think you may be confusing offline operation with private
> branches.  They are not the same.
>
> Some quick searching reveals that one or two SVN developers may be
> considering developing a distributed SVN.  That would indeed be welcome
> and would alleviate a lot of issues.  Unfortunately I can't find
> anything offficialish that indicates the idea is being persued.  It also
> looks to be two years away, at least, given some rather hand-wavey
> predictions of when stuff could happen, if approved.
>
> Admittedly, this was a very quick search.  If you have pointers, that
> would be very helpful.
>
> >> Not true.  SCM support means you get to use all sorts of nice merge
> >> tools to handle the sync.  Applying patches sucks.
> >>
> > I use "svn merge -c <rev#> ..." with great efficacy. And it has a nice
> > way to resolve conflicts.
>
> You use svn merge -c in a working directory merging from one branch to
> another.  Don't confuse an SVN working directory or an SVN branch with a
> repository.
>
> > The LLVM development style is to do as much on ToT as possible with
> > little branching or mirroring needed. This seems to be at odds with
> > your development style, which is that you keep a tree of your own with
> > your changes there.
>
> It's not "my" development style.  Plenty of places do exactly this.  How
> else can an organization keep sane control over its source?
>
> > So there is then conflict. I doubt that things are going to change any
> > time soon.
>
> Too bad.
>
>                             -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110909/9e6201b9/attachment.html>


More information about the llvm-dev mailing list