<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div><br>Sent from my iPhone</div><div><br>On Sep 8, 2016, at 11:08 AM, <a href="mailto:dag@cray.com">dag@cray.com</a> wrote:<br><br></div><blockquote type="cite"><div><span>Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:</span><br><span></span><br><blockquote type="cite"><span>First, have you read this document: <a href="https://reviews.llvm.org/D24167">https://reviews.llvm.org/D24167</a> ?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>TLDR: The answer is no: you have to see it as it is today, i.e. a</span><br></blockquote><blockquote type="cite"><span>single SVN repo containing all the sub-projects, and “exports” in</span><br></blockquote><blockquote type="cite"><span>individual repositories.</span><br></blockquote><span></span><br><blockquote type="cite"><span>The same thing after: a single git repo containing all the subprojects</span><br></blockquote><blockquote type="cite"><span>side-by-side and the *same* “exports” in individual repositories.</span><br></blockquote><span></span><br><span>Sorry, I sent my earlier reply today before I intended to.</span><br><span></span><br><span>After going back and reading the proposal again, I think I understand</span><br><span>the plan.  I haven't used the SVN repository for years so I was thinking</span><br><span>in terms of git, that you'd take the existing git mirrors and combine</span><br><span>them (visa submodule or some other mechanism).  I understand now the</span><br><span>proposal is to take the SVN root and export all of that as one giant git</span><br><span>repository.  Is that correct?</span><br><div style="direction: inherit;"><br></div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Yes</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span>If so, that raises a number of questions for me that aren't directly</span><br><span>addressed in the document as far as I can see:</span><br><span></span><br><span>1. How are the individual component git mirrors going to be maintained?</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Just exactly as they are today.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><br><span>If a commit goes to the monorepository, what is going to extract the</span><br><span>relevant bits and commit them to the individual mirrors?  The document</span><br><span>notes that with a monorepository a single commit can touch multiple</span><br><span>projects (that's good!) but something has to extract the parts of that</span><br><span>commit that are relevant to each subproject and then send those parts to</span><br><span>the subproject repository. </span></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Right, but note that it is already the case today, some people are already using SVN to commit to clang and LLVM at the same time, and the same commit in SVN will result in one commit in the llvm git repo and another commit in the clang repo.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span> There are tools to do this and I think</span><br><span>git-subtree is a good candidate [disclosure: I am the git-subtree</span><br><span>maintainer] but I'm just curious what's being considered as a solution.</span><br></div></blockquote><div><br></div><div>Well we haven't decided on anything for the official mirrors. It looks like you're in a good position to help designing how subtree could help here :)</div><div>(I have a fairly good understanding of git, but very limited knowledge of subtree)</div><div>Anyway I hope will be able to put scripts in the repo so that anyone downstream can split the repo independently of official mirrors.</div><div><br></div><br><blockquote type="cite"><div><span></span><br><span>2. Is there any consideration for restructuring the directory layout?</span><br><span></span><br><span>The document has this to say about checking out multiple components:</span><br><span></span><br><blockquote type="cite"><span>**Monorepo Proposal**</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The repository contains natively the source for every sub-projects at the right</span><br></blockquote><blockquote type="cite"><span>revision, which makes this straightforward::</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><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 type="cite"><span>  cd llvm</span><br></blockquote><blockquote type="cite"><span>  git checkout $REVISION</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>As before, at this point clang, llvm, and libcxx are stored in directories</span><br></blockquote><blockquote type="cite"><span>alongside each other.</span><br></blockquote><span></span><br><span>The problem here is that for the build, clang wants to be in llvm/tools</span><br><span>and other components want to be in other places.  </span></div></blockquote><div><br></div><div>Not exactly: cmake has magic discovery when clang is in tools, but it is not a requirement. You can do (for years): cmake -DLLVM_EXTERNAL_CLANG_SOURCE_DIR=path</div><div><br></div><br><blockquote type="cite"><div><span>Should the</span><br><span>monorepository just be structured to have everything in its correct</span><br><span>place for building?  My inclination is to say "no" because it reduces</span><br><span>the visibility of the subprojects, but what are the alternatives?  There</span><br><span>are two that come to mind off the top of my head, 1) include symlinks in</span><br><span>the repository or 2) change the build so all components can live at the</span><br><span>top level.</span><br></div></blockquote><div><br></div>I'd expect a cmake shortcut cmake -DLLVM_ENABLE_PROjECTS=clang,libcxx,compiler-rt<div><blockquote type="cite"><div><span></span><br><span>I think it's important to think about these kinds of questions because</span><br><span>once a repository layout has been settled on, it's hard to change.  Yes,</span><br><span>it is relatively easy to move entire directories to new places in git,</span><br><span>but that not only would require changes to whatever entity updates the</span><br><span>subproject repositories, it's potentially a huge social issue, which are</span><br><span>typically the most difficult problems to address.  :)</span><br><span></span><br><span>3. How are the subproject repositories going to be created/migrated?</span><br><span></span><br><span>The individual subproject repositories will have to be created from</span><br><span>scratch after the monrepository is created, right?  We can't just</span><br><span>transition the existing git mirrors to the new setup, correct?  </span></div></blockquote><div><br></div><div>It depends: there are tradeof for each option and I think we need to gather community inputs to settle on one. </div><br><blockquote type="cite"><div><span>A</span><br><span>subproject repository reboot would involve some not insignificant pain</span><br><span>for downstream users because their git histories are suddenly invalid.</span><br><span>They would have to fetch a completely different repository and integrate</span><br><span>it into whatever they have.</span></div></blockquote><div><br></div>If we "reboot" the official git mirrors, I expect<br><span style="background-color: rgba(255, 255, 255, 0);">We'd provide scripts for integrating from the new monorepo on top of the existing history.</span></div><div><br></div><div>Ultimately these mirrors are "facilities" but it shouldn't be significantly harder <span style="background-color: rgba(255, 255, 255, 0);"> for downstream </span>to integrate directly from the monorepo with a bit of scripting, and I suspect this scripting is likely to be shareable and committed upstream.</div><div><br></div><div><br><blockquote type="cite"><div><span></span><br><span>If there is some way to maintain the existing git mirrors and layer new</span><br><span>monorepository commits on top of the existing history that would be</span><br><span>fantastic.  I believe it is technically possible (I might need to add</span><br><span>some enhancements to git-subtree :)) but I don't know if anyone has</span><br><span>explored this.  I would love to be told you all have the answers</span><br><span>already.  :)</span><br><span></span><br><span>Bisecting</span><br><span></span><br><span>For the multirepository proposal, the document talks about having the</span><br><span>git-bisect run script update each submodule during bisection.  I suppose</span><br><span>that will work but the bisection would only report that the failure</span><br><span>exists at a particular commit in the umbrella repository, implying a</span><br><span>bunch of different commits, one for each subproject.  It wouldn't really</span><br><span>point to a particular subproject as being the culprit, correct? </span></div></blockquote><div><br></div><div>Yes, it depends on the frequency of the update of the umbrella.</div><br><blockquote type="cite"><div><span> The</span><br><span>document even hints at this: "it is possible that one commit in the</span><br><span>umbrella repository includes multiple commits in the sub-projects"</span><br><span></span><br><span>That's what I was getting at with my submodule bisect question.  It can</span><br><span>only bisect to a granularity of "one of these subprojects at their</span><br><span>respective commits caused the problem."  With a true monorepository</span><br><span>bisect can drill down to the exact commit within a subproject or across</span><br><span>multiple subprojects if the commit touched multiple subprojects.  To me</span><br><span>this is a giant advantage of a non-submodule-based monorepository, which</span><br><span>I think is what the monorepository proposal is.</span><br><span></span><br><span>If everything I've written here is generally correct, I think the</span><br><span>monorepository will work for us, as long as each subproject repository</span><br><span>is maintained at a granularity of one subproject commit per commit to</span><br><span>the corresponding directory in the monorepository (i.e. full history is</span><br><span>maintained).</span><br><span></span><br><span>Thanks for you work on this.  This kind of work is crucially important</span><br><span>but often unrecognized and underappreciated.</span><br><span></span><br></div></blockquote><div><br></div></div><div><br></div><div>Thanks :)</div><div><br></div><div>If you have any input on parts of the document that can be made more clear, feel free to chime in in the review.</div><div><br></div><div>-- </div><div>Mehdi</div></body></html>