comment out parts of the docs on dev setup

git-svn-id: svn://tug.org/texlive/trunk@46624 c570f23f-e606-0410-a88d-b1316a301751

1 files changed, 57 insertions, 52 deletions

diff --git a/Build/source/doc/tlbuild.texi b/Build/source/doc/tlbuild.texi
index c52537fb985..8c96b27667f 100644
--- a/Build/source/doc/tlbuild.texi
+++ b/Build/source/doc/tlbuild.texi
@@ -2563,58 +2563,63 @@ In case changes have been pushed during the cron job mentioned above,
 Travis-CI will automatically checkout the last pushed commit and try
 building it.
 
-@subheading Developer setup for Git/Subversion
-
-In case a developer of code in the @TL{} source code wants to use the CI
-testing facility, the following steps are necessary for initialization:
-
-@itemize @bullet
-@item
-Initial @code{git-svn} checkout as laid out above, replacing
-@code{USER} with the Subversion user name. This initial checkout might
-take quite some time as the whole history has to be parsed. In case the
-checkout is interrupted, change into the already created folder and call
-@code{git svn fetch} to continue pulling from the remote until all
-changes have been fetched.
-
-@item
-Adding the Git remote as laid out above. After that it is also necessary
-to set the upstream for the @code{master} branch with
-@code{git branch --set-upstream-to=origin/master master} followed by a
-@code{git pull}. The last command will probably not fetch anything since
-but update the local information about availability.
-
-@end itemize
-
-After this development can be done as follows:
-
-@itemize @bullet
-@item
-Create a new branch based on @code{master}: @code{git checkout -b feature}
-and develop the new features in this branch.
-
-@item
-Pushing the branch to Github will kick of automatic CI testing on this
-branch, too.
-
-@item
-When the feature is ready, first the branch @code{feature} needs to be
-rebased onto current @code{master} with @code{git rebase master}, then
-merged into @code{master}, followed by a submission to the Subversion
-repository via @code{git svn dcommit}. Don't push to master on Github
-(it is anyway protected), your changes will come in in due time via a
-pull on master.
-
-@item
-After the branch is included in master, optionally delete the local and
-rmeote branch @code{feature}.
-
-@end itemize
-
-The above method is the standards and safest method, but there is an
-alternative way by first pulling from Github, and then tricking git-svn
-into believing that everything has been fetched from Subversion
-already. This alternative method is explained XXXXXXXXX (my BLOG?)
+@comment
+@comment The following needs improvement
+@comment
+@comment @subheading Developer setup for Git/Subversion
+@comment 
+@comment In case a developer of code in the @TL{} source code wants to use the CI
+@comment testing facility, the following steps are necessary for initialization:
+@comment 
+@comment @itemize @bullet
+@comment @item
+@comment Initial @code{git-svn} checkout as laid out above, replacing
+@comment @code{USER} with the Subversion user name. This initial checkout might
+@comment take quite some time as the whole history has to be parsed. In case the
+@comment checkout is interrupted, change into the already created folder and call
+@comment @code{git svn fetch} to continue pulling from the remote until all
+@comment changes have been fetched.
+@comment 
+@comment @item
+@comment Adding the Git remote as laid out above. After that it is also necessary
+@comment to set the upstream for the @code{master} branch with
+@comment @code{git branch --set-upstream-to=origin/master master} followed by a
+@comment @code{git pull}. The last command will probably not fetch anything since
+@comment but update the local information about availability.
+@comment 
+@comment @end itemize
+@comment 
+@comment After this development can be done as follows:
+@comment 
+@comment @itemize @bullet
+@comment @item
+@comment Create a new branch based on @code{master}: @code{git checkout -b feature}
+@comment and develop the new features in this branch.
+@comment 
+@comment @item
+@comment Pushing the branch to Github will kick of automatic CI testing on this
+@comment branch, too.
+@comment 
+@comment @item
+@comment When the feature is ready, first the branch @code{feature} needs to be
+@comment rebased onto current @code{master} with @code{git rebase master}, then
+@comment merged into @code{master}, followed by a submission to the Subversion
+@comment repository via @code{git svn dcommit}. Don't push to master on Github
+@comment (it is anyway protected), your changes will come in in due time via a
+@comment pull on master.
+@comment 
+@comment @item
+@comment After the branch is included in master, optionally delete the local and
+@comment rmeote branch @code{feature}.
+@comment 
+@comment @end itemize
+@comment 
+@comment The above method is the standards and safest method, but there is an
+@comment alternative way by first pulling from Github, and then tricking git-svn
+@comment into believing that everything has been fetched from Subversion
+@comment already. This alternative method is explained XXXXXXXXX (my BLOG?)
+@comment 
+@comment 
 
 @c made from pod doc.
 @include tlbuild-incl/install-tl.texi