<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>