[PATCH] D24167: Moving to GitHub - Unified Proposal

[Paul Robinson via llvm-commits]

probinson added a subscriber: probinson.
probinson added a comment.

Mostly typos.
Please separate the descriptions and the advocacy.


================
Comment at: docs/Proposals/GitHubMove.rst:13
@@ +12,3 @@
+
+There will be a survey pointing at this document which we'll use to gague the
+community's reaction and, if we collectively decide to move, the time-frame. Be
----------------
s/gague/gauge/

================
Comment at: docs/Proposals/GitHubMove.rst:37
@@ +36,3 @@
+Every existing contributors will get commit access on demand in the same
+condition as currently. Those who don't have an existing GitHub account will
+have to create one in order to continue having commit access.
----------------
contributors -> contributor
'in the same condition' -> 'under the same conditions'

================
Comment at: docs/Proposals/GitHubMove.rst:185
@@ +184,3 @@
+
+There are other impacts that are less immediates and less technicals: the first
+proposal of keeping the repository separate implies that the sub-projects are
----------------
immediates ... technicals -> immediate ... technical

================
Comment at: docs/Proposals/GitHubMove.rst:219
@@ +218,3 @@
+
+Under the monorepo, this is a non-issue.  That proposal maintains property of
+the existing SVN repository that the sub-projects move synchronously, and a
----------------
maintains the property

================
Comment at: docs/Proposals/GitHubMove.rst:349
@@ +348,3 @@
+change that prevented the push. An immediate repeat of the command would
+(almost) certainly result in a successed push. (This is
+an extra step that you don't need in the multirepo, but for those of us who
----------------
successed -> successful

================
Comment at: docs/Proposals/GitHubMove.rst:454
@@ +453,3 @@
+
+The single repository proposal handles this natively and makes this use case
+trivial.
----------------
single repository -> monorepo

================
Comment at: docs/Proposals/GitHubMove.rst:488
@@ +487,3 @@
+  cd ../../projects/libcxx
+  git checkout -b AnotherBranch
+
----------------
These checkouts should not have -b on them.

================
Comment at: docs/Proposals/GitHubMove.rst:519
@@ +518,3 @@
+
+SVN does not have builtin bisection support. Using the existing Git read-only
+view of the repositories, it is possible to use the native Git bisection script
----------------
SVN bisection is not built-in but it is easy to do manually (or scripted) because you can do `svn update -r $REVISION` to an arbitrary revision.  Because revisions are integers, do `(BAD - GOOD)/2` to pick the next revision.  So, it is not materially harder than bisecting on the multirepo.

================
Comment at: docs/Proposals/GitHubMove.rst:552
@@ +551,3 @@
+the state where the regression is introduced, one can inspect the history on
+every sub-projects compared to the previous revision in the umbrella (it is
+possible that one commit in the umbrella repository includes multiple commits
----------------
sub-projects -> sub-project

================
Comment at: docs/Proposals/GitHubMove.rst:573
@@ +572,3 @@
+  be prepared for a one-time change to the revision numbers. The multirepo
+  proposal does not provide a great solution for this.
+
----------------
Wouldn't the multirepo still have SVN views on each subproject? Seems like the SVN views would basically be the same for either multirepo or monorepo.

================
Comment at: docs/Proposals/GitHubMove.rst:607
@@ +606,3 @@
+leave projects like libcxx and compiler-rt in their own individual and separate
+repository.
+
----------------
repository -> repositories.



https://reviews.llvm.org/D24167