From 3283f9487d04d0eeda6e9f49c55cc696dac3df1f Mon Sep 17 00:00:00 2001 From: Norbert Preining Date: Tue, 13 Feb 2018 23:53:34 +0000 Subject: comment out parts of the docs on dev setup git-svn-id: svn://tug.org/texlive/trunk@46624 c570f23f-e606-0410-a88d-b1316a301751 --- Build/source/doc/tlbuild.texi | 109 ++++++++++++++++++++++-------------------- 1 file changed, 57 insertions(+), 52 deletions(-) (limited to 'Build/source') 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 -- cgit v1.2.3