<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">I was thinking we'd merge the repos together (as in the second suggestion in the document). However maybe that breaks bisection? Haven't thought it through, but I guess I assumed they'd be preserved somehow. </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">One way to preserve hashes would be to merge each hash into the monorepo in commit order. The monorepo wouldn't have a linear history, but the hashes would stay valid. Seems flawed though...</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">(If preserving hashes isn't practical anyway, then preserving revisions is obvious goodness. But "hashes not preserved" should go down as a concern about monorepo.)</div><div style="direction: inherit;"><br></div>-- dpnes</div><div><br>On Oct 12, 2016, at 07:32, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>How do you preserve hashes in the monorepo?<br><br>Sent from my iPhone</div><div><br>On Oct 12, 2016, at 6:03 AM, Duncan Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><div style="direction: inherit;">I find the idea of rewriting the history really scary. I'd rather keep the same git commit hashes as the current read only mirrors somehow (and have the revision numbers in the git svn ids). Probably contentious but worth mentioning?</div><div style="direction: inherit;"><br></div>-- dpnes</div><div><br>On Oct 12, 2016, at 00:27, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hey,</span><br><span></span><br><span>Thanks, I’m still working on incorporating your comments.</span><br><span></span><br><span>Just wanted to share something: Chandler pointed to me a possibility in the implementation of the monorepo that is worth spelling out in the document.</span><br><span></span><br><span>We can add “padding empty commits” in the history and guarantee that the new revision number (SVN revision when checking out the GitHub SVN bridge, or the `git rev-list HEAD —count`) matches exactly the existing SVN revision.</span><br><span>This would allow:</span><br><span></span><br><span>1) To preserve the reference of all the bugzilla entries (fixed in r12345).</span><br><span>2) For a downstream integrator that rely on the current revision number from SVN to not being disrupted by overlapping revisions (new ToT rev # would be lower than current).</span><br><span></span><br><span>— </span><br><span>Mehdi</span><br><span></span><br><span></span><br><blockquote type="cite"><span>On Oct 11, 2016, at 11:19 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 2016-Oct-11, at 08:16, Mehdi AMINI <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mehdi_amini updated this revision to Diff 74258.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>mehdi_amini added a comment.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Try another layout: add first a description of the multirepo, then one for the monorepo, then the interleaved comparison.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://reviews.llvm.org/D24167">https://reviews.llvm.org/D24167</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Files:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>docs/Proposals/GitHubMove.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>docs/index.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><D24167.74258.patch></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I like this a lot. I think it's a good compromise to keep the workflows</span><br></blockquote><blockquote type="cite"><span>separate while inlining the rest of the sections into the main variant</span><br></blockquote><blockquote type="cite"><span>descriptions.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>A quick overview of the suggestions I've made inline:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- Structural changes to the new Multirepo/Monorepo sections, adding subtitles</span><br></blockquote><blockquote type="cite"><span> and reordering.</span><br></blockquote><blockquote type="cite"><span>- Inline "Living Downstream" (I have specific wording suggestions).</span><br></blockquote><blockquote type="cite"><span>- Major edits to the "Concerns" bullets.</span><br></blockquote><blockquote type="cite"><span>- "Xrepo Proposal" => "Xrepo Variant" or "Xrepo Sub-proposal".</span><br></blockquote><blockquote type="cite"><span>- Minor spelling/grammar changes.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This one isn't inline, but:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- s/subproject/sub-project/</span><br></blockquote><blockquote type="cite"><span> s/sub-project/subproject/</span><br></blockquote><blockquote type="cite"><span> (pick one; I saw instances of both, likely used them inconsistently in my own</span><br></blockquote><blockquote type="cite"><span> edits, and haven't gone back to make sure they're consistent)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Index: docs/index.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>===================================================================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--- docs/index.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+++ docs/index.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>@@ -517,6 +517,7 @@</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> IRC, etc).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>:doc:`Proposals/GitHubSubMod`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+:doc:`Proposals/GitHubMove`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Proposal to move from SVN/Git to GitHub.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Index: docs/Proposals/GitHubMove.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>===================================================================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--- /dev/null</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+++ docs/Proposals/GitHubMove.rst</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>@@ -0,0 +1,751 @@</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+==============================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Moving LLVM Projects to GitHub</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+==============================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Introduction</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+============</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This is a proposal to move our current revision control system from our own</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+hosted Subversion to GitHub. Below are the financial and technical arguments as</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to why we are proposing such a move and how people (and validation</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+infrastructure) will continue to work with a Git-based LLVM.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+There will be a survey pointing at this document which we'll use to gauge the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+community's reaction and, if we collectively decide to move, the time-frame. Be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+sure to make your view count.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Additionally, we will discuss this during a BoF at the next US LLVM Developer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+meeting (<a href="http://llvm.org/devmtg/2016-11/">http://llvm.org/devmtg/2016-11/</a>).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This proposal is divided into the following parts:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Outline of the reasons to move to Git and GitHub</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Description off the options</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* What examples of some workflows will look like (compared to currently)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* The proposed migration plan</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+What This Proposal is *Not* About</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+=================================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Changing the development policy.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This proposal relates only to moving the hosting of our source-code repository</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+from SVN hosted on our own servers to Git hosted on GitHub. We are not proposing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+using GitHub's issue tracker, pull-requests, or code-review.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Contributers will continue to earn commit access on demand under the Developer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Policy, except that that a GitHub account will be required instead of SVN</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+username/password-hash.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Why Git, and Why GitHub?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+========================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Why Move At All?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+----------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This discussion began because we currently host host our own Subversion server</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/host host/host/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+and Git mirror in a voluntary basis. The LLVM Foundation sponsors the server and</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/in a vol/on a vol/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+provides limited support, but there is only so much it can do.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Volunteers are not sysadmins themselves, but compiler engineers that happen</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to know a thing or two about hosting servers. We also don't have 24/7 support,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+and we sometimes wake up to see that continuous integration is broken because</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the SVN server is either down or unresponsive.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+We should take advantage of one of the services out there (GitHub, GitLab,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+BitBucket among others) that offer that same service (24/7 stability, disk</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Should "that same service" be "better service"? 24/7 (at least) sounds better.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+space, Git server, code browsing, forking facilities, etc) for free.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Why Git?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+--------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Many new coders nowadays start with Git, and a lot of people have never used</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+SVN, CVS, or anything else. Websites like GitHub have changed the landscape</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+of open source contributions, reducing the cost of first contribution and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+fostering collaboration.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Git is also the version control many LLVM developers use. Despite the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+sources being stored in a SVN server, these developers are already using Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+through the Git-SVN integration.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Git allows you to:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Commit, squash, merge, and fork locally without touching the remote server.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Maintain local branches, enabling multiple threads of development.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Collaborate on these branches (e.g. through your own fork of llvm on GitHub).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Inspect the repository history (blame, log, bisect) without Internet access.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Maintain remote forks and branches on Git hosting services and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ integrate back to the main repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+In addition, because Git seems to be replacing many OSS projects' version</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+control systems, there are many tools that are built over Git.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Future tooling may support Git first (if not only).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Why GitHub?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-----------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+GitHub, like GitLab and BitBucket, provides free code hosting for open source</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+projects. Any of these could replace the code-hosting infrastructure that we</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+have today.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+These services also have a dedicated team to monitor, migrate, improve and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+distribute the contents of the repositories depending on region and load.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+GitHub has one important advantage over GitLab and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+BitBucket: it offers read-write **SVN** access to the repository</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+(<a href="https://github.com/blog/626-announcing-svn-support">https://github.com/blog/626-announcing-svn-support</a>).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This would enable people to continue working post-migration as though our code</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+were still canonically in an SVN repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+In addition, there are already multiple LLVM mirrors on GitHub, indicating that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+part of our community has already settled there.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+On Managing Revision Numbers with Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The current SVN repository hosts all the LLVM sub-projects alongside each other.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A single revision number (e.g. r123456) thus identifies a consistent version of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+all LLVM sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Git does not use sequential integer revision number but instead uses a hash to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+identify each commit. (Linus mentioned that the lack of such revision number</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+is "the only real design mistake" in Git [TorvaldRevNum]_.)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The loss of a sequential integer revision number has been a sticking point in</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+past discussions about Git:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+- "The 'branch' I most care about is mainline, and losing the ability to say</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ 'fixed in r1234' (with some sort of monotonically increasing number) would</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ be a tragic loss." [LattnerRevNum]_</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+- "I like those results sorted by time and the chronology should be obvious, but</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ timestamps are incredibly cumbersome and make it difficult to verify that a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ given checkout matches a given set of results." [TrickRevNum]_</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+- "There is still the major regression with unreadable version numbers.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ Given the amount of Bugzilla traffic with 'Fixed in...', that's a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ non-trivial issue." [JSonnRevNum]_</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+- "Sequential IDs are important for LNT and llvmlab bisection tool." [MatthewsRevNum]_.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+However, Git can emulate this increasing revision number:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+`git rev-list --count <commit-hash>`. This identifier is unique only within a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+single branch, but this means the tuple `(num, branch-name)` uniquely identifies</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+a commit.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+We can thus use this revision number to ensure that e.g. `clang -v` reports a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+user-friendly revision number (e.g. `master-12345` or `4.0-5321`), addressing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the objections raised above with respect to this aspect of Git.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+What About Branches and Merges?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+In contrast to SVN, Git makes branching easy. Git's commit history is represented</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+as a DAG, a departure from SVN's linear history.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+However, we propose to mandate making merge commits illegal in our canonical Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Unfortunately, GitHub does not support server side hooks to enforce such a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+policy. We must rely on the community to avoid pushing merge commits.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+GitHub offers a feature called `Status Checks`: a branch protected by</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+`status checks` requires commits to be whitelisted before the push can happen.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+We could supply a pre-push hook on the client side that would run and check the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+history, before whitelisting the commit being pushed [statuschecks]_.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+However this solution would be somewhat fragile (how do you update a script</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+installed on every developer machine?) and prevents SVN access to the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+What About Commit Emails?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+We will need a new bot to send emails for each commit. This proposal leaves the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+email format unchanged besides the commit URL.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Straw Man Migration Plan</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+========================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+STEP #1 : Before The Move</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+1. Update docs to mention the move, so people are aware of what is going on.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+2. Set up a read-only version of the GitHub project, mirroring our current SVN</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+3. Add the required bots to implement the commit emails, as well as the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ umbrella repository update (if the multirepo is selected) or the read-only</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ Git views for the sub-projects (if the monorepo is selected).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+STEP #2 : Git Move</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+4. Update the buildbots to pick up updates and commits from the GitHub</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ repository. Not all bots have to migrate at this point, but it'll help</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ provide infrastructure testing.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+5. Update Phabricator to pick up commits from the GitHub repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+6. LNT and llvmlab have to be updated: they rely on unique monotonically</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ increasing integer across branch [MatthewsRevNum]_.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+7. Instruct downstream integrators to pick up commits from the GitHub</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+8. Review and prepare an update for the LLVM documentation.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Until this point nothing has changed for developers, it will just</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+boil down to a lot of work for buildbot and other infrastructure</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+owners.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Once all dependencies are cleared, and all problems have been solved:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+STEP #3: Write Access Move</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+9. Collect developers' GitHub account information, and add them to the project.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+10. Switch the SVN repository to read-only and allow pushes to the GitHub repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+11. Update the documentation.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+12. Mirror Git to SVN.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+STEP #4 : Post Move</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+13. Archive the SVN repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+14. Update links on the LLVM website pointing to viewvc/klaus/phab etc. to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ point to GitHub instead.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+One or Multiple Repositories?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+=============================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+There are two major proposals for how to structure our Git repository: The</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This is one proposal document. I think these should be called "variants"</span><br></blockquote><blockquote type="cite"><span>instead of "proposals". If you specifically dislike "variant", another option</span><br></blockquote><blockquote type="cite"><span>is "sub-proposal".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>My edits below use "variant".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+"multirepo" and the "monorepo".</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Multirepo Proposal</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This proposal consists into moving each SVN sub-projects into its own separate</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Git repository. It would mimic the existing official separate read-only Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repositories (e.g. <a href="http://llvm.org/git/compiler-rt.git">http://llvm.org/git/compiler-rt.git</a>), and make them the new</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+canonical repositories for each sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Grammar suggestions: "This variant recommends moving each LLVM sub-project to a</span><br></blockquote><blockquote type="cite"><span>separate Git repository. This mimics the existing official read-only Git</span><br></blockquote><blockquote type="cite"><span>repositories (e.g., <a href="http://llvm.org/git/compiler-rt.git">http://llvm.org/git/compiler-rt.git</a>), and creates new</span><br></blockquote><blockquote type="cite"><span>canonical repositories for each sub-project."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(or s/variant/sub-proposal/)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(I used "LLVM" instead of "SVN" to match the text in the monorepo proposal".</span><br></blockquote><blockquote type="cite"><span>I'm not sure which is better, but it should be consistent.")</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This will allow the individual subprojects to stay and live independently: a</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/stay and live independently/remain distinct/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+developer interested only by compiler-rt can checkout only this repository,</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/by/in/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+build it, and commit/push-back to the repository without checking-out any of the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+other subprojects.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Clarity/concision suggestion:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"... and commit/push-back to the repository without checking-out any of the</span><br></blockquote><blockquote type="cite"><span>other subprojects."</span><br></blockquote><blockquote type="cite"><span>=></span><br></blockquote><blockquote type="cite"><span>"... and work in isolation of the other subprojects."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A key need is to be able to check out multiple projects (i.e. lldb+llvm or</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>IIRC, lldb relies on clang, so this should be "lldb+clang+llvm".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+clang+llvm+libcxx for example) at a specific revision.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A tuple of revisions (one entry per repository) is sufficient to describe the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+state across separated Git repositories/sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I suggest: "... (one entry per repository) accurately describes the state</span><br></blockquote><blockquote type="cite"><span>across the sub-projects."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If you don't take that: s/separated/the distinct/ (or, "the separate")</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+For example, a given version of clang would be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+*<LLVM-12345, clang-5432, libcxx-123, etc.>*.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><-- Add a subtitle here: "Umbrella Repository"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To make this more convenient, a separate *umbrella* repository will be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+provided. This repository will be used for the sole purpose of understanding</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the sequence in which commits were pushed to the different repositories and to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+provide a single revision number.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This umbrella repository will be read-only and continuously updated</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to record the above tuple. The proposed form to record this is to use Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+[submodules]_, possibly along with a set of scripts to help check out a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+specific revision of the LLVM distribution.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A regular LLVM developer does not need to interact with the umbrella repository</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-- the individual repositories can be checked out independently -- but you would</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+need to use the umbrella repository to bisect multiple sub-projects at the same</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+time, or to check-out old revisions of llvm plus another sub-project at a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+consistent version.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This umbrella repository will be updated automatically by a bot (running on</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+notice from a webhook on every push, and periodically) on a per commit basis: a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+single commit in the umbrella repository would match a single commit in a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+subproject. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><-- Add a subtitle here: "Preview" (or "Multirepo Preview")</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+As a preview (disclaimer: this rough prototype, not polished and not</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+representative of the final solution), you can look at the following:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Repository: <a href="https://github.com/llvm-beanz/llvm-submodules">https://github.com/llvm-beanz/llvm-submodules</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Update bot: <a href="http://beanz-bot.com:8180/jenkins/job/submodule-update/">http://beanz-bot.com:8180/jenkins/job/submodule-update/</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Concerns</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+^^^^^^^^</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Because GitHub does not allow server-side hooks, and because there is no </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ "push timestamp" in Git, the umbrella reposioty sequence isn't totally exact:</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/reposioty/repository/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ commits from different repositories pushed around the same time can appear</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ in different orders. However, we don't expect it to be the common case or to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cause serious issues in practice.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I'd like to add a bullet here that back-references the previous one: "* Another</span><br></blockquote><blockquote type="cite"><span>option is to group commits that were pushed closely enough together in the</span><br></blockquote><blockquote type="cite"><span>umbrella repository that the bot sees the commits at the same time. However,</span><br></blockquote><blockquote type="cite"><span>this has the potential to group too many commits together, especially if the</span><br></blockquote><blockquote type="cite"><span>bot goes down and needs to catch up."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * You can't have a single cross-projects commit that would update both LLVM and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ other subprojects (something that can be achieved now). It would be possible</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ to establish a protocol whereby users add a special token to their commit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ messages that causes the umbrella repo's updater bot to group all of them</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ into a single revision.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * This proposal relies on heavier tooling. But the current prototype shows that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ it is not out-of-reach.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Submodules don't have a good reputation / are complicating the command line.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ However, in the proposed setup, a regular developer will seldom interact with</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ submodules directly, and certainly never update them.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><--- Add a bulleted list of workflows here (as links):</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Workflows</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^^^</span><br></blockquote><blockquote type="cite"><span> * __Link to multirepo workflow 1__.</span><br></blockquote><blockquote type="cite"><span> * __Link to multirepo workflow 2__.</span><br></blockquote><blockquote type="cite"><span> * ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Monorepo Proposal</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-----------------</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"Variant" or "sub-proposal", as above.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This proposal consists into moving all the LLVM sub-projects into a single Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repository. It will mimic an export of the current SVN repository: it would </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+look similar to <a href="https://github.com/llvm-project/llvm-project">https://github.com/llvm-project/llvm-project</a>, where each</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+sub-project has its own top-level directory.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Grammar suggestions: "This variant recommends moving all LLVM sub-projects to a</span><br></blockquote><blockquote type="cite"><span>single Git repository, similar to <a href="https://github.com/llvm-project/llvm-project">https://github.com/llvm-project/llvm-project</a>.</span><br></blockquote><blockquote type="cite"><span>This would mimic an export of the current SVN repository, with each sub-project</span><br></blockquote><blockquote type="cite"><span>having its own top-level directory."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(or s/variant/sub-proposal/)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think the following paragraph should be moved down a little and given a</span><br></blockquote><blockquote type="cite"><span>sub-heading. I suggest "Read/write sub-project mirrors".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the Monorepo, the existing single-subproject mirrors (e.g.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+<a href="http://llvm.org/git/compiler-rt.git">http://llvm.org/git/compiler-rt.git</a>) with git-svn read-write access would</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+continue to be maintained: developers would continue to be able to use the</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/would/could/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+existing single-subproject git repositories as they do today, with *no changes</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to workflow*. Everything (git fetch, git svn dcommit, etc.) would continue to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+work identically to how it works today.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I disagree with "identically", since the revision numbers will likely change</span><br></blockquote><blockquote type="cite"><span>(since the GitHub SVN export is unlikely to number revisions the same way that</span><br></blockquote><blockquote type="cite"><span>our current SVN repository does). I think you should weaken this slightly:</span><br></blockquote><blockquote type="cite"><span>"Git fetch, git svn dcommit, etc., would continue to work the same way they do</span><br></blockquote><blockquote type="cite"><span>today."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>With the other paragraph moved down (with a subtitle so it isn't missed), the</span><br></blockquote><blockquote type="cite"><span>following couple can be argued more directly. I feel like this is the meat of</span><br></blockquote><blockquote type="cite"><span>this variant (this is what's especially compelling about monorepo), so it's</span><br></blockquote><blockquote type="cite"><span>important to have up-front.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"Putting all sub-projects in a single checkout makes cross-project refactoring</span><br></blockquote><blockquote type="cite"><span>naturally simple. Moving code between sub-projects will always be done in a</span><br></blockquote><blockquote type="cite"><span>single commit, designing away a common source of temporary build breakage.</span><br></blockquote><blockquote type="cite"><span>Tooling based on `git grep` and `git blame` can be used natively across</span><br></blockquote><blockquote type="cite"><span>sub-projects. New sub-projects can be trivially split out for better reuse</span><br></blockquote><blockquote type="cite"><span>and/or layering (e.g., to allow libSupport and/or LIT to be used by runtimes</span><br></blockquote><blockquote type="cite"><span>without adding a dependency on LLVM)."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+There are other consequences: having all the code in a single checkout</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+imply that "git grep" works across sub-projects for instance. This can be used</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+for example to find refactoring opportunities across projects (for example</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+reusing a datastructure initially in LLDB by moving it into libSupport, or to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+decide to extract some pieces of libSupport and/or ADT to a new top-level</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+*independent* library that can be reused in libcxxabi).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Finally, having all the sources present encourages maintaining the other</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+sub-projects when changing API.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+As another example, some developers think that the division between e.g. clang</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+and clang-tools-extra is not useful. With the monorepo, we can move code around</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+as we wish and preserve history.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ I think I incorporated this part of the paragraph into the above.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the multirepo, refactoring some functions from clang to make it part of a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+utility in libSupport to share it across sub-projects wouldn't carry the history</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+of the code in the llvm repo, preventing recursively applying `git blame` for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+instance. The monorepo offers natively this ability.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ This should already be handled above as well. I removed the direct reference</span><br></blockquote><blockquote type="cite"><span>to multirepo, but I think it's quite clear.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Finally, the monorepo maintains the property of the existing SVN repository that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the sub-projects move synchronously, and a single revision number (or commit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+hash) identifies the state of the development across all projects.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><-- This is where I want to move "Read/write sub-project mirrors"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><-- Add a subtitle: "Preview" (or "Monorepo Preview")</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+As a preview (disclaimer: this rough prototype, not polished and not</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+representative of the final solution), you can look at the following:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Full Repository: <a href="https://github.com/joker-eph/llvm-project">https://github.com/joker-eph/llvm-project</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Single subproject view with *SVN write access* to the full repo:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ <a href="https://github.com/joker-eph/compiler-rt">https://github.com/joker-eph/compiler-rt</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Concerns</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+^^^^^^^^</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Some concerns have been raised that having a single repository would be a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ burden for those that have interest in only a single repository. This is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ addressed by keeping the single-subproject Git mirrors for each project just</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ as we do today. For contributors the GitHub SVN bridge allows to contribute</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ to a single sub-project the same way it is possible today (see below</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ before/after section for more details).</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"* Using the monolithic repository may be burden for those working on a</span><br></blockquote><blockquote type="cite"><span>standalone sub-project, particularly runtimes like libcxx and compiler-rt that</span><br></blockquote><blockquote type="cite"><span>don't rely on LLVM. A fresh clone of libcxx is only 15MB (vs. 1GB for the</span><br></blockquote><blockquote type="cite"><span>monorepo, and the commit rate of LLVM may cause more frequent `git push`</span><br></blockquote><blockquote type="cite"><span>collisions. Affected users can continue to use the read/write SVN mirrors</span><br></blockquote><blockquote type="cite"><span>and git-svn."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ This should link to the subtitle "Read/write sub-project mirrors".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The concern about maintain SVN should immediately follow to link the two</span><br></blockquote><blockquote type="cite"><span>bullets. I don't think "SVN disappearing" is specifically worth mentioning --</span><br></blockquote><blockquote type="cite"><span>since we're not saying that we're worried about "GitHub disappearing" either --</span><br></blockquote><blockquote type="cite"><span>so I've reworded this as a maintenance concern:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"* Preservation of the existing read/write SVN-based workflows relies on the</span><br></blockquote><blockquote type="cite"><span>GitHub SVN bridge, which is an extra dependency. Maintaining this locks us</span><br></blockquote><blockquote type="cite"><span>into GitHub and could restrict future workflow changes."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I also think we should add:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"* Not all sub-projects are used for building toolchains. In practise, www/</span><br></blockquote><blockquote type="cite"><span>and test-suite/ will probably stay out of the monorepo."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Because I check out the full repository, will I build all the projects by</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ default? Nobody will be forced to compile projects they don't want to build.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ The exact structure is TBD, but even if you use the monorepo directly, we'll</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ ensure that it's easy to set up your build to compile only a few particular</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ I think there's full consensus that this is solvable. I think you should</span><br></blockquote><blockquote type="cite"><span>move it above the new read/write section and give it a subtitle:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Building a single sub-project</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Nobody will be forced to build unnecessary projects. The exact structure</span><br></blockquote><blockquote type="cite"><span> is TBD, but making it trivial to configure builds for a single sub-project</span><br></blockquote><blockquote type="cite"><span> (or a subset of sub-projects) is a hard requirement.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I want this *before* read/write SVN access to make it structurally clear that</span><br></blockquote><blockquote type="cite"><span>"building a single sub-project" does not depend on "using SVN/git-svn".</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * The solution to ensure "zero-regression" and preserve existing workflow,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ especially for developer that want to interact with a single sub-project and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ limit the size of the clonse, relies on the SVN bridge offered by GitHub.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ We can't guarantee that GitHub will support this bridge forever, even if they</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ have announced any intention to discontinue support for it.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ This one can be cut; I replaced it with more concise wording above that</span><br></blockquote><blockquote type="cite"><span>focuses on the maintenance burden.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><--- Add a bulleted list of workflows here (as links):</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Workflows</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^^^</span><br></blockquote><blockquote type="cite"><span> * __Link to monorepo workflow 1__.</span><br></blockquote><blockquote type="cite"><span> * __Link to monorepo workflow 2__.</span><br></blockquote><blockquote type="cite"><span> * ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Multi/Mono Hybrid Variant</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-------------------------</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>You use "variant" here, and I think it's the best word to use. But for</span><br></blockquote><blockquote type="cite"><span>consistency, please change to "sub-proposal" if that's what you go with for</span><br></blockquote><blockquote type="cite"><span>multirepo and monorepo (or reconsider that choice...).</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A variant of the monorepo proposal is to group together in a single repository</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+only the projects that are *rev-locked* to LLVM (clang, lld, lldb, ...) and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+leave projects like libcxx and compiler-rt in their own individual and separate</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repositories.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I'd reword like this:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> This variant recommends moving only the LLVM sub-projects that are</span><br></blockquote><blockquote type="cite"><span> *rev-locked* to LLVM into a monorepo (clang, lld, lldb, ...), following the</span><br></blockquote><blockquote type="cite"><span> multirepo proposal for the rest. While neither variant recommends</span><br></blockquote><blockquote type="cite"><span> combining sub-projects like www/ and test-suite/ (which are completely</span><br></blockquote><blockquote type="cite"><span> standalone), this goes further and keeps sub-projects like libcxx and</span><br></blockquote><blockquote type="cite"><span> compiler-rt in their own distinct repositories.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(I added wording to clarify around test-suite/ and www/.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Concerns</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+^^^^^^^^</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Add:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> * All projects that use LIT for testing are effectively rev-locked to LLVM.</span><br></blockquote><blockquote type="cite"><span> Furthermore, some runtimes (like compiler-rt) are rev-locked with Clang.</span><br></blockquote><blockquote type="cite"><span> It's not clear where to draw the lines.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Inconvenient of both proposals together (see above concerns). </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>^ Reword: "* This has most disadvantages of multirepo and monorepo, without</span><br></blockquote><blockquote type="cite"><span>bringing many of the advantages."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ * Downstream have to upgrade to the monorepo structure, but only partially. So</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ they will keep the infrastructure to integrate the other separate</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Workflow Before/After</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+=====================</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This section goes through a few examples of workflows, intended to illustrate</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+how end-users or developers would interact with the repository for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+various use-cases.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Checkout/Clone a Single Project, without Commit Access</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+------------------------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Except the URL, nothing changes. The possibilities today are::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="http://llvm.org/svn/llvm-project/llvm/trunk">http://llvm.org/svn/llvm-project/llvm/trunk</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # or with Git</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+After the move to GitHub, you would do either::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="https://github.com/llvm-project/llvm.git">https://github.com/llvm-project/llvm.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # or using the GitHub svn native bridge</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="https://github.com/llvm-project/llvm/trunk">https://github.com/llvm-project/llvm/trunk</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The above works for both the monorepo and the multirepo, as we'll maintain the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+existing read-only views of the individual sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Checkout/Clone a Single Project, with Commit Access</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+---------------------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Currently**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # direct SVN checkout</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="https://user@llvm.org/svn/llvm-project/llvm/trunk">https://user@llvm.org/svn/llvm-project/llvm/trunk</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # or using the read-only Git view, with git-svn</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn init <a href="https://llvm.org/svn/llvm-project/llvm/trunk">https://llvm.org/svn/llvm-project/llvm/trunk</a> --username=<username></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config svn-remote.svn.fetch :refs/remotes/origin/master</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn rebase -l # -l avoids fetching ahead of the git mirror.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Commits are performed using `svn commit` or with the sequence `git commit` and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+`git svn dcommit`.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Multirepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the multirepo proposal, nothing changes but the URL, and commits can be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+performed using `svn commit` or `git commit` and `git push`::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="https://github.com/llvm/llvm.git">https://github.com/llvm/llvm.git</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # or using the GitHub svn native bridge</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="https://github.com/llvm/llvm/trunk/">https://github.com/llvm/llvm/trunk/</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Monorepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the monorepo, there are multiple possibilities to achieve this. First,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+you could just clone the full repository::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="https://github.com/llvm/llvm-projects.git">https://github.com/llvm/llvm-projects.git</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # or using the GitHub svn native bridge</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="https://github.com/llvm/llvm-projects/trunk/">https://github.com/llvm/llvm-projects/trunk/</a> llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+At this point you have every sub-project (llvm, clang, lld, lldb, ...), which</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**doesn't imply you have to build all of them**. You can still build only</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+compiler-rt for instance. In this way it's not different from someone who would</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+check out all the projects with SVN today.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+You can commit as normal using `git commit` and `git push` or `svn commit`, and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+read the history for a single project (`git log libcxx` for example).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+There are a few options to avoid checking out all the sources.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+First, you could hide the other directories using a Git sparse checkout::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config core.sparseCheckout true</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ echo /compiler-rt > .git/info/sparse-checkout</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git read-tree -mu HEAD</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The data for all sub-projects is still in your `.git` directory, but in your</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+checkout, you only see `compiler-rt`.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Before you push, you'll need to fetch and rebase (`git pull --rebase`) as</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+usual.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Note that when you fetch you'll likely pull in changes to sub-projects you don't</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+care about. If you are using spasre checkout, the files from other projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+won't appear on your disk. The only effect is that your commit hash changes.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+You can check whether the changes in the last fetch are relevant to your commit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+by running::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git log origin/master@{1}..origin/master -- libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This command can be hidden in a script so that `git llvmpush` would perform all</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+these steps, fail only if such a dependent change exists, and show immediately</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the change that prevented the push. An immediate repeat of the command would</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+(almost) certainly result in a successful push.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Note that today with SVN or git-svn, this step is not possible since the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+"rebase" implicitly happens while committing (unless a conflict occurs).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+A second option is to use svn via the GitHub svn native bridge::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="https://github.com/llvm/llvm-projects/trunk/compiler-rt">https://github.com/llvm/llvm-projects/trunk/compiler-rt</a> compiler-rt —username=...</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+This checks out only compiler-rt and provides commit access using "svn commit",</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+in the same way as it would do today.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Finally, you could use *git-svn* and one of the sub-project mirrors::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # Clone from the single read-only Git repo</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # Configure the SVN remote and initialize the svn metadata</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ $ git svn init <a href="https://github.com/joker-eph/llvm-project/trunk/llvm">https://github.com/joker-eph/llvm-project/trunk/llvm</a> —username=...</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config svn-remote.svn.fetch :refs/remotes/origin/master</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn rebase -l</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+In this case the repository contains only a single sub-project, and commits can</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+be made using `git svn dcommit`, again exactly as we do today.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Checkout/Clone Multiple Projects, with Commit Access</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+----------------------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Let's look how to assemble llvm+clang+libcxx at a given revision.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Currently**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="http://llvm.org/svn/llvm-project/llvm/trunk">http://llvm.org/svn/llvm-project/llvm/trunk</a> llvm -r $REVISION</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm/tools</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="http://llvm.org/svn/llvm-project/clang/trunk">http://llvm.org/svn/llvm-project/clang/trunk</a> clang -r $REVISION</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd ../projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ svn co <a href="http://llvm.org/svn/llvm-project/libcxx/trunk">http://llvm.org/svn/llvm-project/libcxx/trunk</a> libcxx -r $REVISION</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Or using git-svn::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/llvm.git">http://llvm.org/git/llvm.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm/</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn init <a href="https://llvm.org/svn/llvm-project/llvm/trunk">https://llvm.org/svn/llvm-project/llvm/trunk</a> --username=<username></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config svn-remote.svn.fetch :refs/remotes/origin/master</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn rebase -l</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout `git svn find-rev -B r258109`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd tools</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/clang.git">http://llvm.org/git/clang.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd clang/</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn init <a href="https://llvm.org/svn/llvm-project/clang/trunk">https://llvm.org/svn/llvm-project/clang/trunk</a> --username=<username></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config svn-remote.svn.fetch :refs/remotes/origin/master</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn rebase -l</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout `git svn find-rev -B r258109`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd ../../projects/</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="http://llvm.org/git/libcxx.git">http://llvm.org/git/libcxx.git</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn init <a href="https://llvm.org/svn/llvm-project/libcxx/trunk">https://llvm.org/svn/llvm-project/libcxx/trunk</a> --username=<username></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git config svn-remote.svn.fetch :refs/remotes/origin/master</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git svn rebase -l</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout `git svn find-rev -B r258109`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Note that the list would be longer with more sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Multirepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the multirepo proposal, the umbrella repository will be used. This is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+where the mapping from a single revision number to the individual repositories</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+revisions is stored.::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="https://github.com/llvm-beanz/llvm-submodules">https://github.com/llvm-beanz/llvm-submodules</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm-submodules</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout $REVISION</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git submodule init</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git submodule update clang llvm libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # the list of subproject is optional, `git submodule update` would get them all.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+At this point the clang, llvm, and libcxx individual repositories are cloned</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+and stored alongside each other. There are CMake flags to describe the directory</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+structure; alternatively, you can just symlink `clang` to `llvm/tools/clang`,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+etc.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Another option is to checkout repositories based on the commit timestamp::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout `git rev-list -n 1 --before="2009-07-27 13:37" master`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Monorepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The repository contains natively the source for every sub-projects at the right</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+revision, which makes this straightforward::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git clone <a href="https://github.com/llvm/llvm-projects.git">https://github.com/llvm/llvm-projects.git</a> llvm-projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd llvm-projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout $REVISION</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+As before, at this point clang, llvm, and libcxx are stored in directories</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+alongside each other.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Commit an API Change in LLVM and Update the Sub-projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+--------------------------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Today this is possible, even though not common (at least not documented) for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+subversion users and for git-svn users. Few Git users try to e.g. update LLD or</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Clang in the same commit as they change an LLVM API.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The multirepo proposal does not address this: one would have to commit and push</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+separately in every individual repository. It would be possible to establish a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+protocol whereby users add a special token to their commit messages that causes</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the umbrella repo's updater bot to group all of them into a single revision.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The monorepo proposal handles this natively.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Branching/Stashing/Updating for Local Development or Experiments</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+----------------------------------------------------------------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Currently**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+SVN does not allow this use case, but developers that are currently using</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+git-svn can do it. Let's look in practice what it means when dealing with</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+multiple sub-projects.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To update the repository to tip of trunk::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git pull</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd tools/clang</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git pull</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd ../../projects/libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git pull</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To create a new branch::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout -b MyBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd tools/clang</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout -b MyBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd ../../projects/libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout -b MyBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To switch branches::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout AnotherBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd tools/clang</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout AnotherBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd ../../projects/libcxx</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout AnotherBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Multirepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The multirepo works the same as the current Git workflow: every command needs</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to be applied to each of the individual repositories.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+However, the umbrella repository makes this easy using `git submodule foreach`</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to replicate a command on all the individual repositories (or submodules</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+in this case):</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To create a new branch::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git submodule foreach git checkout -b MyBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To switch branches::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git submodule foreach git checkout AnotherBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Monorepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Regular Git commands are sufficient, because everything is in a single</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+repository:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To update the repository to tip of trunk::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git pull</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To create a new branch::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout -b MyBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+To switch branches::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git checkout AnotherBranch</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Bisecting</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+---------</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Assuming a developer is looking for a bug in clang (or lld, or lldb, ...).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Currently**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+SVN does not have builtin bisection support, but the single revision across</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+sub-projects makes it possible to script around.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Using the existing Git read-only view of the repositories, it is possible to use</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the native Git bisection script over the llvm repository, and use some scripting</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+to synchronize the clang repository to match the llvm revision.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Multirepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the multi-repositories proposal, the cross-repository synchronization is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+achieved using the umbrella repository. This repository contains only</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+submodules for the other sub-projects. The native Git bisection can be used on</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the umbrella repository directly. A subtlety is that the bisect script itself</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+needs to make sure the submodules are updated accordingly.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+For example, to find which commit introduces a regression where clang-3.9</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+crashes but not clang-3.8 passes, one should be able to simply do::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git bisect start release_39 release_38</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git bisect run ./bisect_script.sh</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the `bisect_script.sh` script being::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ #!/bin/sh</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd $UMBRELLA_DIRECTORY</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git submodule update llvm clang libcxx #....</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd $BUILD_DIR</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ ninja clang || exit 125 # an exit code of 125 asks "git bisect"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # to "skip" the current commit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ ./bin/clang some_crash_test.cpp</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+When the `git bisect run` command returns, the umbrella repository is set to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the state where the regression is introduced. The commit diff in the umbrella</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+indicate which submodule was updated, and the last commit in this subprojects is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the one that the bisect found.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+**Monorepo Proposal**</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Bisecting on the monorepo is straightforward, and very similar to the above,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+expect that the bisection script does not need to include the</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s/expect/except/</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+`git submodule update` step.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+The same example, finding which commit introduces a regression where clang-3.9</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+crashes but not clang-3.8 passes, will look like::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git bisect start release_39 release_38</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ git bisect run ./bisect_script.sh</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+With the `bisect_script.sh` script being::</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ #!/bin/sh</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ cd $BUILD_DIR</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ ninja clang || exit 125 # an exit code of 125 asks "git bisect"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ # to "skip" the current commit</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ ./bin/clang some_crash_test.cpp</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Since this is almost duplicated (and an implementation detail), it would be</span><br></blockquote><blockquote type="cite"><span>nice to separate to an appendix. If you don't think there's a clear way to</span><br></blockquote><blockquote type="cite"><span>do that I'm fine as is.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Also, since the monorepo handles commits update across multiple projects, you're</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+less like to encounter a build failure where a commit change an API in LLVM and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+another later one "fixes" the build in clang.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Living Downstream</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+-----------------</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think this should be split up between multirepo and monorepo ("inlined" into</span><br></blockquote><blockquote type="cite"><span>the variants, specifically before the "Preview" subtitle).</span><br></blockquote><blockquote type="cite"><span>- As written, it's still hard to see what applies to multirepo and what to</span><br></blockquote><blockquote type="cite"><span> monorepo.</span><br></blockquote><blockquote type="cite"><span>- There's a fairly long monorepo-only section.</span><br></blockquote><blockquote type="cite"><span>- I think there should be a matching multirepo-only section.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Here's my recommendation:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Multirepo Variant</span><br></blockquote><blockquote type="cite"><span> -----------------</span><br></blockquote><blockquote type="cite"><span> ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Living Downstream</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^^^^^^^^^^^</span><br></blockquote><blockquote type="cite"><span> Downstream SVN users can use the read/write SVN bridges with the following</span><br></blockquote><blockquote type="cite"><span> caveats:</span><br></blockquote><blockquote type="cite"><span> * Be prepared for a one-time change to the upstream revision numbers.</span><br></blockquote><blockquote type="cite"><span> * The upstream sub-project revision numbers will no longer be in sync.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Downstream Git users can continue without any major changes, with the minor</span><br></blockquote><blockquote type="cite"><span> change of upstreaming using `git push` instead of `git svn dcommit`.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Git users also have the option of adopting an umbrella repository</span><br></blockquote><blockquote type="cite"><span> downstream. The tooling for the upstream umbrella can easily be reused for</span><br></blockquote><blockquote type="cite"><span> downstream needs, incorporating extra sub-projects and branching in</span><br></blockquote><blockquote type="cite"><span> parallel with sub-project branches.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Preview</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^</span><br></blockquote><blockquote type="cite"><span> ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Monorepo Variant</span><br></blockquote><blockquote type="cite"><span> -----------------</span><br></blockquote><blockquote type="cite"><span> ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Living Downstream</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^^^^^^^^^^^</span><br></blockquote><blockquote type="cite"><span> Downstream SVN users can use the read/write SVN bridge with the following</span><br></blockquote><blockquote type="cite"><span> caveat:</span><br></blockquote><blockquote type="cite"><span> * Be prepared for a one-time change to the upstream revision numbers.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Downstream Git users can continue without any major changes, by using the</span><br></blockquote><blockquote type="cite"><span> git-svn mirrors on top of the SVN bridge.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Git users can also work upstream with monorepo even if their downstream</span><br></blockquote><blockquote type="cite"><span> fork has split repositories. They can apply patches in the appropriate</span><br></blockquote><blockquote type="cite"><span> subdirectories of the monorepo using, e.g., `git am --directory=...`, or</span><br></blockquote><blockquote type="cite"><span> plain `diff` and `patch`.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Alternatively, Git users can migrate their own fork to the monorepo. As a</span><br></blockquote><blockquote type="cite"><span> demonstration, we've migrated the "CHERI" fork to the monorepo in two ways:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> * Using a script that rewrites history (including merges) so that it looks</span><br></blockquote><blockquote type="cite"><span> like the fork always lived in the monorepo [LebarCHERI]_. The upside of</span><br></blockquote><blockquote type="cite"><span> this is when you check out an old revision, you get a copy of all llvm</span><br></blockquote><blockquote type="cite"><span> sub-projects at a consistent revision. (For instance, if it's a clang</span><br></blockquote><blockquote type="cite"><span> fork, when you check out an old revision you'll get a consistent version</span><br></blockquote><blockquote type="cite"><span> of llvm proper.) The downside is that this changes the fork's commit</span><br></blockquote><blockquote type="cite"><span> hashes.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> * Merging the fork into the monorepo [AminiCHERI]_. This preserves the</span><br></blockquote><blockquote type="cite"><span> fork's commit hashes, but when you check out an old commit you only get</span><br></blockquote><blockquote type="cite"><span> the one sub-project.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Preview</span><br></blockquote><blockquote type="cite"><span> ^^^^^^^</span><br></blockquote><blockquote type="cite"><span> ...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Depending on which of the multirepo or the monorepo proposal gets accepted,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+and depending on the integration scheme, downstream projects may be differently</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+impacted and have different options.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* If you were pulling from the SVN repo before the switch to Git. The monorepo</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ will allow you to continue to use SVN the same way. The main caveat is that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ you'll need to be prepared for a one-time change to the revision numbers.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ The multirepo proposal still offers an SVN access to each individual</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ sub-project, but the SVN revision for each sub-project won't be synchronized.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* If you were pulling from one of the existing read-only Git repos, this also</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ will continue to work as before as they will continue to exist in both of the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ proposals.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+Under the monorepo proposal, you have a third option: migrating your fork to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the monorepo. If your fork touches multiple LLVM projects, migrating your fork</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+into the mono repo would enable you to make commits that touch multiple projects</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+at the same time the same way LLVM contributors would be able to do so.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+As a demonstration, we've migrated the "CHERI" fork to the monorepo in two ways:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Using a script that rewrites history (including merges) so that it looks like</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ the fork always lived in the monorepo [LebarCHERI]_. The upside of this is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ when you check out an old revision, you get a copy of all llvm sub-projects at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ a consistent revision. (For instance, if it's a clang fork, when you check</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ out an old revision you'll get a consistent version of llvm proper.) The</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ downside is that this changes the fork's commit hashes.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+* Merging the fork into the monorepo [AminiCHERI]_. This preserves the fork's</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ commit hashes, but when you check out an old commit you only get the one</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+ sub-project.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+If you keep a split-repository solution downstream, upstreaming patches to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+the monorepo is always possible (the splitrepo is obvious): you can apply the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+patches in the appropriate subdirectory of the monorepo (using either</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+`git am --directory=...` or plain `diff` and `patch`).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+References</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+==========</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [LattnerRevNum] Chris Lattner, <a href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041739.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041739.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [TrickRevNum] Andrew Trick, <a href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041721.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041721.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [JSonnRevNum] Joerg Sonnenberg, <a href="http://lists.llvm.org/pipermail/llvm-dev/2011-July/041688.html">http://lists.llvm.org/pipermail/llvm-dev/2011-July/041688.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [TorvaldRevNum] Linus Torvald, <a href="http://git.661346.n2.nabble.com/Git-commit-generation-numbers-td6584414.html">http://git.661346.n2.nabble.com/Git-commit-generation-numbers-td6584414.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [MatthewsRevNum] Chris Matthews, <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html">http://lists.llvm.org/pipermail/cfe-dev/2016-July/049886.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [submodules] Git submodules, <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a>)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [statuschecks] GitHub status-checks, <a href="https://help.github.com/articles/about-required-status-checks/">https://help.github.com/articles/about-required-status-checks/</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [LebarCHERI] Port *CHERI* to a single repository rewriting history, <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102787.html">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102787.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>+.. [AminiCHERI] Port *CHERI* to a single repository preserving history, <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102804.html">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102804.html</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br></div></blockquote></div></blockquote></div></blockquote></body></html>