diff options
Diffstat (limited to 'doc/using-git.texi')
| -rw-r--r-- | doc/using-git.texi | 1179 |
1 files changed, 0 insertions, 1179 deletions
diff --git a/doc/using-git.texi b/doc/using-git.texi deleted file mode 100644 index 1812c153..00000000 --- a/doc/using-git.texi +++ /dev/null @@ -1,1179 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header (This is for running Texinfo on a region.) -@setfilename using-git.info -@settitle Workflow in the @command{gawk} project -@c %**end of header (This is for running Texinfo on a region.) - -@dircategory Network applications -@direntry -* Gawkworkflow: (using-git). Workflow in the `gawk' project. -@end direntry - -@iftex -@set DOCUMENT book -@set CHAPTER chapter -@set SECTION section -@set DARKCORNER @inmargin{@image{lflashlight,1cm}, @image{rflashlight,1cm}} -@end iftex -@ifinfo -@set DOCUMENT Info file -@set CHAPTER major node -@set SECTION node -@set DARKCORNER (d.c.) -@end ifinfo -@ifhtml -@set DOCUMENT web page -@set CHAPTER chapter -@set SECTION section -@set DARKCORNER (d.c.) -@end ifhtml - -@set FN file name -@set FFN File Name - -@c merge the function and variable indexes into the concept index -@ifinfo -@synindex fn cp -@synindex vr cp -@end ifinfo -@iftex -@syncodeindex fn cp -@syncodeindex vr cp -@end iftex - -@c If "finalout" is commented out, the printed output will show -@c black boxes that mark lines that are too long. Thus, it is -@c unwise to comment it out when running a master in case there are -@c overfulls which are deemed okay. - -@iftex -@finalout -@end iftex - -@smallbook - -@set TITLE Workflow in the @command{gawk} project -@set EDITION 0.0 -@set UPDATE-MONTH August, 2014 -@c gawk versions: -@set VERSION 4.1 -@set PATCHLEVEL 0 - -@copying -This is Edition @value{EDITION} of @cite{@value{TITLE}}, -for the @value{VERSION}.@value{PATCHLEVEL} (or later) version of the GNU -implementation of AWK. -@sp 2 -Copyright (C) 2014, 2015 Free Software Foundation, Inc. -@sp 2 -Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.3 or -any later version published by the Free Software Foundation; with the -Invariant Sections being ``GNU General Public License'', the Front-Cover -texts being (a) (see below), and with the Back-Cover Texts being (b) -(see below). A copy of the license is included in the section entitled -``GNU Free Documentation License''. - -@enumerate a -@item -The FSF's Back-Cover Text is: ``You have the freedom to -copy and modify this GNU manual.'' -@end enumerate -@end copying - -@ifinfo -This file documents the workflow of the developers in the GNU -@command{awk} project. - -@insertcopying -@end ifinfo - -@setchapternewpage odd - -@titlepage -@title @value{TITLE} -@subtitle Edition @value{EDITION} -@subtitle @value{UPDATE-MONTH} -@author J@"urgen Kahrs -@author with Arnold D. Robbins - -@c Include the Distribution inside the titlepage environment so -@c that headings are turned off. Headings on and off do not work. - -@page -@vskip 0pt plus 1filll -@sp 2 -Published by: -@sp 1 - -Free Software Foundation @* -51 Franklin Street, Fifth Floor @* -Boston, MA 02110-1301 USA @* -Phone: +1-617-542-5942 @* -Fax: +1-617-542-2652 @* -Email: @email{gnu@@gnu.org} @* -URL: @uref{http://www.gnu.org/} @* - -ISBN 1-882114-93-0 @* - -@insertcopying - -@c @sp 2 -@c Cover art by ?????. -@end titlepage - -@iftex -@headings off -@evenheading @thispage@ @ @ @strong{@value{TITLE}} @| @| -@oddheading @| @| @strong{@thischapter}@ @ @ @thispage -@end iftex - -@ifnottex -@node Top -@top Introduction -@comment node-name, next, previous, up - -This file documents the workflow of the developers in the GNU Awk (@command{gawk}) -version 4.1 and later. - -@insertcopying -@end ifnottex - -@menu -* Introduction:: About networking. -* Basics of GIT repositories:: The fundamental environment of - the developer. -* Conventions used in the repository:: How to behave. -* Tutorial for a first-time-gawk-contributor:: How to get started with least - pain. -* FAQs and HOWTOs:: General recipes for daily work. -* Links:: Where to find the stuff - mentioned in this document. -* GNU Free Documentation License:: The license for this document. -* Index:: The index. - -@detailmenu -* Quick Start:: -* Setting up a proper @command{git} repository:: -* Pulling the latest changes from the remote repository:: -* Checking out a feature branch from the remote repository:: -* Semantics of Cloning:: What to - consider - before you - clone. -* Local versus Remote:: Where my - source code - really is. -* Tracking and Merging:: What the - others are - doing. -* master:: -* stable:: -* feature:: -* who does what:: -* step-by-step instructions for a first-time-gawk-contributor:: -* step-by-step instructions for a first-time-gawk-administrator:: -* general recipes for daily work:: -* references and URLs to books and other texts:: -@end detailmenu -@end menu - -@contents - -@node Introduction -@chapter Introduction - -This @value{DOCUMENT} is meant to be a description of the working habits -that were established for collaboration in the GNU Awk project. -Such stuff tends to become rather dry, and to prevent you from getting -bored at this early stage, we will begin this @value{CHAPTER} with a -brief introduction that shows you how to get the -source code of the GNU Awk project compiled on your machine. - -We do this in order to get you motivated to follow us through the later -steps that consist mainly of conceptual considerations. -We hope that (in later, more abstract steps) you will always remember -this down-to-earth introduction, should you ever wonder what all the -later bizarre trickery is good for. - -@menu -* Quick Start:: -* Setting up a proper @command{git} repository:: -* Pulling the latest changes from the remote repository:: -* Checking out a feature branch from the remote repository:: -@end menu - -@node Quick Start -@section Quick Start: Compiling @command{gawk} in 5 Minutes - -The following steps will look familiar to you; they are not that much -different from the steps you used in the old days when you downloaded -a tar ball, extracted it and compiled the source code. It is mainly -the very first step that looks different; instead of downloading the -tar ball you need the tool @command{git}.@footnote{If the command -@command{git} does not exist on your machine, -you need adminstrator privileges to install it. By convention, the -command is usually part of an installation package by the same name.} - -@example -git clone git://git.savannah.gnu.org/gawk.git -cd gawk -git checkout gawk-4.1-stable -./bootstrap.sh -./configure -make -./gawk --version -@end example - -There are two differences to your working habits. In the third step,, -you have to extract (or @dfn{check out}) the @code{gawk-4.1-stable} branch of the current source -code (there are other branches available, that's the point where -things get interesting). - -In the fourth step, you must run the @command{bootstrap.sh} script in -order to set correctly timestamps on various files. Doing this is essential; -it allows you to avoid having to install the correct versions of the -various autotools as used by the @command{gawk} maintainer. - -Isn't this simple? No, it's not that simple. -If you plan to go any further (for example compile the source -code again next week, including next week's latest update), you will -need to know what's going on when you use this seemingly simple -@command{git} command (and that's the point where things get bizarre). - -In the next @value{CHAPTER} you will find a more thorough conceptual -explanation, here we are satisfied with getting to know the practical -steps necessary to get a working environment going that you can use -in your daily work in a reliable way. - -@node Setting up a proper @command{git} repository -@section Setting up a proper @command{git} repository - -After the initial @emph{checkout} you have access to all the source code -files that the maintainers have pushed through the official release procedure. - -You may not have noticed, but each change is well documented and traceable. -This process of tracing the change history is so precise, reproducable and -fine-grained that any dubious change may be kicked out later and the author -of dubious stuff identified by name and change date. - -Some bookkeeping is -necessary for this and that's why you need @command{git}. @command{git} -does all this for you. Developers who have used @command{svn} or -@command{cvs} in the past will not be surprised to hear that each change -is traceable precisely (they know that @command{svn} and @command{cvs} -can do this, too). - -But the first-time user of @command{git} (as well as the @command{svn} user) -may still have failed to notice what he actually did earlier in this @value{CHAPTER}. -It is not just a mere copy of the source code that you created, -it is a full copy of the entire @dfn{upstream} repository server that you created -(or @dfn{cloned}). This means that others could make their own copy of -@emph{your} repository and treat it as @emph{their upstream} repository. - -This is the essential difference between working with @command{svn} and -working with @command{git}: by @emph{cloning} you become a repository -administrator, whether you like it or not. As such you have some duties that -go beyond the duties of an @command{svn} user. For example, you have to -identify yourself properly as the owner of the repository by setting -some global variables identifying you. The global settings will be used -every time you connect again to the upstream repository. - -@smallexample -git config --global user.name "@var{First-Name Last-Name}" -git config --global user.email @var{email@@address.site} -git config --global color.ui auto -@end smallexample - -You may leave these variables unset, but then you are reduced to an -anonymous consumer-only behaviour whenever you connect to the upstream -repository. Later you will learn that there are many other variables -to be set, most of them serving as defaults that can be overridden if -you like. Choosing to work with defaults makes work quick and easy for the most frequent -use cases, but that comes at a cost: With so many helpful defaults -you may be overwhelmed by the detail and complexity of the real inner working. -Here is an example of one of the author's configuration variables: - -@smallexample -$ @kbd{git config --list} -@print{} user.name=First-Name Last-Name -@print{} user.email=email@@address.site -@print{} color.diff=auto -@print{} color.status=auto -@print{} color.branch=auto -@print{} gui.spellingdictionary=en_US -@print{} core.repositoryformatversion=0 -@print{} core.filemode=true -@print{} core.logallrefupdaIsn't this simple? No, it's not that simple. tes=true -@print{} remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* -@print{} remote.origin.url=ssh://jkahrs@@git.sv.gnu.org/srv/git/gawk.git -@print{} branch.master.remote=origin -@print{} branch.master.merge=refs/heads/master -@print{} branch.xgawk_load.remote=origin -@print{} branch.xgawk_load.merge=refs/heads/xgawk_load -@end smallexample - -Changing these variables with specialized variants of the @command{git} command -may seem awkward to you and perhaps you prefer to use your favourite text editor -to overview and change the variables. That's easy: edit the file @file{.git/config}. - -@smallexample -$ @kbd{cat .git/config} -@print{} [core] -@print{} repositoryformatversion = 0 -@print{} filemode = true -@print{} bare = false -@print{} logallrefupdates = true -@print{} [remote "origin"] -@print{} fetch = +refs/heads/*:refs/remotes/origin/* -@print{} url = ssh://jkahrs@@git.sv.gnu.org/srv/git/gawk.git -@print{} [branch "master"] -@print{} remote = origin -@print{} merge = refs/heads/master -@print{} [branch "cmake"] -@print{} remote = origin -@print{} merge = refs/heads/cmake -@end smallexample - -Now you can see how variables are structured group-wise. -But wait, where is the e-mail address in this list of variables? -It is missing in the file @file{.git/config} because that file -contains only the local settings of this one repository -(while there may be others on your machine). -The e-mail address is a variable of a more general kind that -should be stored above all the repositories. -These are referred to as the @dfn{global} variables: - -@smallexample -$ @kbd{git config --list --global} -@print{} user.name=First-Name Last-Name -@print{} user.email=email@@address.site -@print{} color.diff=auto -@print{} color.status=auto -@print{} color.branch=auto -@print{} gui.spellingdictionary=en_US -@end smallexample - -If you wonder whether there is a parameter @command{--local} to list -the local variables, then you should look into the well-structured -man pages of @command{git}. The level of detail may overwhelm you, -but one day you might appreciate it. - -@smallexample -git help config -@end smallexample - -@node Pulling the latest changes from the remote repository -@section Pulling the latest changes from the remote repository - -Whether you set any of these variables or not, sooner or later you will want -to catch up with the changes that happened in the upstream repository. -So, how can you update your copy of the repository and re-build the source code? -The easiest way is to rely on defaults and use the @emph{pull} command to request -updates from the upstream repository: - -@smallexample -git pull -./bootstrap.sh -./configure -make -@end smallexample - -When using the @emph{pull} command, all the changes available in all branches of -the upstream repository will be copied (and merged) into your local repository. -We assume here that we still have the @emph{gawk-4.1-stable} branch checked out (as described earlier) -and we are not interested in changes to other existing branches. -The merging of changes will be done inside the branches only, so that changes in one -branch are kept inside this branch and don't mix up other branches. - -@c ======================================== - -But @emph{what is a branch?} you may wonder. It is the name given to a sequence of changes -that were made to the master branch outside the master branch. -It is easy to look up all the available branches -(the names of the change sequences) in the remote upstream repository. - -@smallexample -$ @kbd{git branch -a} -@print{} * master -@print{} remotes/origin/cmake -@end smallexample - -The asterisk in front of the branch name assures you of the fact that you see -the source files as they are in the @emph{master} branch. - -@node Checking out a feature branch from the remote repository -@section Checking out a feature branch from the remote repository - -It is also easy to -have a look at other branches, for example when you are interested in what is -going on in a certain @emph{feature branch} that the maintainer set up recently -for a new feature to be developed separately (so that others can go on undisturbed). - -@smallexample -$ @kbd{git checkout origin/cmake} -$ @kbd{git branch -a} -@print{} master -@print{} * remotes/origin/cmake -$ @kbd{./bootstrap.sh} -$ @kbd{./configure} -$ @kbd{make} -@end smallexample - -When you try this, take care that you have not changed anything in any source file. -@command{git} would notice changes and refuse to checkout the other branch. -This is meant to protect you from losing any local changes that you forgot to save. -Any source file that is part of the repository and gets generated during the build -in a slightly different way than the original would cause such a problem. - -@smallexample -$ @kbd{git status} -@print{} # On branch master -@print{} # Changes not staged for commit: -@print{} # awkgram.c -@end smallexample - -Here we have @file{awkgram.c} that was generated from @file{awkgram.y}. -But what was generated differently in the file? - -@smallexample -git diff awkgram.c -@end smallexample - -Ok, you are not interested in textual changes to the copyright notice -that are only due to a new calendar year. You are also not interested -in the internals of the generated parser and only wonder -@emph{How do we get back the original file from the repository?} - -@smallexample -$ @kbd{git checkout awkgram.c} -$ @kbd{git diff awkgram.c | wc -l} -@print{} 0 -@end smallexample - -After checking the file out once more, there is obviously no difference -to the copy saved in the repository. But let's not get distracted, we -wanted to find out what was going on in this feature branch. We can -find out by asking @command{git} what has changed in the file @file{ChangeLog} -of this feature branch relative to the master branch. - -@smallexample -git diff origin/master ChangeLog -@end smallexample - -@noindent -This produces: - -@smallexample -diff --git a/ChangeLog b/ChangeLog -index eab657c..a499ec5 100644 ---- a/ChangeLog -+++ b/ChangeLog -@@ -1,81 +1,3 @@ --2014-09-07 Arnold D. Robbins <arnold@@skeeve.com> -- -- * awk.h: Move libsigsegv stuff to ... -- * main.c: here. Thanks to Yehezkel Bernat for motivating -- the cleanup. -- * symbol.c (make_symbol, install, install_symbol): Add const to -- first parameter. Adjust decls and fix up uses. -@end smallexample - -Looks like a minor cleanup operation in the master branch that has not -yet been merged into the feature branch. We still don't know what is new -in this feature branch, how can we know? By looking at all changes that exist. - -@smallexample -$ @kbd{git diff origin/master --numstat} -@print{} 0 78 ChangeLog -@print{} 8 3 README_d/README.cmake -@end smallexample - -On your screen you see a list of all differences between the currently -checked-out branch and the master branch. It tells you the names of the -files that have changed, along with the number of added and deleted lines. -Now we can have a closer look at who changed what. -Let's single out one particular file that looks interesting. -As usual there is a @command{diff} sub-command to list all the changed -lines, but there is also a @command{blame} sub-command that tells you -who made the last change to any of the lines. - -@smallexample -git blame README_d/README.cmake -@end smallexample - -@noindent -This produces (in part): - -@smallexample -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 1) CMake is a build automation system -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 2) http://en.wikipedia.org/wiki/Cmake -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 3) -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 4) We try to use it as a replacement for the established GNU build system. -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 5) This attempt is currently only experimental. If you wonder why anyone -2092a35f (Juergen Kahrs 2014-08-12 17:11:20 +0200 6) should do this, read -@end smallexample - -The strange number on the left margin is the short form of a numerical -identifier of the change set. At the moment you can safely ignore it, -but this number is the key you need in case you should ever want to -cherry-pick some change sets. But cherry-picking is still far away, -before you can do this, you have to learn how to make changes to your -local repository and @command{push} them to the upstream repository. -Some conceptual basics are needed for understanding this essential part -of the workflow. - -@node Basics of GIT repositories -@chapter Basics of GIT repositories - -@menu -* Semantics of Cloning:: What to consider before you clone. -* Local versus Remote:: Where my source code really is. -* Tracking and Merging:: What the others are doing. -@end menu - -@c http://iverilog.wikia.com/wiki/Installation_Guide -@c http://www.linuxjournal.com/article/2840 -@c http://git-scm.com/book/en/Git-Branching-Branching-Workflows -@c https://www.atlassian.com/en/git/workflows -@c https://help.github.com/articles/what-is-a-good-git-workflow -@c https://guides.github.com/introduction/flow/index.html -@c http://supercollider.sourceforge.net/wiki/index.php/Developer_cheatsheet_for_git -@c http://savannah.gnu.org/maintenance/UsingGit/ -@c http://www.emacswiki.org/emacs/GitForEmacsDevs - -What is tracking ? - -@display -- How can I use git to contribute source code ? -You need an account at Savannah. Read this to understand the first steps: - http://savannah.gnu.org/maintenance/UsingGit - README.git -Use your account there to register your public ssh key at Savannah. -Then you are ready to checkout. Remember that (when cloning) you are -setting up your own local repository and make sure you configure it -properly. - git clone ssh://my_account_name@@git.sv.gnu.org/srv/git/gawk.git -@end display - -@node Semantics of Cloning -@section Semantics of Cloning - -@node Local versus Remote -@section Local versus Remote - -@node Tracking and Merging -@section Tracking and Merging - -@node Conventions used in the repository -@chapter Conventions used in the repository - -@menu -* master:: -* stable:: -* feature:: -* who does what:: -@end menu - -@node master -@section master - -@node stable -@section stable - -@node feature -@section feature - -@node who does what -@section who does what - -@node Tutorial for a first-time-gawk-contributor -@chapter Tutorial for a first-time-gawk-contributor - -@menu -* step-by-step instructions for a first-time-gawk-contributor:: -* step-by-step instructions for a first-time-gawk-administrator:: -@end menu - -@node step-by-step instructions for a first-time-gawk-contributor -@section step-by-step instructions for a first-time-gawk-contributor - -@node step-by-step instructions for a first-time-gawk-administrator -@section step-by-step instructions for a first-time-gawk-administrator - -@c e-mail from Arnold 2014-08.24 -@c Thanks to Michal for pointing us in the right direction! -@c I see this: -@c -@c bash-4.2$ git config --get push.default -@c simple -@c -@c What does yours say? -@c -@c It appears that "simple" will be the default in version 2.0: -@c -@c From: -@c http://blog.nicoschuele.com/posts/git-2-0-changes-push-default-to-simple -@c -@c Matching -@c -@c The 'matching' option is the default behavior in Git 1.x. It means that if you do a git push without specifying a branch, it will push all your local branches to their matching ones on your remote repository. -@c -@c Simple -@c -@c The new default in Git 2.x is 'simple'. It means that when doing a git push without specifying a branch, only your current branch will be pushed to the one git pull would normally get your code from." -@c -@c So this must explain it. I'll bet yours is set to "matching". I have no -@c idea how mine got set to "simple", since I don't recall doing that. -@c -@c In the future, I will simply make sure to push before switching branches. -@c I think I actually prefer that behavior, since it's more intuitive to me. - - -@node FAQs and HOWTOs -@chapter FAQs and HOWTOs - -@menu -* general recipes for daily work:: -@end menu - -@node general recipes for daily work -@section general recipes for daily work - -@node Links -@chapter Links - -@menu -* references and URLs to books and other texts:: -@end menu - -@node references and URLs to books and other texts -@section references and URLs to books and other texts - -@c The GNU Free Documentation License. -@node GNU Free Documentation License -@unnumbered GNU Free Documentation License -@cindex FDL (Free Documentation License) -@cindex Free Documentation License (FDL) -@cindex GNU Free Documentation License -@center Version 1.3, 3 November 2008 - -@c This file is intended to be included within another document, -@c hence no sectioning command or @node. - -@display -Copyright @copyright{} 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. -@uref{http://fsf.org/} - -Everyone is permitted to copy and distribute verbatim copies -of this license document, but changing it is not allowed. -@end display - -@enumerate 0 -@item -PREAMBLE - -The purpose of this License is to make a manual, textbook, or other -functional and useful document @dfn{free} in the sense of freedom: to -assure everyone the effective freedom to copy and redistribute it, -with or without modifying it, either commercially or noncommercially. -Secondarily, this License preserves for the author and publisher a way -to get credit for their work, while not being considered responsible -for modifications made by others. - -This License is a kind of ``copyleft'', which means that derivative -works of the document must themselves be free in the same sense. It -complements the GNU General Public License, which is a copyleft -license designed for free software. - -We have designed this License in order to use it for manuals for free -software, because free software needs free documentation: a free -program should come with manuals providing the same freedoms that the -software does. But this License is not limited to software manuals; -it can be used for any textual work, regardless of subject matter or -whether it is published as a printed book. We recommend this License -principally for works whose purpose is instruction or reference. - -@item -APPLICABILITY AND DEFINITIONS - -This License applies to any manual or other work, in any medium, that -contains a notice placed by the copyright holder saying it can be -distributed under the terms of this License. Such a notice grants a -world-wide, royalty-free license, unlimited in duration, to use that -work under the conditions stated herein. The ``Document'', below, -refers to any such manual or work. Any member of the public is a -licensee, and is addressed as ``you''. You accept the license if you -copy, modify or distribute the work in a way requiring permission -under copyright law. - -A ``Modified Version'' of the Document means any work containing the -Document or a portion of it, either copied verbatim, or with -modifications and/or translated into another language. - -A ``Secondary Section'' is a named appendix or a front-matter section -of the Document that deals exclusively with the relationship of the -publishers or authors of the Document to the Document's overall -subject (or to related matters) and contains nothing that could fall -directly within that overall subject. (Thus, if the Document is in -part a textbook of mathematics, a Secondary Section may not explain -any mathematics.) The relationship could be a matter of historical -connection with the subject or with related matters, or of legal, -commercial, philosophical, ethical or political position regarding -them. - -The ``Invariant Sections'' are certain Secondary Sections whose titles -are designated, as being those of Invariant Sections, in the notice -that says that the Document is released under this License. If a -section does not fit the above definition of Secondary then it is not -allowed to be designated as Invariant. The Document may contain zero -Invariant Sections. If the Document does not identify any Invariant -Sections then there are none. - -The ``Cover Texts'' are certain short passages of text that are listed, -as Front-Cover Texts or Back-Cover Texts, in the notice that says that -the Document is released under this License. A Front-Cover Text may -be at most 5 words, and a Back-Cover Text may be at most 25 words. - -A ``Transparent'' copy of the Document means a machine-readable copy, -represented in a format whose specification is available to the -general public, that is suitable for revising the document -straightforwardly with generic text editors or (for images composed of -pixels) generic paint programs or (for drawings) some widely available -drawing editor, and that is suitable for input to text formatters or -for automatic translation to a variety of formats suitable for input -to text formatters. A copy made in an otherwise Transparent file -format whose markup, or absence of markup, has been arranged to thwart -or discourage subsequent modification by readers is not Transparent. -An image format is not Transparent if used for any substantial amount -of text. A copy that is not ``Transparent'' is called ``Opaque''. - -Examples of suitable formats for Transparent copies include plain -@sc{ascii} without markup, Texinfo input format, La@TeX{} input -format, @acronym{SGML} or @acronym{XML} using a publicly available -@acronym{DTD}, and standard-conforming simple @acronym{HTML}, -PostScript or @acronym{PDF} designed for human modification. Examples -of transparent image formats include @acronym{PNG}, @acronym{XCF} and -@acronym{JPG}. Opaque formats include proprietary formats that can be -read and edited only by proprietary word processors, @acronym{SGML} or -@acronym{XML} for which the @acronym{DTD} and/or processing tools are -not generally available, and the machine-generated @acronym{HTML}, -PostScript or @acronym{PDF} produced by some word processors for -output purposes only. - -The ``Title Page'' means, for a printed book, the title page itself, -plus such following pages as are needed to hold, legibly, the material -this License requires to appear in the title page. For works in -formats which do not have any title page as such, ``Title Page'' means -the text near the most prominent appearance of the work's title, -preceding the beginning of the body of the text. - -The ``publisher'' means any person or entity that distributes copies -of the Document to the public. - -A section ``Entitled XYZ'' means a named subunit of the Document whose -title either is precisely XYZ or contains XYZ in parentheses following -text that translates XYZ in another language. (Here XYZ stands for a -specific section name mentioned below, such as ``Acknowledgements'', -``Dedications'', ``Endorsements'', or ``History''.) To ``Preserve the Title'' -of such a section when you modify the Document means that it remains a -section ``Entitled XYZ'' according to this definition. - -The Document may include Warranty Disclaimers next to the notice which -states that this License applies to the Document. These Warranty -Disclaimers are considered to be included by reference in this -License, but only as regards disclaiming warranties: any other -implication that these Warranty Disclaimers may have is void and has -no effect on the meaning of this License. - -@item -VERBATIM COPYING - -You may copy and distribute the Document in any medium, either -commercially or noncommercially, provided that this License, the -copyright notices, and the license notice saying this License applies -to the Document are reproduced in all copies, and that you add no other -conditions whatsoever to those of this License. You may not use -technical measures to obstruct or control the reading or further -copying of the copies you make or distribute. However, you may accept -compensation in exchange for copies. If you distribute a large enough -number of copies you must also follow the conditions in section 3. - -You may also lend copies, under the same conditions stated above, and -you may publicly display copies. - -@item -COPYING IN QUANTITY - -If you publish printed copies (or copies in media that commonly have -printed covers) of the Document, numbering more than 100, and the -Document's license notice requires Cover Texts, you must enclose the -copies in covers that carry, clearly and legibly, all these Cover -Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on -the back cover. Both covers must also clearly and legibly identify -you as the publisher of these copies. The front cover must present -the full title with all words of the title equally prominent and -visible. You may add other material on the covers in addition. -Copying with changes limited to the covers, as long as they preserve -the title of the Document and satisfy these conditions, can be treated -as verbatim copying in other respects. - -If the required texts for either cover are too voluminous to fit -legibly, you should put the first ones listed (as many as fit -reasonably) on the actual cover, and continue the rest onto adjacent -pages. - -If you publish or distribute Opaque copies of the Document numbering -more than 100, you must either include a machine-readable Transparent -copy along with each Opaque copy, or state in or with each Opaque copy -a computer-network location from which the general network-using -public has access to download using public-standard network protocols -a complete Transparent copy of the Document, free of added material. -If you use the latter option, you must take reasonably prudent steps, -when you begin distribution of Opaque copies in quantity, to ensure -that this Transparent copy will remain thus accessible at the stated -location until at least one year after the last time you distribute an -Opaque copy (directly or through your agents or retailers) of that -edition to the public. - -It is requested, but not required, that you contact the authors of the -Document well before redistributing any large number of copies, to give -them a chance to provide you with an updated version of the Document. - -@item -MODIFICATIONS - -You may copy and distribute a Modified Version of the Document under -the conditions of sections 2 and 3 above, provided that you release -the Modified Version under precisely this License, with the Modified -Version filling the role of the Document, thus licensing distribution -and modification of the Modified Version to whoever possesses a copy -of it. In addition, you must do these things in the Modified Version: - -@enumerate A -@item -Use in the Title Page (and on the covers, if any) a title distinct -from that of the Document, and from those of previous versions -(which should, if there were any, be listed in the History section -of the Document). You may use the same title as a previous version -if the original publisher of that version gives permission. - -@item -List on the Title Page, as authors, one or more persons or entities -responsible for authorship of the modifications in the Modified -Version, together with at least five of the principal authors of the -Document (all of its principal authors, if it has fewer than five), -unless they release you from this requirement. - -@item -State on the Title page the name of the publisher of the -Modified Version, as the publisher. - -@item -Preserve all the copyright notices of the Document. - -@item -Add an appropriate copyright notice for your modifications -adjacent to the other copyright notices. - -@item -Include, immediately after the copyright notices, a license notice -giving the public permission to use the Modified Version under the -terms of this License, in the form shown in the Addendum below. - -@item -Preserve in that license notice the full lists of Invariant Sections -and required Cover Texts given in the Document's license notice. - -@item -Include an unaltered copy of this License. - -@item -Preserve the section Entitled ``History'', Preserve its Title, and add -to it an item stating at least the title, year, new authors, and -publisher of the Modified Version as given on the Title Page. If -there is no section Entitled ``History'' in the Document, create one -stating the title, year, authors, and publisher of the Document as -given on its Title Page, then add an item describing the Modified -Version as stated in the previous sentence. - -@item -Preserve the network location, if any, given in the Document for -public access to a Transparent copy of the Document, and likewise -the network locations given in the Document for previous versions -it was based on. These may be placed in the ``History'' section. -You may omit a network location for a work that was published at -least four years before the Document itself, or if the original -publisher of the version it refers to gives permission. - -@item -For any section Entitled ``Acknowledgements'' or ``Dedications'', Preserve -the Title of the section, and preserve in the section all the -substance and tone of each of the contributor acknowledgements and/or -dedications given therein. - -@item -Preserve all the Invariant Sections of the Document, -unaltered in their text and in their titles. Section numbers -or the equivalent are not considered part of the section titles. - -@item -Delete any section Entitled ``Endorsements''. Such a section -may not be included in the Modified Version. - -@item -Do not retitle any existing section to be Entitled ``Endorsements'' or -to conflict in title with any Invariant Section. - -@item -Preserve any Warranty Disclaimers. -@end enumerate - -If the Modified Version includes new front-matter sections or -appendices that qualify as Secondary Sections and contain no material -copied from the Document, you may at your option designate some or all -of these sections as invariant. To do this, add their titles to the -list of Invariant Sections in the Modified Version's license notice. -These titles must be distinct from any other section titles. - -You may add a section Entitled ``Endorsements'', provided it contains -nothing but endorsements of your Modified Version by various -parties---for example, statements of peer review or that the text has -been approved by an organization as the authoritative definition of a -standard. - -You may add a passage of up to five words as a Front-Cover Text, and a -passage of up to 25 words as a Back-Cover Text, to the end of the list -of Cover Texts in the Modified Version. Only one passage of -Front-Cover Text and one of Back-Cover Text may be added by (or -through arrangements made by) any one entity. If the Document already -includes a cover text for the same cover, previously added by you or -by arrangement made by the same entity you are acting on behalf of, -you may not add another; but you may replace the old one, on explicit -permission from the previous publisher that added the old one. - -The author(s) and publisher(s) of the Document do not by this License -give permission to use their names for publicity for or to assert or -imply endorsement of any Modified Version. - -@item -COMBINING DOCUMENTS - -You may combine the Document with other documents released under this -License, under the terms defined in section 4 above for modified -versions, provided that you include in the combination all of the -Invariant Sections of all of the original documents, unmodified, and -list them all as Invariant Sections of your combined work in its -license notice, and that you preserve all their Warranty Disclaimers. - -The combined work need only contain one copy of this License, and -multiple identical Invariant Sections may be replaced with a single -copy. If there are multiple Invariant Sections with the same name but -different contents, make the title of each such section unique by -adding at the end of it, in parentheses, the name of the original -author or publisher of that section if known, or else a unique number. -Make the same adjustment to the section titles in the list of -Invariant Sections in the license notice of the combined work. - -In the combination, you must combine any sections Entitled ``History'' -in the various original documents, forming one section Entitled -``History''; likewise combine any sections Entitled ``Acknowledgements'', -and any sections Entitled ``Dedications''. You must delete all -sections Entitled ``Endorsements.'' - -@item -COLLECTIONS OF DOCUMENTS - -You may make a collection consisting of the Document and other documents -released under this License, and replace the individual copies of this -License in the various documents with a single copy that is included in -the collection, provided that you follow the rules of this License for -verbatim copying of each of the documents in all other respects. - -You may extract a single document from such a collection, and distribute -it individually under this License, provided you insert a copy of this -License into the extracted document, and follow this License in all -other respects regarding verbatim copying of that document. - -@item -AGGREGATION WITH INDEPENDENT WORKS - -A compilation of the Document or its derivatives with other separate -and independent documents or works, in or on a volume of a storage or -distribution medium, is called an ``aggregate'' if the copyright -resulting from the compilation is not used to limit the legal rights -of the compilation's users beyond what the individual works permit. -When the Document is included in an aggregate, this License does not -apply to the other works in the aggregate which are not themselves -derivative works of the Document. - -If the Cover Text requirement of section 3 is applicable to these -copies of the Document, then if the Document is less than one half of -the entire aggregate, the Document's Cover Texts may be placed on -covers that bracket the Document within the aggregate, or the -electronic equivalent of covers if the Document is in electronic form. -Otherwise they must appear on printed covers that bracket the whole -aggregate. - -@item -TRANSLATION - -Translation is considered a kind of modification, so you may -distribute translations of the Document under the terms of section 4. -Replacing Invariant Sections with translations requires special -permission from their copyright holders, but you may include -translations of some or all Invariant Sections in addition to the -original versions of these Invariant Sections. You may include a -translation of this License, and all the license notices in the -Document, and any Warranty Disclaimers, provided that you also include -the original English version of this License and the original versions -of those notices and disclaimers. In case of a disagreement between -the translation and the original version of this License or a notice -or disclaimer, the original version will prevail. - -If a section in the Document is Entitled ``Acknowledgements'', -``Dedications'', or ``History'', the requirement (section 4) to Preserve -its Title (section 1) will typically require changing the actual -title. - -@item -TERMINATION - -You may not copy, modify, sublicense, or distribute the Document -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense, or distribute it is void, and -will automatically terminate your rights under this License. - -However, if you cease all violation of this License, then your license -from a particular copyright holder is reinstated (a) provisionally, -unless and until the copyright holder explicitly and finally -terminates your license, and (b) permanently, if the copyright holder -fails to notify you of the violation by some reasonable means prior to -60 days after the cessation. - -Moreover, your license from a particular copyright holder is -reinstated permanently if the copyright holder notifies you of the -violation by some reasonable means, this is the first time you have -received notice of violation of this License (for any work) from that -copyright holder, and you cure the violation prior to 30 days after -your receipt of the notice. - -Termination of your rights under this section does not terminate the -licenses of parties who have received copies or rights from you under -this License. If your rights have been terminated and not permanently -reinstated, receipt of a copy of some or all of the same material does -not give you any rights to use it. - -@item -FUTURE REVISIONS OF THIS LICENSE - -The Free Software Foundation may publish new, revised versions -of the GNU Free Documentation License from time to time. Such new -versions will be similar in spirit to the present version, but may -differ in detail to address new problems or concerns. See -@uref{http://www.gnu.org/copyleft/}. - -Each version of the License is given a distinguishing version number. -If the Document specifies that a particular numbered version of this -License ``or any later version'' applies to it, you have the option of -following the terms and conditions either of that specified version or -of any later version that has been published (not as a draft) by the -Free Software Foundation. If the Document does not specify a version -number of this License, you may choose any version ever published (not -as a draft) by the Free Software Foundation. If the Document -specifies that a proxy can decide which future versions of this -License can be used, that proxy's public statement of acceptance of a -version permanently authorizes you to choose that version for the -Document. - -@item -RELICENSING - -``Massive Multiauthor Collaboration Site'' (or ``MMC Site'') means any -World Wide Web server that publishes copyrightable works and also -provides prominent facilities for anybody to edit those works. A -public wiki that anybody can edit is an example of such a server. A -``Massive Multiauthor Collaboration'' (or ``MMC'') contained in the -site means any set of copyrightable works thus published on the MMC -site. - -``CC-BY-SA'' means the Creative Commons Attribution-Share Alike 3.0 -license published by Creative Commons Corporation, a not-for-profit -corporation with a principal place of business in San Francisco, -California, as well as future copyleft versions of that license -published by that same organization. - -``Incorporate'' means to publish or republish a Document, in whole or -in part, as part of another Document. - -An MMC is ``eligible for relicensing'' if it is licensed under this -License, and if all works that were first published under this License -somewhere other than this MMC, and subsequently incorporated in whole -or in part into the MMC, (1) had no cover texts or invariant sections, -and (2) were thus incorporated prior to November 1, 2008. - -The operator of an MMC Site may republish an MMC contained in the site -under CC-BY-SA on the same site at any time before August 1, 2009, -provided the MMC is eligible for relicensing. - -@end enumerate - -@c fakenode --- for prepinfo -@unnumberedsec ADDENDUM: How to use this License for your documents - -To use this License in a document you have written, include a copy of -the License in the document and put the following copyright and -license notices just after the title page: - -@smallexample -@group - Copyright (C) @var{year} @var{your name}. - Permission is granted to copy, distribute and/or modify this document - under the terms of the GNU Free Documentation License, Version 1.3 - or any later version published by the Free Software Foundation; - with no Invariant Sections, no Front-Cover Texts, and no Back-Cover - Texts. A copy of the license is included in the section entitled ``GNU - Free Documentation License''. -@end group -@end smallexample - -If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, -replace the ``with@dots{}Texts.'' line with this: - -@smallexample -@group - with the Invariant Sections being @var{list their titles}, with - the Front-Cover Texts being @var{list}, and with the Back-Cover Texts - being @var{list}. -@end group -@end smallexample - -If you have Invariant Sections without Cover Texts, or some other -combination of the three, merge those two alternatives to suit the -situation. - -If your document contains nontrivial examples of program code, we -recommend releasing these examples in parallel under your choice of -free software license, such as the GNU General Public License, -to permit their use in free software. - -@c Local Variables: -@c ispell-local-pdict: "ispell-dict" -@c End: - - -@node Index -@comment node-name, next, previous, up - -@unnumbered Index -@printindex cp -@bye - -Conventions: -1. Functions, built-in or otherwise, do NOT have () after them. -2. Gawk built-in vars and functions are in @code. Also program vars and - functions. -3. HTTP method names are in @code. -4. Protocols such as echo, ftp, etc are in @samp. -5. URLs are in @url. -6. All RFCs in the index. Put a space between `RFC' and the number. |