[MERGE] Fixing Typos in documentation

[Ben Finney]

Frank Aspell <frankaspell at googlemail.com> writes:

> This fixes some typos in bzr documentation.
> 
> === modified file 'bzrlib/annotate.py'
> --- bzrlib/annotate.py	2009-01-27 18:05:00 +0000
> +++ bzrlib/annotate.py	2009-02-18 22:36:52 +0000
> @@ -173,7 +173,7 @@
>  
>  
>  def _expand_annotations(annotations, branch, current_rev=None):
> -    """Expand a a files annotations into command line UI ready tuples.
> +    """Expand a files annotations into command line UI ready tuples.

s/a files annotation/a file's annotation/

> @@ -1970,7 +1970,7 @@
>  
>      @staticmethod
>      def on_file(path):
> -        """Construct a DirState on the file at path path.
> +        """Construct a DirState on the file at path.

This is where I wish the convention of marking up replaceable
parameters was more commonly followed. I think the above is meant to
be read as:

    Construct a DirState on the file at path `path`.

> === modified file 'bzrlib/remote.py'
> --- bzrlib/remote.py	2009-02-13 00:52:18 +0000
> +++ bzrlib/remote.py	2009-02-19 10:18:15 +0000
> @@ -44,7 +44,7 @@
>  
>  
>  class _RpcHelper(object):
> -    """Mixin class that helps with issuing RPCs."""
> +    """Mixing class that helps with issuing RPCs."""

A “mixin” (or, better, “mix-in”) is a modifier describing a
category of class (one that is intended for use “mixed in” with
another). Perhaps better as:

    Mix-in class that helps with issuing RPCs.

> @@ -114,7 +114,7 @@
>  
>      def create_repository(self, shared=False):
>          # as per meta1 formats - just delegate to the format object which may
> -        # be parameterised.
> +        # be parameterized.

Is there a need for this? Many other “ise/ize” discrepancies exist,
why focus on only a few?

> @@ -918,7 +918,7 @@
>              # the user will almost certainly have seen a warning about the
>              # server version already.
>              rg = self.get_revision_graph()
> -            # There is an api discrepency between get_parent_map and
> +            # There is an api discrepancy between get_parent_map and

Might as well correct the initialism to use the correct case:

    There is an API discrepancy between get_parent_map and

> === modified file 'bzrlib/tests/__init__.py'
> --- bzrlib/tests/__init__.py	2009-02-19 01:41:43 +0000
> +++ bzrlib/tests/__init__.py	2009-02-19 10:29:06 +0000
> @@ -992,7 +992,7 @@
>                  raise AssertionError("%r is %r." % (left, right))
>  
>      def assertTransportMode(self, transport, path, mode):
> -        """Fail if a path does not have mode mode.
> +        """Fail if a path does not have mode.

Another instance where markup would make intent clearer.

    Fail if a path does not have mode `mode`.

> @@ -856,7 +856,7 @@
>          """Merge from a branch into this working tree.
>  
>          :param branch: The branch to merge from.
> -        :param to_revision: If non-None, the merge will merge to to_revision,
> +        :param to_revision: If non-None, the merge will merge to_revision,
>              but not beyond it. to_revision does not need to be in the history

The original seems to be correct as is.

> === modified file 'doc/developers/planned-performance-changes.txt'
> --- doc/developers/planned-performance-changes.txt	2007-06-19 00:48:22 +0000
> +++ doc/developers/planned-performance-changes.txt	2009-02-18 11:05:38 +0000
> @@ -50,7 +50,7 @@
>     considered a cache this is not exposed in such a way that cache operations
>     like 'drop the cache' can be performed. On current disk formats the cache is
>     mandatory, but an API to manage would allow refreshing of the cache (e.g.
> -   after ghosts are filled in in baz conversions).
> +   after ghosts are filled in baz conversions).

Another case where possibly the original is correct as is; “filled in”
is a phrasal verb, and “in baz conversions” is a modifier specifying
a condition when that verb occurs. Could perhaps be phrased better:

    after ghosts are filled in during baz conversions).

> === modified file 'doc/en/user-guide/solo_intro.txt'
> --- doc/en/user-guide/solo_intro.txt	2007-11-23 05:52:03 +0000
> +++ doc/en/user-guide/solo_intro.txt	2009-02-17 12:04:09 +0000
> @@ -5,7 +5,7 @@
>  ----------------------------
>  
>  Some tools are designed to make individuals productive (e.g. editors)
> -while other tools (e.g. back-end services) are focussed on making teams
> +while other tools (e.g. back-end services) are focused on making teams

Fine as is in the original. (This is another en_UK vs. en_US variation.)

> === modified file 'doc/en/user-guide/using_gatekeepers.txt'
> --- doc/en/user-guide/using_gatekeepers.txt	2007-11-23 15:45:20 +0000
> +++ doc/en/user-guide/using_gatekeepers.txt	2009-02-17 12:04:09 +0000
> @@ -22,7 +22,7 @@
>  acceptable, indeed common, to have multiple central branches with
>  different gatekeepers, e.g. one branch for the current production
>  release and another for the next release. In this case, a task branch
> -holding a bug fix will most likely be advertized to both gatekeepers.
> +holding a bug fix will most likely be advertised to both gatekeepers.

I think this is evidence that even you aren't decided on which of
“-ise” or “-ize” you are aiming for :-)


Thanks for these changes. I wonder what caused so many doubled-up words?

-- 
 \         “If life deals you lemons, why not go kill someone with the |
  `\     lemons (maybe by shoving them down his throat).” —Jack Handey |
_o__)                                                                  |
Ben Finney