Merge branch 'doc' of git://github.com/mgeisler/buildbot

master/docs/developer/master-slave.rst

@@ -58,7 +58,7 @@ The slave-side Bot object has the following remote methods:
     ``environ``
         copy of the slaves environment
     ``system``
-        OS the slave is running (extracted from pythons os.name)
+        OS the slave is running (extracted from Python's os.name)
     ``basedir``
         base directory where slave is running
 
@@ -215,7 +215,7 @@ Runs a shell command on the slave.  This command takes the following arguments:
     A dictionary of environment variables to augment or replace the
     existing environment on the slave.  In this dictionary, ``PYTHONPATH``
     is treated specially: it should be a list of path components, rather
-    than a string, and will be prepended to the existing python path.
+    than a string, and will be prepended to the existing Python path.
 
 ``initial_stdin``
 

master/docs/manual/cfg-buildfactories.rst

@@ -365,7 +365,7 @@ Arguments:
     pure-python modules.
 
 ``python``
-    which python executable to use. This list will form the start of
+    which Python executable to use. This list will form the start of
     the `argv` array that will launch trial. If you use this,
     you should set ``trial`` to an explicit path (like
     :file:`/usr/bin/trial` or :file:`./bin/trial`). The parameter defaults

master/docs/manual/cfg-buildslaves.rst

@@ -368,13 +368,13 @@ Libvirt
 
 `libvirt <http://www.libvirt.org/>`_ is a virtualization API for interacting
 with the virtualization capabilities of recent versions of Linux and other OSes.
-It is LGPL and comes with a stable C API, and python bindings.
+It is LGPL and comes with a stable C API, and Python bindings.
 
 This means we know have an API which when tied to buildbot allows us to have slaves
 that run under Xen, QEMU, KVM, LXC, OpenVZ, User Mode Linux, VirtualBox and VMWare.
 
 The libvirt code in Buildbot was developed against libvirt 0.7.5 on Ubuntu Lucid. It
-is used with KVM to test python code on Karmic VM's, but obviously isn't limited to that.
+is used with KVM to test Python code on Karmic VM's, but obviously isn't limited to that.
 Each build is run on a new VM, images are temporary and thrown away after each build.
 
 Setting up libvirt

master/docs/manual/cfg-buildsteps.rst

@@ -264,7 +264,7 @@ The :bb:step:`Mercurial` build step performs a `Mercurial <http://selenic.com/me
 (aka ``hg``) checkout or update.
 
 Branches are available in two modes: ``dirname``, where the name of the branch is
-a suffix of the name of the repository, or ``inrepo``, which uses hg's
+a suffix of the name of the repository, or ``inrepo``, which uses Hg's
 named-branches support. Make sure this setting matches your changehook, if you
 have that installed. ::
 
@@ -285,7 +285,7 @@ The Mercurial step takes the following arguments:
 ``branchType``
    either 'dirname' (default) or 'inrepo' depending on whether the
    branch name should be appended to the ``repourl`` or the branch
-   is a mercurial named branch and can be found within the ``repourl``.
+   is a Mercurial named branch and can be found within the ``repourl``.
 
 ``clobberOnBranchChange``
    boolean, defaults to ``True``. If set and using inrepos branches,
@@ -345,11 +345,11 @@ The Git step takes the following arguments:
 
 ``submodules``
    (optional): when initializing/updating a Git repository, this
-   decides whether or not buildbot should consider git submodules.
+   decides whether or not buildbot should consider Git submodules.
    Default: ``False``.
 
 ``shallow``
-   (optional): instructs git to attempt shallow clones (``--depth
+   (optional): instructs Git to attempt shallow clones (``--depth
    1``). If the user/scheduler asks for a specific revision, this
    parameter is ignored. 
 
@@ -412,10 +412,10 @@ The Git step takes the following arguments:
 
    * ``getDescription=False``: disables this feature explicitly
    * ``getDescription=True`` or empty ``dict()``: Run `git describe` with no args
-   * ``getDescription={...}``: a dict with keys named the same as the git option.
+   * ``getDescription={...}``: a dict with keys named the same as the Git option.
      Each key's value can be ``False`` or ``None`` to explicitly skip that argument.
 
-     For the following keys, a value of ``True`` appends the same-named git argument:
+     For the following keys, a value of ``True`` appends the same-named Git argument:
 
       * ``all`` : `--all`
       * ``always``: `--always`
@@ -426,7 +426,7 @@ The Git step takes the following arguments:
       * ``tags``: `--tags`
       * ``dirty``: `--dirty`
 
-     For the following keys, an integer or string value (depending on what git expects)
+     For the following keys, an integer or string value (depending on what Git expects)
      will set the argument's parameter appropriately. Examples show the key-value pair:
 
       * ``match=foo``: `--match foo`
@@ -704,7 +704,7 @@ The Repo step takes the following arguments:
     (optional, defaults to ``None``): the repo tarball used for
     fast bootstrap. If not present the tarball will be created
     automatically after first sync. It is a copy of the ``.repo``
-    directory which contains all the git objects. This feature helps
+    directory which contains all the Git objects. This feature helps
     to minimize network usage on very big projects.
 
 ``jobs``
@@ -772,7 +772,7 @@ sources are coming from.
         problems if the build process does not handle dependencies
         properly (sometimes you must do a *clean build* to make sure
         everything gets compiled), or if source files are deleted but
-        generated files can influence test behavior (e.g. python's
+        generated files can influence test behavior (e.g. Python's
         .pyc files), or when source directories are deleted but
         generated files prevent CVS from removing them. Builds ought
         to be correct regardless of whether they are done *from
@@ -1101,7 +1101,7 @@ The Mercurial step takes the following arguments:
 ``branchType``
     either 'dirname' (default) or 'inrepo' depending on whether
     the branch name should be appended to the ``baseURL``
-    or the branch is a mercurial named branch and can be
+    or the branch is a Mercurial named branch and can be
     found within the ``repourl``.
 
 ``clobberOnBranchChange``
@@ -1219,15 +1219,15 @@ The ``Git`` step takes the following arguments:
 
 ``submodules``
     (optional): when initializing/updating a Git repository, this decides whether
-    or not buildbot should consider git submodules.  Default: ``False``.
+    or not buildbot should consider Git submodules.  Default: ``False``.
 
 ``reference``
     (optional): use the specified string as a path to a reference
     repository on the local machine. Git will try to grab objects from
     this path first instead of the main repository, if they exist.
 
 ``shallow``
-    (optional): instructs git to attempt shallow clones (``--depth 1``).  If the
+    (optional): instructs Git to attempt shallow clones (``--depth 1``).  If the
     user/scheduler asks for a specific revision, this parameter is ignored.
 
 ``progress``
@@ -1294,7 +1294,7 @@ The Repo step takes the following arguments:
     (optional, defaults to ``None``): the repo tarball used for
     fast bootstrap. If not present the tarball will be created
     automatically after first sync. It is a copy of the ``.repo``
-    directory which contains all the git objects. This feature helps
+    directory which contains all the Git objects. This feature helps
     to minimize network usage on very big projects.
 
 ``jobs``
@@ -1640,7 +1640,7 @@ false-positives. To use a different regexp, provide a
     f.addStep(Compile(command=["make", "test"],
                       warningPattern="^Warning: "))
 
-The ``warningPattern=`` can also be a pre-compiled python regexp
+The ``warningPattern=`` can also be a pre-compiled Python regexp
 object: this makes it possible to add flags like ``re.I`` (to use
 case-insensitive matching).
 
@@ -2233,7 +2233,7 @@ found in the shell search path.  It can be overridden with the ``trial``
 parameter.  This is useful for Twisted's own unittests, which want to use the
 copy of bin/trial that comes with the sources.
 
-To influence the version of python being used for the tests, or to add flags to
+To influence the version of Python being used for the tests, or to add flags to
 the command, set the ``python`` parameter. This can be a string (like
 ``python2.2``) or a list (like ``['python2.3', '-Wall']``).
 

master/docs/manual/cfg-changesources.rst

@@ -85,9 +85,9 @@ Git
    :file:`contrib/github_buildbot.py`, which listens for notifications
    from GitHub)
  * :bb:chsrc:`Change Hooks` in WebStatus
- * github change hook (specifically designed for GitHub notifications,
+ * GitHub change hook (specifically designed for GitHub notifications,
    but requiring a publicly-accessible WebStatus)
- * :bb:chsrc:`GitPoller` (polling a remote git repository)
+ * :bb:chsrc:`GitPoller` (polling a remote Git repository)
  * :bb:chsrc:`GoogleCodeAtomPoller` (polling the
    commit feed for a GoogleCode Git repository)
 
@@ -98,7 +98,7 @@ Repo/Git
 
 Monotone
  * :bb:chsrc:`PBChangeSource` (listening for connections from
-   :file:`monotone-buildbot.lua`, which is available with monotone)
+   :file:`monotone-buildbot.lua`, which is available with Monotone)
 
 All VC systems can be driven by a :bb:chsrc:`PBChangeSource` and the ``buildbot
 sendchange`` tool run from some form of commit script.  If you write an email
@@ -487,7 +487,7 @@ The following hooks are useful for sending changes to a :bb:chsrc:`PBChangeSourc
 Mercurial Hook
 ++++++++++++++
 
-Since Mercurial is written in python, the hook script can invoke
+Since Mercurial is written in Python, the hook script can invoke
 Buildbot's :meth:`sendchange` function directly, rather than having to
 spawn an external process. This function delivers the same sort of
 changes as :command:`buildbot sendchange` and the various hook scripts in
@@ -498,7 +498,7 @@ To set this up, first choose a Mercurial repository that represents
 your central `official` source tree. This will be the same
 repository that your buildslaves will eventually pull from. Install
 Buildbot on the machine that hosts this repository, using the same
-version of python as Mercurial is using (so that the Mercurial hook
+version of Python as Mercurial is using (so that the Mercurial hook
 can import code from buildbot). Then add the following to the
 :file:`.hg/hgrc` file in that repository, replacing the buildmaster
 hostname/portnumber as appropriate for your buildbot:
@@ -618,7 +618,7 @@ Compatibility
 
 As twisted needs to hook some signals, and some web servers 
 strictly forbid that, the parameter ``fork`` in the
-``[hgbuildbot]`` section will instruct mercurial to fork before
+``[hgbuildbot]`` section will instruct Mercurial to fork before
 sending the change request. Then as the created process will be of short
 life, it is considered as safe to disable the signal restriction in
 the Apache setting like that ``WSGIRestrictSignal Off``. Refer to the
@@ -1021,13 +1021,13 @@ GitPoller
 If you cannot take advantage of post-receive hooks as provided by
 :file:`contrib/git_buildbot.py` for example, then you can use the :bb:chsrc:`GitPoller`.
 
-The :bb:chsrc:`GitPoller` periodically fetches from a remote git repository and processes any changes.
+The :bb:chsrc:`GitPoller` periodically fetches from a remote Git repository and processes any changes.
 It requires its own working directory for operation.
 The default should be adequate, but it can be overridden via the ``workdir`` property.
 
 .. note:: There can only be a single `GitPoller` pointed at any given repository.
 
-The :bb:chsrc:`GitPoller` requires git-1.7 and later.  It accepts the following
+The :bb:chsrc:`GitPoller` requires Git-1.7 and later.  It accepts the following
 arguments:
 
 ``repourl``
@@ -1046,7 +1046,7 @@ arguments:
     interval in seconds between polls, default is 10 minutes
 
 ``gitbin``
-    path to the git binary, defaults to just ``'git'``
+    path to the Git binary, defaults to just ``'git'``
 
 ``category``
     Set the category to be used for the changes produced by the
@@ -1068,16 +1068,16 @@ arguments:
 ``encoding``
     Set encoding will be used to parse author's name and commit
     message. Default encoding is ``'utf-8'``. This will not be
-    applied to file names since git will translate non-ascii file
+    applied to file names since Git will translate non-ascii file
     names to unreadable escape sequences.
 
 ``workdir``
     the directory where the poller should keep its local repository.
     The default is :samp:`gitpoller_work`.
     If this is a relative path, it will be interpreted relative to the master's basedir.
-    Multiple git pollers can share the same directory.
+    Multiple Git pollers can share the same directory.
 
-An configuration for the git poller might look like this::
+An configuration for the Git poller might look like this::
 
     from buildbot.changes.gitpoller import GitPoller
     c['change_source'] = GitPoller('git@example.com:foobaz/myrepo.git',

master/docs/manual/cfg-global.rst

@@ -263,7 +263,7 @@ The available caches are:
 ``Changes``
     the number of change objects to cache in memory.
     This should be larger than the number of changes that typically arrive in the span of a few minutes, otherwise your schedulers will be reloading changes from the database every time they run.
-    For distributed version control systems, like git or hg, several thousand changes may arrive at once, so setting this parameter to something like 10000 isn't unreasonable.
+    For distributed version control systems, like Git or Hg, several thousand changes may arrive at once, so setting this parameter to something like 10000 isn't unreasonable.
 
     This parameter is the same as the deprecated global parameter :bb:cfg:`changeCacheSize`.  Its default value is 10.
 

master/docs/manual/cfg-properties.rst

@@ -193,7 +193,7 @@ example above, it replaces an argument to ``echo``.  Often, properties need to
 be interpolated into strings, instead.  The tool for that job is
 :ref:`Interpolate`.
 
-The more common pattern is to use python dictionary-style string interpolation by using the ``%(prop:<propname>)s`` syntax.
+The more common pattern is to use Python dictionary-style string interpolation by using the ``%(prop:<propname>)s`` syntax.
 In this form, the property name goes in the parentheses, as above.
 A common mistake is to omit the trailing "s", leading to a rather obscure error from Python ("ValueError: unsupported format character"). ::
 
@@ -262,7 +262,7 @@ Here, ``%s`` is used as a placeholder, and the substitutions (which may themselv
 
 .. note:
 
-  Like python, you can use either positional interpolation *or*
+  Like Python, you can use either positional interpolation *or*
   dictionary-style interpolation, not both.  Thus you cannot use a string
   like ``Interpolate("foo-%(src::revision)s-%s", "branch")``.
 
@@ -320,7 +320,7 @@ create a tarball with a name like
 
 .. index:: unsupported format character
 
-The more common pattern is to use python dictionary-style string interpolation
+The more common pattern is to use Python dictionary-style string interpolation
 by using the ``%(propname)s`` syntax. In this form, the property name goes in
 the parentheses, as above.  A common mistake is to omit the trailing "s",
 leading to a rather obscure error from Python ("ValueError: unsupported format
@@ -358,7 +358,7 @@ Although these are similar to shell substitutions, no other
 substitutions are currently supported, and ``replacement`` in the
 above cannot contain more substitutions.
 
-Note: like python, you can use either positional interpolation *or*
+Note: like Python, you can use either positional interpolation *or*
 dictionary-style interpolation, not both. Thus you cannot use a string like
 ``WithProperties("foo-%(revision)s-%s", "branch")``.
 

master/docs/manual/cfg-schedulers.rst

@@ -896,7 +896,7 @@ file is something like::
                                 label="force a make clean", default=False),
 
                     StringParameter(name="pull_url",
-                        label="optionally give a public git pull url:<br>",
+                        label="optionally give a public Git pull url:<br>",
                         default="", size=80)
                  ]
                  )
@@ -979,7 +979,7 @@ StringParameter
 ::
 
     StringParameter(name="pull_url",
-        label="optionally give a public git pull url:<br>",
+        label="optionally give a public Git pull url:<br>",
         default="", size=80)
 
 This parameter type will show a single-line text-entry box, and allow the user
@@ -1017,7 +1017,7 @@ the StringParameter arguments, this type allows:
 
 This class could be subclassed in order to have more customization e.g.
 
-    * developer could send a list of git branches to pull from
+    * developer could send a list of Git branches to pull from
 
     * developer could send a list of gerrit changes to cherry-pick,
 

master/docs/manual/cfg-statustargets.rst

@@ -269,7 +269,7 @@ be used to access them.
 
     The console view is still in development. At this moment by
     default the view sorts revisions lexically, which can lead to odd
-    behavior with non-integer revisions (e.g., git), or with integer
+    behavior with non-integer revisions (e.g., Git), or with integer
     revisions of different length (e.g., 999 and 1000). It also has
     some issues with displaying multiple braches at the same time. If
     you do have multiple branches, you should use the ``branch=``
@@ -702,7 +702,7 @@ submission of an arbitrary change request. Run :command:`post_build_request.py
 --help` for more information.  The ``base`` dialect must be enabled for this to
 work.
 
-github hook
+GitHub hook
 ###########
 
 The GitHub hook is simple and takes no options. ::

master/docs/manual/cmdline.rst

@@ -337,7 +337,7 @@ for each tree you use, so it may be more convenient to use the
 ``try_topfile`` approach instead.
 
 Other VC systems which work on full projects instead of individual
-directories (darcs, mercurial, git, monotone) do not require
+directories (Darcs, Mercurial, Git, Monotone) do not require
 :command:`try` to know the top directory, so the :option:`--try-topfile`
 and :option:`--try-topdir` arguments will be ignored.
 
@@ -792,7 +792,7 @@ command will look for a special directory named :file:`.buildbot`,
 starting from the current directory (where the command was run) and
 crawling upwards, eventually looking in the user's home directory. It
 will look for a file named :file:`options` in this directory, and will
-evaluate it as a python script, looking for certain names to be set.
+evaluate it as a Python script, looking for certain names to be set.
 You can just put simple ``name = 'value'`` pairs in this file to
 set the options.
 

master/docs/manual/concepts.rst

@@ -572,7 +572,7 @@ User Objects
 User Objects allow Buildbot to better manage users throughout its various
 interactions with users (see :ref:`Change-Sources` and :ref:`Status-Targets`).
 The User Objects are stored in the Buildbot database and correlate the various
-attributes that a user might have: irc, git, etc.
+attributes that a user might have: irc, Git, etc.
 
 Changes
 +++++++