<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/15/2015 12:13 PM, Reid Spencer
wrote:<br>
</div>
<blockquote
cite="mid:4B8AB912-BA89-4C82-A958-670DB4081933@reactific.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hello LLVMers,
<div class=""><br class="">
</div>
<div class="">It has been a while (8 years?) since I’ve been
involved with LLVM but I’m considering picking it up again. My
recent review of the code base has led me to wonder if it isn’t
time to update the code base, specifically:</div>
<div class="">
<ul class="MailOutline">
<li class="">Convert to GIT</li>
<li class="">Refactor into smaller, separate, reusable
libraries</li>
<li class="">Host the master repository at GitHub (amongst
other places)</li>
</ul>
</div>
</blockquote>
<br>
It's not clear from your suggestion if you are or are not planning
on breaking the repositories into smaller chunks (e.g., how the llvm
and clang repositories are hosted as separate git modules). If this
is indeed what you are suggesting, then the following paragraph
applies:<br>
<br>
Losing atomicity of commits in a project is a pain that you do not
want to have to suffer, speaking as a maintainer of project which is
bifurcated in two distinct repositories for the past 6 years. SVN
allows you to do partial tree checkouts, a feature which is to my
knowledge not replicated by any major DVCS. You thus get the choice
between having one monolithic repository for all projects, or making
do with non-atomic commits, and that last option is not viable given
the coupling between llvm, clang, and compiler-rt at the very least.
Separating them would subject developers to the worst kind of
development hell that can only be accurately conveyed to those who
have had the misfortune to be sentenced there. Or to those who
recall CVS or other abominations of version control. :-)<br>
<br>
<br>
Beyond that, though, my impression of GitHub is that it encourages
development models and processes which do not scale to large
projects, which llvm undoubtedly is. Its issue tracking system is
underpowered, its reviewer underwhelming, and you're prone to lose
important information if you, say, rebase pull requests (at least
the last time I checked). It's designed to encourage its particular
development model, and if you want anything that's different (say,
linear history), well, you have to fight it all the way.<br>
<br>
<blockquote
cite="mid:4B8AB912-BA89-4C82-A958-670DB4081933@reactific.com"
type="cite">
<div class="">Sorry if this topic has been covered .. the archives
are not searchable (google group, anyone?).</div>
</blockquote>
<br>
GMane:
<a class="moz-txt-link-rfc2396E" href="http://search.gmane.org/?query=github&group=gmane.comp.compilers.llvm.devel"><http://search.gmane.org/?query=github&group=gmane.comp.compilers.llvm.devel></a>.
Which is infinitely better than Google Groups.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>