<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 5:38 AM, Reid Spencer <span dir="ltr"><<a href="mailto:reid@reactific.com" target="_blank">reid@reactific.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Owen, and many others …<div><br></div><div>I do not wish to belabor this conversation as it distracts from everything else you all have to do. </div><div><br></div><div>The fact that llvm does have a synchronized repository on github is sufficient for me. I can fork it, hack on it, and keep it up to date as needed. If a change I make is sufficiently useful, I’ll just submit a patch. </div><div><br></div><div>The arguments about monotonically increasing revision number are, in my view, rather silly. That is not a very good reason for choosing or even staying with an SCM. There are stronger arguments for sticking with SVN.</div><div><br></div><div>The arguments about having a single line of change is valid, but SVN isn’t the only tool that supports that model. I’m in support of this approach as I use it on all my projects, including those using GIT.</div><div><br></div><div>I do understand that many automated processes are now built up around SVN and changing to git would be a huge effort with little to be gained.</div><div><br></div><div>In putting out my inquiry, I was concerned more about LLVM being sequestered off in a corner of the Internet and not having its code as easily available as on, say, github. Code access and brows ability is one of the things that fosters innovation. However, I get that switching would be a huge pain and that LLVM is by now a mature project where perhaps innovation is taking a back seat to maintaining a standard development model that its many existing developers have grown accustomed to.</div><div><br></div><div>So, let’s follow Owen’s suggestion and end the conversation about SCM choice and replace it with conversations about improving the development process. I for one will need to get back into that process before I can comment because it is clear that after 7 years, things just ain’t the same. :)</div></div></blockquote><div><br></div><div>There is definitely quite a bit of stuff that is recognized as being pretty crusty and in need of revitalization (and for all I know, you might find familiar even with 7 years of absence). Bugpoint, TableGen, the <a href="http://llvm.org">llvm.org</a> website, bugzilla, etc.</div><div><br></div><div>-- Sean Silva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Best,</div><div><br></div><div>Reid.</div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Jan 16, 2015, at 6:40 AM, Owen Anderson <<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <<a href="mailto:mle+cl@mega-nerd.com" target="_blank">mle+cl@mega-nerd.com</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">As for all the reason why the LLVM project does not use Git, I wonder</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">why large complex projects like the Linux kernel, Wine, MinGW-w64,</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">GHC and many many others don't seem to have any major problems using</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Git.</span></div></blockquote></div><br><div>Lots of projects are also happy with Mercurial, or BZR, or even CVS.</div><div><br></div><div>Every open source community has its own established workflows by which developers interact with and ultimately contribute to the mainline repository.  Those workflows, and the common use cases that lead to them, strongly impact what specific SCM arrangements will or will not work.</div><div><br></div><div>To take the Linux kernel as an example, they use a very different integration strategy from LLVM that is predicated on having a significant hierarchy of developers whose major roles are to act as integrators for incoming patches.  Obviously they use (and built!) an SCM tool that supports their workflow.</div><div><br></div><div>LLVM does *not* use such a workflow.  The outcome of several iterations of this discussion on this list has been that, for the LLVM community’s workflow, the advantages of moving mainline to git have not been seen as substantial versus our current arrangement, and it will lose some features that are useful.</div><div><br></div><div>Any re-opening of this discussion needs to address the fundamental question of how switching mainline to git will actively help the LLVM community’s development process, and whether those benefits will outweigh the downsides.</div><div><br></div><div>—Owen</div></div></div></div><span class="">_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></span></div></blockquote></div><br></div></div><br>_______________________________________________<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>
<br></blockquote></div><br></div></div>