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