texlive[46624] Build/source/doc/tlbuild.texi: comment out parts of

[commits+preining at tug.org]

Revision: 46624
          http://tug.org/svn/texlive?view=revision&revision=46624
Author:   preining
Date:     2018-02-14 00:53:34 +0100 (Wed, 14 Feb 2018)
Log Message:
-----------
comment out parts of the docs on dev setup

Modified Paths:
--------------
    trunk/Build/source/doc/tlbuild.texi

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