<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 4:04 PM NAKAMURA Takumi <<a href="mailto:geek4civic@gmail.com">geek4civic@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Hello, David.</div><div dir="ltr"><br></div><div dir="ltr">On Sat, Nov 17, 2018 at 7:46 AM David Jones via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi James,</div><div><br></div>I've started working with the prototype layout in context of Google's internal infrastructure. With deep apologies, I have a (very late, I know) pair of requests that have only recently solidified for me.</div><div dir="ltr"><br></div><div dir="ltr">1. Could you add annotated tags after the cut point of each release? (I think this would probably be easy.)</div></div></div></div></div></div></div></blockquote><div><br></div><div>I suppose the monorepo has annotated tags.</div><div><br></div><div><div>$ git describe RELEASE_701/rc1^</div><div>RELEASE_700/final-20-gd0540f76dd4f</div></div><div><br></div><div>$ git show RELEASE_700/final<br></div><div><div>tag RELEASE_700/final</div><div>Tagger: Hans Wennborg <<a href="mailto:hans@hanshq.net" target="_blank" class="cremed">hans@hanshq.net</a>></div><div>Date: Mon Sep 17 20:38:10 2018</div><div><br></div><div>Creating release candidate final from release_700 branch</div></div><div><br></div><div>...Are they not what you want?</div></div></div></blockquote><div><br></div><div>No, I want git-describe to be usable on master. (Your example describes a change to the release branch.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">2. Could you mark branch/tag operations somehow other than a annotated tag on master? (This seems less trivial, but my reasoning is below.)<br><div><br></div><div><br></div><div>The overall goal is for `git describe` to give a reasonable default output.<br></div><div><br></div><div><br></div><div>Reasoning for request #1:</div><div><br></div><div>Example: add a tag after the cut point of the 7.0 release:</div><div><br></div><div><div>$ git log --oneline $(git merge-base HEAD origin/release_70)..HEAD | tail -1</div><div>63297479398 Bump the trunk version to 8.0.0svn</div></div><div>$ git tag -m 'Begin development of 8.0.0.' '8.0.0svn' 63297479398</div><div><br></div><div>Then, `git describe` can give a useful result that would be stable(-ish [*]):</div><div><br></div><div>$ git describe --match=\*svn<br></div><div><div>8.0.0svn-7878-gfdb08034fd8</div></div><div><br></div><div>([*] Subject to the normal caveat for git-describe: the trailing short hash may become non-unique over time. This is mentioned in the git help.)</div><div><br></div><div><div>Again, I think these tags could probably be added later, but it would be nice to have a single source of truth (especially since the tag annotation is itself a commit).</div><div><br></div><div>I think we could also probably come up with better than than '8.0.0svn'; although whatever the choice, they probably need to be suitable for --match, because...</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Interesting. It'd be better if release.sh has such a functionality.</div><div>Options I think;</div><div><br></div><div>1) Tag 700/rc0 automatically as merge base.</div><div> I think it's not smart since 8.0.0svn cannot be shown as 8.0.0 but 7.</div><div>2) Tag 8svn manually at the point of "bump to" by the release manager.</div><div> 2-1) Improve release.sh to bump version in trunk and tag it automatically.</div><div><br></div><div>Thoughts?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Reasoning for request #2:</div><div><br></div><div>Since many other branch/tag operations are stored as annotated tags, they are currently used by git-describe:</div><div><br></div><div><div>$ git describe</div><div>google/stable/2018-10-04-3473-gfdb08034fd8</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>We could just consider to remove such tags in trunk for public version of the monorepo.</div><div>(I didn't know tags/google are in trunk)</div><div><br></div><div>Thanks,</div><div>Takumi </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>This doesn't seem as generally useful to me as the release-cut based revisions... describing a commit as "the 7878th of 8.0.0 development" seems more generally helpful than saying "the 3473rd after a google/stable release."</div><div><br></div><div>A very similar approach might be to drop the existing annotated tags, and add the unchanged branches as no-change commits (i.e., the equivalent of `git commit --allow-empty`), with a lightweight tag.</div><div><br></div><div>Unfortunately, this seems (to me) to be harder to fix than #1. The "similar approach" seems like it could be added safely without recreating the entire history, but it seems like this would need to be done before folks start depending on the existing tags.</div><div><br></div><div><br></div><div><br></div><div>(Of course, it's possible I've completely missed something obvious or somehow fouled up my clone of the repo, and this is already supposed to work... let me know if I've missed something, or if you have a better approach.)</div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 1:11 PM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, I believe all the known issues are resolved and that we're ready to go, whenever the other thread (on whether to abandon this monorepo, and zipper-commit the existing gitrepositories) is concluded.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 4:09 PM Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank" class="cremed">tstellar@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/11/2018 03:27 PM, James Y Knight via llvm-dev wrote:<br>
> TLDR: <a href="https://github.com/llvm-git-prototype/" rel="noreferrer" target="_blank" class="cremed">https://github.com/llvm-git-prototype/</a> exists as a read-only mirror of SVN, and is being updated continuously with a script running on an llvm-project AWS VM.<br>
> <br>
<br>
Hi James,<br>
<br>
What is the current status of the monorepo, have you resolved all the<br>
known issues with the history? Are there any other changes that need<br>
to be made before it can be finalized?<br>
<br>
-Tom<br>
<br>
> Let me know what you think.<br>
> <br>
> I had meant to get this prototype finalized 6 months ago, and I must apologize for the delay. I hope this is close to final for what we want our git repository to look like, and that we can move forward with the remainder of the work to convert to git.<br>
> <br>
> At this point, there's no guarantee that the repository won't be rebuilt from scratch with new hashes, if some problem is discovered which requires changing something way back in history. But I hope we're now close to being able to declare a conversion final -- and let people start depending on the hashes being stable.<br>
> <br>
> This conversion uses the "flat monorepo" layout, like the previous existing git monorepo, and as discussed previously. The process generating it is different, which allows a more faithful conversion, including branches. I've also converted a bunch of the auxiliary repositories.<br>
> <br>
> I would request that other people help take charge of the remainder of the work. Most importantly -- making a plan for implementing the *rest* of the migration. We have <a href="https://llvm.org/docs/Proposals/GitHubMove.html" rel="noreferrer" target="_blank" class="cremed">https://llvm.org/docs/Proposals/GitHubMove.html</a>, but I think it'll need significant fleshing out and updating. I'm happy to assist with the rest of the migration, but I'd like to _not_ be primarily responsible for other parts beyond svn->git repository conversion.<br>
> <br>
> Some things that could be discussed in such a plan:<br>
> * Verifying that this conversion is good, what we want, and declaring it final (at which point the hashes can be relied upon not to change).<br>
> * Any particular steps wanted here?<br>
> * Converting buildbots to use git.<br>
> * Phabricator changes?<br>
> * How do email notifications get sent for commits?<br>
> * Gathering github accounts for all committers, adding them to a github team.<br>
> * Deciding upon and announcing a timeline for switching over.<br>
> * Proposing, implementing, and testing new workflows for direct git usage:<br>
> * Github pull requests instead of (or in addition to?) phabricator?<br>
> * Github Protected Branch configuration options?<br>
> * E.g. -- direct pushing to git without any restriction, or, require that pull requests be created first?<br>
> * Automated Pre-commit testing? Do we setup CI (e.g. <a href="http://travis-ci.org" rel="noreferrer" target="_blank" class="cremed">travis-ci.org</a> <<a href="http://travis-ci.org" rel="noreferrer" target="_blank" class="cremed">http://travis-ci.org</a>>) to do some testing on pull requests, to reduce avoidable tree breakages?<br>
> * Any other github configuration options that need to be decided upon?<br>
> * ....other things I forgot about at the moment...<br>
> * Timeline for switchover.<br>
> <br>
> <br>
> <br>
> Anyways, what's been done _so far_ is a full SVN->Git repository conversion. This conversion:<br>
> * Places the SVN revision number into the commit message, as "llvm-svn=1234"<br>
> <br>
> * Automatically preserves all branches from the SVN repository (it merges the branches named /$project/branches/$name into a single "$name" branch, attempting, as much as possible, to make the branch-creation commits not look insane).<br>
> <br>
> * Attempts to convert the svn branches in the "tags" subdir into annotated git tags pointing to the proper commit on the parent branch, where feasible. Sometimes this is impossible, since the "tags" have had modifications after their creation. (They're just branches in SVN, so you can do that, although you shouldn't). If so, they're preserved as a branch named "svntag/$name", instead.<br>
> <br>
> * Preserves the svn id -> email mapping that was in-use at the time of each SVN commit, as far as is known.<br>
> <br>
> * Fixes a bunch of -- but not all -- the CVS->SVN conversion errors (due, e.g., to files being renamed directly in the CVS repository).<br>
> <br>
> <br>
> <br>
> Most of the SVN directories are migrated into sub-directories inside the main "llvm" mono-repository:<br>
> * cfe (renamed to clang in the conversion)<br>
> * clang-tools-extra<br>
> * compiler-rt<br>
> * debuginfo-tests<br>
> * dragonegg (also "gcc-plugin", the original name)<br>
> * libclc<br>
> * libcxx<br>
> * libcxxabi<br>
> * libunwind<br>
> * lld<br>
> * lldb<br>
> * llgo<br>
> * llvm<br>
> * openmp<br>
> * parallel-libs<br>
> * polly<br>
> * pstl<br>
> * stacker (deleted after r40406)<br>
> (Additionally, files added to the "monorepo-root/trunk" directory in SVN end up at the root of this repository).<br>
> <br>
> Some SVN projects are still active, but not part of the LLVM codebase. These get migrated to their own separate git repositories:<br>
> * lnt<br>
> * test-suite<br>
> * www<br>
> * www-pubs<br>
> * www-releases ## TODO. Not done yet as it requires the use of git-lfs, due to large files.<br>
> * zorg<br>
> <br>
> A couple inactive projects which are somewhat related to the LLVM codebase, migrated to separate repos:<br>
> * poolalloc<br>
> * safecode<br>
> <br>
> Legacy projects that are not particularly interesting, migrated to a single separate git repository named "archive":<br>
> * clang-tests # Copy of GCC 4.2 testsuite, modified to work with clang<br>
> * clang-tests-external # Copy of GDB testsuite<br>
> * llvm-gcc-4.0 # GCC 4.0, modified for llvm<br>
> * llvm-gcc-4.2 # GCC 4.2, modified for llvm<br>
> * llvm-gcc-4-2 # (merge with above)<br>
> * java<br>
> * vmkit<br>
> * nightly-test-server<br>
> * llbrowse # An LLVM bitcode GUI browser<br>
> * television # A different LLVM GUI browser; shows effects of transforms, etc<br>
> * website # 2007-era snapshot of website, not actually maintained here.<br>
> * core, llvm-top, sample, support, hlvm # from the "HLVM" refactoring attempt.<br>
> <br>
> Projects _not_ migrated from SVN in this conversion, since they're elsewhere already:<br>
> * giri # Never actually developed here; actually <a href="https://github.com/liuml07/giri" rel="noreferrer" target="_blank" class="cremed">https://github.com/liuml07/giri</a><br>
> * klee # Already migrated to github with history; <a href="https://github.com/klee/klee" rel="noreferrer" target="_blank" class="cremed">https://github.com/klee/klee</a><br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="cremed">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="cremed">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="cremed">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>