Ticket #1400: NEWS-restification-1.darcs.patch

1 patch for repository /Users/zooko/playground/tahoe-lafs/1.8.2:

Fri May 13 16:02:50 MDT 2011  zooko@zooko.com
  * docs: convert NEWS to NEWS.rst and change all references to it
  This only converts the top few releases in NEWS.rst. Patrick McDonald has volunteered to convert the rest.

New patches:

[docs: convert NEWS to NEWS.rst and change all references to it
zooko@zooko.com**20110513220250
 Ignore-this: b1898e1c0e4a2d5aa8e735a3dd1428bb
 This only converts the top few releases in NEWS.rst. Patrick McDonald has volunteered to convert the rest.
] {
move ./NEWS ./NEWS.rst
hunk ./NEWS.rst 1
-User visible changes in Tahoe-LAFS.  -*- outline; coding: utf-8 -*-
+.. -*- coding: utf-8 -*-
 
hunk ./NEWS.rst 3
-* Release 1.8.2 (2011-01-30)
+==================================
+User-Visible Changes in Tahoe-LAFS
+==================================
 
hunk ./NEWS.rst 7
-** Compatibility and Dependencies
+Release 1.8.2 (2011-01-30)
+--------------------------
 
hunk ./NEWS.rst 10
- - Tahoe is now compatible with Twisted-10.2 (released last month), as well
-   as with earlier versions. The previous Tahoe-1.8.1 release failed to run
-   against Twisted-10.2, raising an AttributeError on
-   StreamServerEndpointService (#1286)
- - Tahoe now depends upon the "mock" testing library, and the foolscap
-   dependency was raised to 0.6.1 . It no longer requires pywin32 (which
-   was used only on windows). Future developers should note that
-   reactor.spawnProcess and derivatives may no longer be used inside
-   Tahoe code.
+Compatibility and Dependencies
+''''''''''''''''''''''''''''''
 
hunk ./NEWS.rst 13
-** Other Changes
+- Tahoe is now compatible with Twisted-10.2 (released last month), as
+  well as with earlier versions. The previous Tahoe-1.8.1 release
+  failed to run against Twisted-10.2, raising an AttributeError on
+  StreamServerEndpointService (`#1286`_)
+- Tahoe now depends upon the "mock" testing library, and the foolscap
+  dependency was raised to 0.6.1 . It no longer requires pywin32
+  (which was used only on windows). Future developers should note that
+  reactor.spawnProcess and derivatives may no longer be used inside
+  Tahoe code.
 
hunk ./NEWS.rst 23
- - the default reserved_space value for new storage nodes is 1 GB (#1208)
- - documentation is now in reStructuredText (.rst) format
- - "tahoe cp" should now handle non-ASCII filenames
- - the unmaintained Mac/Windows GUI applications have been removed (#1282)
- - tahoe processes should appear in top and ps as "tahoe", not "python",
-   on some unix platforms. (#174)
- - "tahoe debug trial" can be used to run the test suite (#1296)
- - the SFTP frontend now reports unknown sizes as "0" instead of "?",
-   to improve compatibility with clients like FileZilla (#1337)
- - "tahoe --version" should now report correct values in situations where
-   1.8.1 might have been wrong (#1287)
+Other Changes
+'''''''''''''
 
hunk ./NEWS.rst 26
+- the default reserved_space value for new storage nodes is 1 GB
+  (`#1208`_)
+- documentation is now in reStructuredText (.rst) format
+- "tahoe cp" should now handle non-ASCII filenames
+- the unmaintained Mac/Windows GUI applications have been removed
+  (`#1282`_)
+- tahoe processes should appear in top and ps as "tahoe", not
+  "python", on some unix platforms. (`#174`_)
+- "tahoe debug trial" can be used to run the test suite (`#1296`_)
+- the SFTP frontend now reports unknown sizes as "0" instead of "?",
+  to improve compatibility with clients like FileZilla (`#1337`_)
+- "tahoe --version" should now report correct values in situations
+  where 1.8.1 might have been wrong (`#1287`_)
 
hunk ./NEWS.rst 40
-* Release 1.8.1 (2010-10-28)
+.. _`#174`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/174
+.. _`#1208`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1208
+.. _`#1282`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1282
+.. _`#1286`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1286
+.. _`#1287`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1287
+.. _`#1296`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1296
+.. _`#1337`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1337
 
hunk ./NEWS.rst 48
-** Bugfixes and Improvements
 
hunk ./NEWS.rst 49
- - Allow the repairer to improve the health of a file by uploading
-   some shares, even if it cannot achieve the configured happiness
-   threshold. This fixes a regression introduced between v1.7.1 and
-   v1.8.0. (#1212)
- - Fix a memory leak in the ResponseCache which is used during mutable
-   file/directory operations. (#1045)
- - Fix a regression and add a performance improvement in the downloader.
-   This issue caused repair to fail in some special cases. (#1223)
- - Fix a bug that caused 'tahoe cp' to fail for a grid-to-grid copy
-   involving a non-ASCII filename. (#1224)
- - Fix a rarely-encountered bug involving printing large strings to
-   the console on Windows. (#1232)
- - Perform ~ expansion in the --exclude-from filename argument to
-   'tahoe backup'. (#1241)
- - The CLI's 'tahoe mv' and 'tahoe ln' commands previously would try
-   to use an HTTP proxy if the HTTP_PROXY environment variable was set.
-   These now always connect directly to the WAPI, thus avoiding giving
-   caps to the HTTP proxy (and also avoiding failures in the case that
-   the proxy is failing or requires authentication). (#1253)
- - The CLI now correctly reports failure in the case that 'tahoe mv'
-   fails to unlink the file from its old location. (#1255)
- - 'tahoe start' now gives a more positive indication that the node
-   has started. (#71)
- - The arguments seen by 'ps' or other tools for node processes are
-   now more useful (in particular, they include the path of the
-   'tahoe' script, rather than an obscure tool named 'twistd'). (#174)
+Release 1.8.1 (2010-10-28)
+--------------------------
 
hunk ./NEWS.rst 52
-** Removed Features
+Bugfixes and Improvements
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 55
- - The tahoe start/stop/restart and node creation commands no longer
-   accept the -m or --multiple option, for consistency between platforms.
-   (#1262)
+- Allow the repairer to improve the health of a file by uploading some
+  shares, even if it cannot achieve the configured happiness
+  threshold. This fixes a regression introduced between v1.7.1 and
+  v1.8.0. (`#1212`_)
+- Fix a memory leak in the ResponseCache which is used during mutable
+  file/directory operations. (`#1045`_)
+- Fix a regression and add a performance improvement in the
+  downloader.  This issue caused repair to fail in some special
+  cases. (`#1223`_)
+- Fix a bug that caused 'tahoe cp' to fail for a grid-to-grid copy
+  involving a non-ASCII filename. (`#1224`_)
+- Fix a rarely-encountered bug involving printing large strings to the
+  console on Windows. (`#1232`_)
+- Perform ~ expansion in the --exclude-from filename argument to
+  'tahoe backup'. (`#1241`_)
+- The CLI's 'tahoe mv' and 'tahoe ln' commands previously would try to
+  use an HTTP proxy if the HTTP_PROXY environment variable was set.
+  These now always connect directly to the WAPI, thus avoiding giving
+  caps to the HTTP proxy (and also avoiding failures in the case that
+  the proxy is failing or requires authentication). (`#1253`_)
+- The CLI now correctly reports failure in the case that 'tahoe mv'
+  fails to unlink the file from its old location. (`#1255`_)
+- 'tahoe start' now gives a more positive indication that the node has
+  started. (`#71`_)
+- The arguments seen by 'ps' or other tools for node processes are now
+  more useful (in particular, they include the path of the 'tahoe'
+  script, rather than an obscure tool named 'twistd'). (`#174`_)
 
hunk ./NEWS.rst 83
-** Packaging
+Removed Features
+''''''''''''''''
 
hunk ./NEWS.rst 86
- - We now host binary packages so that users on certain operating systems
-   can install without having a compiler.
-   <http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/README.html>
- - Use a newer version of a dependency if needed, even if an older
-   version is installed. This would previously cause a VersionConflict
-   error. (#1190)
- - Use a precompiled binary of a dependency if one with a sufficiently
-   high version number is available, instead of attempting to compile
-   the dependency from source, even if the source version has a higher
-   version number. (#1233)
+- The tahoe start/stop/restart and node creation commands no longer
+  accept the -m or --multiple option, for consistency between
+  platforms.  (`#1262`_)
 
hunk ./NEWS.rst 90
-** Documentation
+Packaging
+'''''''''
 
hunk ./NEWS.rst 93
- - All current documentation in .txt format has been converted to
-   .rst format. (#1225)
- - Added docs/backdoors.rst declaring that we won't add backdoors to
-   Tahoe-LAFS, or add anything to facilitate government access to data.
-   (#1216)
+- We now host binary packages so that users on certain operating
+  systems can install without having a compiler.
+  <http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/README.html>
+- Use a newer version of a dependency if needed, even if an older
+  version is installed. This would previously cause a VersionConflict
+  error. (`#1190`_)
+- Use a precompiled binary of a dependency if one with a sufficiently
+  high version number is available, instead of attempting to compile
+  the dependency from source, even if the source version has a higher
+  version number. (`#1233`_)
 
hunk ./NEWS.rst 104
+Documentation
+'''''''''''''
 
hunk ./NEWS.rst 107
-* Release 1.8.0 (2010-09-23)
+- All current documentation in .txt format has been converted to .rst
+  format. (`#1225`_)
+- Added docs/backdoors.rst declaring that we won't add backdoors to
+  Tahoe-LAFS, or add anything to facilitate government access to data.
+  (`#1216`_)
 
hunk ./NEWS.rst 113
-** New Features
+.. _`#71`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/71
+.. _`#174`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/174
+.. _`#1212`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1212
+.. _`#1045`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1045
+.. _`#1190`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1190
+.. _`#1216`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1216
+.. _`#1223`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1223
+.. _`#1224`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1224
+.. _`#1225`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1225
+.. _`#1232`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1232
+.. _`#1233`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1233
+.. _`#1241`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1241
+.. _`#1253`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1253
+.. _`#1255`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1255
+.. _`#1262`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1262
 
hunk ./NEWS.rst 129
- - A completely new downloader which improves performance and
-   robustness of immutable-file downloads. It uses the fastest K
-   servers to download the data in K-way parallel. It automatically
-   fails over to alternate servers if servers fail in mid-download. It
-   allows seeking to arbitrary locations in the file (the previous
-   downloader which would only read the entire file sequentially from
-   beginning to end). It minimizes unnecessary round trips and
-   unnecessary bytes transferred to improve performance. It sends
-   requests to fewer servers to reduce the load on servers (the
-   previous one would send a small request to every server for every
-   download) (#287, #288, #448, #798, #800, #990, #1170, #1191)
 
hunk ./NEWS.rst 130
- - Non-ASCII command-line arguments and non-ASCII outputs now work on
-   Windows. In addition, the command-line tool now works on 64-bit
-   Windows. (#1074)
+Release 1.8.0 (2010-09-23)
+--------------------------
 
hunk ./NEWS.rst 133
-** Bugfixes and Improvements
+New Features
+''''''''''''
 
hunk ./NEWS.rst 136
- - Document and clean up the command-line options for specifying the
-   node's base directory. (#188, #706, #715, #772, #1108)
- - The default node directory for Windows is ".tahoe" in the user's
-   home directory, the same as on other platforms. (#890)
- - Fix a case in which full cap URIs could be logged. (#685, #1155)
- - Fix bug in WUI in Python 2.5 when the system clock is set back to
-   1969. Now you can use Tahoe-LAFS with Python 2.5 and set your
-   system clock to 1969 and still use the WUI. (#1055)
- - Many improvements in code organization, tests, logging,
-   documentation, and packaging. (#983, #1074, #1108, #1127, #1129,
-   #1131, #1166, #1175)
+- A completely new downloader which improves performance and
+  robustness of immutable-file downloads. It uses the fastest K
+  servers to download the data in K-way parallel. It automatically
+  fails over to alternate servers if servers fail in mid-download. It
+  allows seeking to arbitrary locations in the file (the previous
+  downloader which would only read the entire file sequentially from
+  beginning to end). It minimizes unnecessary round trips and
+  unnecessary bytes transferred to improve performance. It sends
+  requests to fewer servers to reduce the load on servers (the
+  previous one would send a small request to every server for every
+  download) (`#287`_, `#288`_, `#448`_, `#798`_, `#800`_, `#990`_,
+  `#1170`_, `#1191`_)
+- Non-ASCII command-line arguments and non-ASCII outputs now work on
+  Windows. In addition, the command-line tool now works on 64-bit
+  Windows. (`#1074`_)
 
hunk ./NEWS.rst 152
-** Dependency Updates
+Bugfixes and Improvements
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 155
- - on x86 and x86-64 platforms, pycryptopp >= 0.5.20
- - pycrypto 2.2 is excluded due to a bug
+- Document and clean up the command-line options for specifying the
+  node's base directory. (`#188`_, `#706`_, `#715`_, `#772`_,
+  `#1108`_)
+- The default node directory for Windows is ".tahoe" in the user's
+  home directory, the same as on other platforms. (`#890`_)
+- Fix a case in which full cap URIs could be logged. (`#685`_,
+  `#1155`_)
+- Fix bug in WUI in Python 2.5 when the system clock is set back to
+  1969. Now you can use Tahoe-LAFS with Python 2.5 and set your system
+  clock to 1969 and still use the WUI. (`#1055`_)
+- Many improvements in code organization, tests, logging,
+  documentation, and packaging. (`#983`_, `#1074`_, `#1108`_,
+  `#1127`_, `#1129`_, `#1131`_, `#1166`_, `#1175`_)
 
hunk ./NEWS.rst 169
+Dependency Updates
+''''''''''''''''''
 
hunk ./NEWS.rst 172
-* Release 1.7.1 (2010-07-18)
+- on x86 and x86-64 platforms, pycryptopp >= 0.5.20
+- pycrypto 2.2 is excluded due to a bug
 
hunk ./NEWS.rst 175
-** Bugfixes and Improvements
+.. _`#188`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/188
+.. _`#287`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/287
+.. _`#288`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/288
+.. _`#448`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/448
+.. _`#685`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/685
+.. _`#706`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/706
+.. _`#715`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/715
+.. _`#772`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/772
+.. _`#798`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/798
+.. _`#800`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/800
+.. _`#890`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/890
+.. _`#983`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/983
+.. _`#990`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/990
+.. _`#1055`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1055
+.. _`#1074`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1074
+.. _`#1108`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1108
+.. _`#1155`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1155
+.. _`#1170`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1170
+.. _`#1191`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1191
+.. _`#1127`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1127
+.. _`#1129`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1129
+.. _`#1131`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1131
+.. _`#1166`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1166
+.. _`#1175`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1175
 
hunk ./NEWS.rst 200
- - Fix bug in which uploader could fail with AssertionFailure or
-   report that it had achieved servers-of-happiness when it
-   hadn't. (#1118)
- - Fix bug in which servers could get into a state where they would
-   refuse to accept shares of a certain file (#1117)
- - Add init scripts for managing the gateway server on Debian/Ubuntu
-   (#961)
- - Fix bug where server version number was always 0 on the welcome
-   page (#1067)
- - Add new command-line command "tahoe unlink" as a synonym for "tahoe
-   rm" (#776)
- - The FTP frontend now encrypts its temporary files, protecting their
-   contents from an attacker who is able to read the disk. (#1083)
- - Fix IP address detection on FreeBSD 7, 8, and 9 (#1098)
- - Fix minor layout issue in the Web User Interface with Internet
-   Explorer (#1097)
- - Fix rarely-encountered incompatibility between Twisted logging
-   utility and the new unicode support added in v1.7.0 (#1099)
- - Forward-compatibility improvements for non-ASCII caps (#1051)
+Release 1.7.1 (2010-07-18)
+--------------------------
 
hunk ./NEWS.rst 203
-** Code improvements
+Bugfixes and Improvements
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 206
- - Simplify and tidy-up directories, unicode support, test code (#923, #967,
-   #1072)
+- Fix bug in which uploader could fail with AssertionFailure or report
+  that it had achieved servers-of-happiness when it hadn't. (`#1118`_)
+- Fix bug in which servers could get into a state where they would
+  refuse to accept shares of a certain file (`#1117`_)
+- Add init scripts for managing the gateway server on Debian/Ubuntu
+  (`#961`_)
+- Fix bug where server version number was always 0 on the welcome page
+  (`#1067`_)
+- Add new command-line command "tahoe unlink" as a synonym for "tahoe
+  rm" (`#776`_)
+- The FTP frontend now encrypts its temporary files, protecting their
+  contents from an attacker who is able to read the disk. (`#1083`_)
+- Fix IP address detection on FreeBSD 7, 8, and 9 (`#1098`_)
+- Fix minor layout issue in the Web User Interface with Internet
+  Explorer (`#1097`_)
+- Fix rarely-encountered incompatibility between Twisted logging
+  utility and the new unicode support added in v1.7.0 (`#1099`_)
+- Forward-compatibility improvements for non-ASCII caps (`#1051`_)
 
hunk ./NEWS.rst 225
+Code improvements
+'''''''''''''''''
 
hunk ./NEWS.rst 228
-* Release 1.7.0 (2010-06-18)
+- Simplify and tidy-up directories, unicode support, test code
+  (`#923`_, `#967`_, `#1072`_)
 
hunk ./NEWS.rst 231
-** New Features
+.. _`#776`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/776
+.. _`#923`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/923
+.. _`#961`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/961
+.. _`#967`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/967
+.. _`#1051`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1051
+.. _`#1067`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1067
+.. _`#1072`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1072
+.. _`#1083`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1083
+.. _`#1097`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1097
+.. _`#1098`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1098
+.. _`#1099`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1099
+.. _`#1117`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1117
+.. _`#1118`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1118
 
hunk ./NEWS.rst 245
-*** SFTP support
 
hunk ./NEWS.rst 246
-Your Tahoe-LAFS gateway now acts like a full-fledged SFTP server.  It has been
-tested with sshfs to provide a virtual filesystem in Linux.  Many users have
-asked for this feature.  We hope that it serves them well! See the
-docs/frontends/FTP-and-SFTP.txt document to get started.
+Release 1.7.0 (2010-06-18)
+--------------------------
 
hunk ./NEWS.rst 249
-*** support for non-ASCII character encodings
+New Features
+''''''''''''
 
hunk ./NEWS.rst 252
-Tahoe-LAFS now correctly handles filenames containing non-ASCII characters on
-all supported platforms:
-
- - when reading files in from the local filesystem (such as when you run "tahoe
-   backup" to back up your local files to a Tahoe-LAFS grid);
-
- - when writing files out to the local filesystem (such as when you run "tahoe
-   cp -r" to recursively copy files out of a Tahoe-LAFS grid);
-
- - when displaying filenames to the terminal (such as when you run "tahoe ls"),
-   subject to limitations of the terminal and locale;
+- SFTP support (`#1037`_)
+  Your Tahoe-LAFS gateway now acts like a full-fledged SFTP server. It
+  has been tested with sshfs to provide a virtual filesystem in Linux.
+  Many users have asked for this feature.  We hope that it serves them
+  well! See the docs/frontends/FTP-and-SFTP.txt document to get
+  started.
+- support for non-ASCII character encodings (`#534`_)
+  Tahoe-LAFS now correctly handles filenames containing non-ASCII
+  characters on all supported platforms:
 
hunk ./NEWS.rst 262
+ - when reading files in from the local filesystem (such as when you
+   run "tahoe backup" to back up your local files to a Tahoe-LAFS
+   grid);
+ - when writing files out to the local filesystem (such as when you
+   run "tahoe cp -r" to recursively copy files out of a Tahoe-LAFS
+   grid);
+ - when displaying filenames to the terminal (such as when you run
+   "tahoe ls"), subject to limitations of the terminal and locale;
  - when parsing command-line arguments, except on Windows.
 
hunk ./NEWS.rst 272
-*** Servers of Happiness
-
-Tahoe-LAFS now measures during immutable file upload to see how well
-distributed it is across multiple servers. It aborts the upload if the pieces
-of the file are not sufficiently well-distributed.
-
-This behavior is controlled by a configuration parameter called "servers of
-happiness". With the default settings for its erasure coding, Tahoe-LAFS
-generates 10 shares for each file, such that any 3 of those shares are
-sufficient to recover the file. The default value of "servers of happiness" is
-7, which means that Tahoe-LAFS will guarantee that there are at least 7 servers
-holding some of the shares, such that any 3 of those servers can completely
-recover your file.
+- Servers of Happiness (`#778`_)
+  Tahoe-LAFS now measures during immutable file upload to see how well
+  distributed it is across multiple servers. It aborts the upload if
+  the pieces of the file are not sufficiently well-distributed.
+  This behavior is controlled by a configuration parameter called
+  "servers of happiness". With the default settings for its erasure
+  coding, Tahoe-LAFS generates 10 shares for each file, such that any
+  3 of those shares are sufficient to recover the file. The default
+  value of "servers of happiness" is 7, which means that Tahoe-LAFS
+  will guarantee that there are at least 7 servers holding some of the
+  shares, such that any 3 of those servers can completely recover your
+  file.  The new upload code also distributes the shares better than the
+  previous version in some cases and takes better advantage of
+  pre-existing shares (when a file has already been previously
+  uploaded). See the architecture.txt document [3] for details.
 
hunk ./NEWS.rst 288
-The new upload code also distributes the shares better than the previous
-version in some cases and takes better advantage of pre-existing shares (when a
-file has already been previously uploaded). See the architecture.txt document
-[3] for details.
+Bugfixes and Improvements
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 291
-** Bugfixes and Improvements
+- Premature abort of upload if some shares were already present and
+  some servers fail. (`#608`_)
+- python ./setup.py install -- can't create or remove files in install
+  directory. (`#803`_)
+- Network failure => internal TypeError. (`#902`_)
+- Install of Tahoe on CentOS 5.4. (`#933`_)
+- CLI option --node-url now supports https url. (`#1028`_)
+- HTML/CSS template files were not correctly installed under
+  Windows. (`#1033`_)
+- MetadataSetter does not enforce restriction on setting "tahoe"
+  subkeys.  (`#1034`_)
+- ImportError: No module named
+  setuptools_darcs.setuptools_darcs. (`#1054`_)
+- Renamed Title in xhtml files. (`#1062`_)
+- Increase Python version dependency to 2.4.4, to avoid a critical
+  CPython security bug. (`#1066`_)
+- Typo correction for the munin plugin tahoe_storagespace. (`#968`_)
+- Fix warnings found by pylint. (`#973`_)
+- Changing format of some documentation files. (`#1027`_)
+- the misc/ directory was tied up. (`#1068`_)
+- The 'ctime' and 'mtime' metadata fields are no longer written except
+  by "tahoe backup". (`#924`_)
+- Unicode filenames in Tahoe-LAFS directories are normalized so that
+  names that differ only in how accents are encoded are treated as the
+  same. (`#1076`_)
+- Various small improvements to documentation. (`#937`_, `#911`_,
+  `#1024`_, `#1082`_)
 
hunk ./NEWS.rst 319
- - Premature abort of upload if some shares were already present and some
-   servers fail. (#608)
- - python ./setup.py install -- can't create or remove files in install
-   directory. (#803)
- - Network failure => internal TypeError. (#902)
- - Install of Tahoe on CentOS 5.4. (#933)
- - CLI option --node-url now supports https url. (#1028)
- - HTML/CSS template files were not correctly installed under Windows. (#1033)
- - MetadataSetter does not enforce restriction on setting "tahoe" subkeys.
-   (#1034)
- - ImportError: No module named setuptools_darcs.setuptools_darcs. (#1054)
- - Renamed Title in xhtml files. (#1062)
- - Increase Python version dependency to 2.4.4, to avoid a critical CPython
-   security bug. (#1066)
- - Typo correction for the munin plugin tahoe_storagespace. (#968)
- - Fix warnings found by pylint. (#973)
- - Changing format of some documentation files. (#1027)
- - the misc/ directory was tied up. (#1068)
- - The 'ctime' and 'mtime' metadata fields are no longer written except by
-   "tahoe backup". (#924)
- - Unicode filenames in Tahoe-LAFS directories are normalized so that names
-   that differ only in how accents are encoded are treated as the same. (#1076)
- - Various small improvements to documentation. (#937, #911, #1024, #1082)
+Removals
+''''''''
 
hunk ./NEWS.rst 322
-** Removals
+- The 'tahoe debug consolidate' subcommand (for converting old
+  allmydata Windows client backups to a newer format) has been
+  removed.
 
hunk ./NEWS.rst 326
-The 'tahoe debug consolidate' subcommand (for converting old allmydata Windows
-client backups to a newer format) has been removed.
+Dependency Updates
+''''''''''''''''''
 
hunk ./NEWS.rst 329
-** Dependency Updates
+- the Python version dependency is raised to 2.4.4 in some cases
+  (2.4.3 for Redhat-based Linux distributions, 2.4.2 for UCS-2 builds)
+  (`#1066`_)
+- pycrypto >= 2.0.1
+- pyasn1 >= 0.0.8a
+- mock (only required by unit tests)
 
hunk ./NEWS.rst 336
-the Python version dependency is raised to 2.4.4 in some cases (2.4.3 for
-  Redhat-based Linux distributions, 2.4.2 for UCS-2 builds) (#1066)
-pycrypto >= 2.0.1
-pyasn1 >= 0.0.8a
-mock (only required by unit tests)
+.. _`#534`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/534
+.. _`#608`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/608
+.. _`#778`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/778
+.. _`#803`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/803
+.. _`#902`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/902
+.. _`#911`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/911
+.. _`#924`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/924
+.. _`#937`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/937
+.. _`#933`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/933
+.. _`#968`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/968
+.. _`#973`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/973
+.. _`#1024`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1024
+.. _`#1027`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1027
+.. _`#1028`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1028
+.. _`#1033`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1033
+.. _`#1034`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1034
+.. _`#1037`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1037
+.. _`#1054`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1054
+.. _`#1062`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1062
+.. _`#1066`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1066
+.. _`#1068`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1068
+.. _`#1076`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1076
+.. _`#1082`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1082
 
 
hunk ./NEWS.rst 361
-* Release 1.6.1 (2010-02-27)
+Release 1.6.1 (2010-02-27)
+--------------------------
 
hunk ./NEWS.rst 364
-** Bugfixes
+Bugfixes
+''''''''
 
hunk ./NEWS.rst 367
-*** Correct handling of Small Immutable Directories
+- Correct handling of Small Immutable Directories
 
hunk ./NEWS.rst 369
-Immutable directories can now be deep-checked and listed in the web UI in
-all cases. (In v1.6.0, some operations, such as deep-check, on a directory
-graph that included very small immutable directories, would result in an
-exception causing the whole operation to abort.) (#948)
+  Immutable directories can now be deep-checked and listed in the web
+  UI in all cases. (In v1.6.0, some operations, such as deep-check, on
+  a directory graph that included very small immutable directories,
+  would result in an exception causing the whole operation to abort.)
+  (`#948`_)
 
hunk ./NEWS.rst 375
-** Usability Improvements
+Usability Improvements
+''''''''''''''''''''''
 
hunk ./NEWS.rst 378
-Improved user interface messages and error reporting. (#681, #837, #939)
+- Improved user interface messages and error reporting. (`#681`_,
+  `#837`_, `#939`_)
+- The timeouts for operation handles have been greatly increased, so
+  that you can view the results of an operation up to 4 days after it
+  has completed. After viewing them for the first time, the results
+  are retained for a further day. (`#577`_)
 
hunk ./NEWS.rst 385
-The timeouts for operation handles have been greatly increased, so that
-you can view the results of an operation up to 4 days after it has
-completed. After viewing them for the first time, the results are
-retained for a further day. (#577)
+Release 1.6.0 (2010-02-01)
+--------------------------
 
hunk ./NEWS.rst 388
+New Features
+''''''''''''
 
hunk ./NEWS.rst 391
-* Release 1.6.0 (2010-02-01)
+- Immutable Directories
 
hunk ./NEWS.rst 393
-** New Features
+  Tahoe-LAFS can now create and handle immutable
+  directories. (`#607`_, `#833`_, `#931`_) These are read just like
+  normal directories, but are "deep-immutable", meaning that all their
+  children (and everything reachable from those children) must be
+  immutable objects (i.e. immutable or literal files, and other
+  immutable directories).
 
hunk ./NEWS.rst 400
-*** Immutable Directories
+  These directories must be created in a single webapi call that
+  provides all of the children at once. (Since they cannot be changed
+  after creation, the usual create/add/add sequence cannot be used.)
+  They have URIs that start with "URI:DIR2-CHK:" or "URI:DIR2-LIT:",
+  and are described on the human-facing web interface (aka the "WUI")
+  with a "DIR-IMM" abbreviation (as opposed to "DIR" for the usual
+  read-write directories and "DIR-RO" for read-only directories).
 
hunk ./NEWS.rst 408
-Tahoe-LAFS can now create and handle immutable directories. (#607, #833, #931)
-These are read just like normal directories, but are "deep-immutable", meaning
-that all their children (and everything reachable from those children) must be
-immutable objects (i.e. immutable or literal files, and other immutable
-directories).
+  Tahoe-LAFS releases before 1.6.0 cannot read the contents of an
+  immutable directory. 1.5.0 will tolerate their presence in a
+  directory listing (and display it as "unknown"). 1.4.1 and earlier
+  cannot tolerate them: a DIR-IMM child in any directory will prevent
+  the listing of that directory.
 
hunk ./NEWS.rst 414
-These directories must be created in a single webapi call that provides all
-of the children at once. (Since they cannot be changed after creation, the
-usual create/add/add sequence cannot be used.) They have URIs that start with
-"URI:DIR2-CHK:" or "URI:DIR2-LIT:", and are described on the human-facing web
-interface (aka the "WUI") with a "DIR-IMM" abbreviation (as opposed to "DIR"
-for the usual read-write directories and "DIR-RO" for read-only directories).
+  Immutable directories are repairable, just like normal immutable
+  files.
 
hunk ./NEWS.rst 417
-Tahoe-LAFS releases before 1.6.0 cannot read the contents of an immutable
-directory. 1.5.0 will tolerate their presence in a directory listing (and
-display it as "unknown"). 1.4.1 and earlier cannot tolerate them: a DIR-IMM
-child in any directory will prevent the listing of that directory.
+  The webapi "POST t=mkdir-immutable" call is used to create immutable
+  directories. See docs/frontends/webapi.txt for details.
 
hunk ./NEWS.rst 420
-Immutable directories are repairable, just like normal immutable files.
+- "tahoe backup" now creates immutable directories, backupdb has
+  dircache
 
hunk ./NEWS.rst 423
-The webapi "POST t=mkdir-immutable" call is used to create immutable
-directories. See docs/frontends/webapi.txt for details.
+  The "tahoe backup" command has been enhanced to create immutable
+  directories (in previous releases, it created read-only mutable
+  directories) (`#828`_). This is significantly faster, since it does
+  not need to create an RSA keypair for each new directory. Also
+  "DIR-IMM" immutable directories are repairable, unlike "DIR-RO"
+  read-only mutable directories at present. (A future Tahoe-LAFS
+  release should also be able to repair DIR-RO.)
 
hunk ./NEWS.rst 431
-*** "tahoe backup" now creates immutable directories, backupdb has dircache
+  In addition, the backupdb (used by "tahoe backup" to remember what
+  it has already copied) has been enhanced to store information about
+  existing immutable directories. This allows it to re-use directories
+  that have moved but still contain identical contents, or that have
+  been deleted and later replaced. (The 1.5.0 "tahoe backup" command
+  could only re-use directories that were in the same place as they
+  were in the immediately previous backup.)  With this change, the
+  backup process no longer needs to read the previous snapshot out of
+  the Tahoe-LAFS grid, reducing the network load
+  considerably. (`#606`_)
 
hunk ./NEWS.rst 442
-The "tahoe backup" command has been enhanced to create immutable directories
-(in previous releases, it created read-only mutable directories) (#828). This
-is significantly faster, since it does not need to create an RSA keypair for
-each new directory. Also "DIR-IMM" immutable directories are repairable, unlike
-"DIR-RO" read-only mutable directories at present. (A future Tahoe-LAFS release
-should also be able to repair DIR-RO.)
+  A "null backup" (in which nothing has changed since the previous
+  backup) will require only two Tahoe-side operations: one to add an
+  Archives/$TIMESTAMP entry, and a second to update the Latest/
+  link. On the local disk side, it will readdir() all your local
+  directories and stat() all your local files.
 
hunk ./NEWS.rst 448
-In addition, the backupdb (used by "tahoe backup" to remember what it has
-already copied) has been enhanced to store information about existing immutable
-directories. This allows it to re-use directories that have moved but still
-contain identical contents, or that have been deleted and later replaced. (The
-1.5.0 "tahoe backup" command could only re-use directories that were in the
-same place as they were in the immediately previous backup.)  With this change,
-the backup process no longer needs to read the previous snapshot out of the
-Tahoe-LAFS grid, reducing the network load considerably. (#606)
+  If you've been using "tahoe backup" for a while, you will notice
+  that your first use of it after upgrading to 1.6.0 may take a long
+  time: it must create proper immutable versions of all the old
+  read-only mutable directories. This process won't take as long as
+  the initial backup (where all the file contents had to be uploaded
+  too): it will require time proportional to the number and size of
+  your directories. After this initial pass, all subsequent passes
+  should take a tiny fraction of the time.
 
hunk ./NEWS.rst 457
-A "null backup" (in which nothing has changed since the previous backup) will
-require only two Tahoe-side operations: one to add an Archives/$TIMESTAMP
-entry, and a second to update the Latest/ link. On the local disk side, it
-will readdir() all your local directories and stat() all your local files.
+  As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot list a
+  directory containing an immutable subdirectory. Tahoe-LAFS versions
+  earlier than 1.6.0 cannot read the contents of an immutable
+  directory.
 
hunk ./NEWS.rst 462
-If you've been using "tahoe backup" for a while, you will notice that your
-first use of it after upgrading to 1.6.0 may take a long time: it must create
-proper immutable versions of all the old read-only mutable directories. This
-process won't take as long as the initial backup (where all the file contents
-had to be uploaded too): it will require time proportional to the number and
-size of your directories. After this initial pass, all subsequent passes
-should take a tiny fraction of the time.
+  The "tahoe backup" command has been improved to skip over unreadable
+  objects (like device files, named pipes, and files with permissions
+  that prevent the command from reading their contents), instead of
+  throwing an exception and terminating the backup process. It also
+  skips over symlinks, because these cannot be represented faithfully
+  in the Tahoe-side filesystem. A warning message will be emitted each
+  time something is skipped. (`#729`_, `#850`_, `#641`_)
 
hunk ./NEWS.rst 470
-As noted above, Tahoe-LAFS versions earlier than 1.5.0 cannot list a directory
-containing an immutable subdirectory. Tahoe-LAFS versions earlier than 1.6.0
-cannot read the contents of an immutable directory.
+- "create-node" command added, "create-client" now implies
+  --no-storage
 
hunk ./NEWS.rst 473
-The "tahoe backup" command has been improved to skip over unreadable objects
-(like device files, named pipes, and files with permissions that prevent the
-command from reading their contents), instead of throwing an exception and
-terminating the backup process. It also skips over symlinks, because these
-cannot be represented faithfully in the Tahoe-side filesystem. A warning
-message will be emitted each time something is skipped. (#729, #850, #641)
+  The basic idea behind Tahoe-LAFS's client+server and client-only
+  processes is that you are creating a general-purpose Tahoe-LAFS
+  "node" process, which has several components that can be
+  activated. Storage service is one of these optional components, as
+  is the Helper, FTP server, and SFTP server. Web gateway
+  functionality is nominally on this list, but it is always active; a
+  future release will make it optional. There are three special
+  purpose servers that can't currently be run as a component in a
+  node: introducer, key-generator, and stats-gatherer.
 
hunk ./NEWS.rst 483
-*** "create-node" command added, "create-client" now implies --no-storage
+  So now "tahoe create-node" will create a Tahoe-LAFS node process,
+  and after creation you can edit its tahoe.cfg to enable or disable
+  the desired services. It is a more general-purpose replacement for
+  "tahoe create-client".  The default configuration has storage
+  service enabled. For convenience, the "--no-storage" argument makes
+  a tahoe.cfg file that disables storage service. (`#760`_)
 
hunk ./NEWS.rst 490
-The basic idea behind Tahoe-LAFS's client+server and client-only processes is
-that you are creating a general-purpose Tahoe-LAFS "node" process, which has
-several components that can be activated. Storage service is one of these
-optional components, as is the Helper, FTP server, and SFTP server. Web gateway
-functionality is nominally on this list, but it is always active; a future
-release will make it optional. There are three special purpose servers that
-can't currently be run as a component in a node: introducer, key-generator,
-and stats-gatherer.
+  "tahoe create-client" has been changed to create a Tahoe-LAFS node
+  without a storage service. It is equivalent to "tahoe create-node
+  --no-storage". This helps to reduce the confusion surrounding the
+  use of a command with "client" in its name to create a storage
+  *server*. Use "tahoe create-client" to create a purely client-side
+  node. If you want to offer storage to the grid, use "tahoe
+  create-node" instead.
 
hunk ./NEWS.rst 498
-So now "tahoe create-node" will create a Tahoe-LAFS node process, and after
-creation you can edit its tahoe.cfg to enable or disable the desired
-services. It is a more general-purpose replacement for "tahoe create-client".
-The default configuration has storage service enabled. For convenience, the
-"--no-storage" argument makes a tahoe.cfg file that disables storage
-service. (#760)
+  In the future, other services will be added to the node, and they
+  will be controlled through options in tahoe.cfg . The most important
+  of these services may get additional --enable-XYZ or --disable-XYZ
+  arguments to "tahoe create-node".
 
hunk ./NEWS.rst 503
-"tahoe create-client" has been changed to create a Tahoe-LAFS node without a
-storage service. It is equivalent to "tahoe create-node --no-storage". This
-helps to reduce the confusion surrounding the use of a command with "client" in
-its name to create a storage *server*. Use "tahoe create-client" to create a
-purely client-side node. If you want to offer storage to the grid, use
-"tahoe create-node" instead.
+- Performance Improvements
 
hunk ./NEWS.rst 505
-In the future, other services will be added to the node, and they will be
-controlled through options in tahoe.cfg . The most important of these
-services may get additional --enable-XYZ or --disable-XYZ arguments to
-"tahoe create-node".
+  Download of immutable files begins as soon as the downloader has
+  located the K necessary shares (`#928`_, `#287`_). In both the
+  previous and current releases, a downloader will first issue queries
+  to all storage servers on the grid to locate shares before it begins
+  downloading the shares. In previous releases of Tahoe-LAFS, download
+  would not begin until all storage servers on the grid had replied to
+  the query, at which point K shares would be chosen for download from
+  among the shares that were located. In this release, download begins
+  as soon as any K shares are located. This means that downloads start
+  sooner, which is particularly important if there is a server on the
+  grid that is extremely slow or even hung in such a way that it will
+  never respond. In previous releases such a server would have a
+  negative impact on all downloads from that grid. In this release,
+  such a server will have no impact on downloads, as long as K shares
+  can be found on other, quicker, servers.  This also means that
+  downloads now use the "best-alacrity" servers that they talk to, as
+  measured by how quickly the servers reply to the initial query. This
+  might cause downloads to go faster, especially on grids with
+  heterogeneous servers or geographical dispersion.
 
hunk ./NEWS.rst 525
-** Performance Improvements
+Minor Changes
+'''''''''''''
 
hunk ./NEWS.rst 528
-Download of immutable files begins as soon as the downloader has located the K
-necessary shares (#928, #287). In both the previous and current releases, a
-downloader will first issue queries to all storage servers on the grid to
-locate shares before it begins downloading the shares. In previous releases of
-Tahoe-LAFS, download would not begin until all storage servers on the grid had
-replied to the query, at which point K shares would be chosen for download from
-among the shares that were located. In this release, download begins as soon as
-any K shares are located. This means that downloads start sooner, which is
-particularly important if there is a server on the grid that is extremely slow
-or even hung in such a way that it will never respond. In previous releases
-such a server would have a negative impact on all downloads from that grid. In
-this release, such a server will have no impact on downloads, as long as K
-shares can be found on other, quicker, servers.  This also means that
-downloads now use the "best-alacrity" servers that they talk to, as measured by
-how quickly the servers reply to the initial query. This might cause downloads
-to go faster, especially on grids with heterogeneous servers or geographical
-dispersion.
+- The webapi acquired a new "t=mkdir-with-children" command, to create
+  and populate a directory in a single call. This is significantly
+  faster than using separate "t=mkdir" and "t=set-children" operations
+  (it uses one gateway-to-grid roundtrip, instead of three or
+  four). (`#533`_)
 
hunk ./NEWS.rst 534
-** Minor Changes
+- The t=set-children (note the hyphen) operation is now documented in
+  docs/frontends/webapi.txt, and is the new preferred spelling of the
+  old t=set_children (with an underscore). The underscore version
+  remains for backwards compatibility. (`#381`_, `#927`_)
 
hunk ./NEWS.rst 539
-The webapi acquired a new "t=mkdir-with-children" command, to create and
-populate a directory in a single call. This is significantly faster than
-using separate "t=mkdir" and "t=set-children" operations (it uses one
-gateway-to-grid roundtrip, instead of three or four). (#533)
+- The tracebacks produced by errors in CLI tools should now be in
+  plain text, instead of HTML (which is unreadable outside of a
+  browser). (`#646`_)
 
hunk ./NEWS.rst 543
-The t=set-children (note the hyphen) operation is now documented in
-docs/frontends/webapi.txt, and is the new preferred spelling of the old
-t=set_children (with an underscore). The underscore version remains for
-backwards compatibility. (#381, #927)
+- The [storage]reserved_space configuration knob (which causes the
+  storage server to refuse shares when available disk space drops
+  below a threshold) should work on Windows now, not just
+  UNIX. (`#637`_)
 
hunk ./NEWS.rst 548
-The tracebacks produced by errors in CLI tools should now be in plain text,
-instead of HTML (which is unreadable outside of a browser). (#646)
+- "tahoe cp" should now exit with status "1" if it cannot figure out a
+  suitable target filename, such as when you copy from a bare
+  filecap. (`#761`_)
 
hunk ./NEWS.rst 552
-The [storage]reserved_space configuration knob (which causes the storage
-server to refuse shares when available disk space drops below a threshold)
-should work on Windows now, not just UNIX. (#637)
+- "tahoe get" no longer creates a zero-length file upon
+  error. (`#121`_)
 
hunk ./NEWS.rst 555
-"tahoe cp" should now exit with status "1" if it cannot figure out a suitable
-target filename, such as when you copy from a bare filecap. (#761)
+- "tahoe ls" can now list single files. (`#457`_)
 
hunk ./NEWS.rst 557
-"tahoe get" no longer creates a zero-length file upon error. (#121)
+- "tahoe deep-check --repair" should tolerate repair failures now,
+  instead of halting traversal. (`#874`_, `#786`_)
 
hunk ./NEWS.rst 560
-"tahoe ls" can now list single files. (#457)
+- "tahoe create-alias" no longer corrupts the aliases file if it had
+  previously been edited to have no trailing newline. (`#741`_)
 
hunk ./NEWS.rst 563
-"tahoe deep-check --repair" should tolerate repair failures now, instead of
-halting traversal. (#874, #786)
+- Many small packaging improvements were made to facilitate the
+  "tahoe-lafs" package being included in Ubuntu. Several mac/win32
+  binary libraries were removed, some figleaf code-coverage files were
+  removed, a bundled copy of darcsver-1.2.1 was removed, and
+  additional licensing text was added.
 
hunk ./NEWS.rst 569
-"tahoe create-alias" no longer corrupts the aliases file if it had
-previously been edited to have no trailing newline. (#741)
+- Several DeprecationWarnings for python2.6 were silenced. (`#859`_)
 
hunk ./NEWS.rst 571
-Many small packaging improvements were made to facilitate the "tahoe-lafs"
-package being included in Ubuntu. Several mac/win32 binary libraries were
-removed, some figleaf code-coverage files were removed, a bundled copy of
-darcsver-1.2.1 was removed, and additional licensing text was added.
+- The checker --add-lease option would sometimes fail for shares
+  stored on old (Tahoe v1.2.0) servers. (`#875`_)
 
hunk ./NEWS.rst 574
-Several DeprecationWarnings for python2.6 were silenced. (#859)
-
-The checker --add-lease option would sometimes fail for shares stored
-on old (Tahoe v1.2.0) servers. (#875)
-
-The documentation for installing on Windows (docs/install.html) has been
-improved. (#773)
+- The documentation for installing on Windows (docs/install.html)
+  has been improved. (`#773`_)
 
 For other changes not mentioned here, see
 <http://tahoe-lafs.org/trac/tahoe/query?milestone=1.6.0&keywords=!~news-done>.
hunk ./NEWS.rst 582
 To include the tickets mentioned above, go to
 <http://tahoe-lafs.org/trac/tahoe/query?milestone=1.6.0>.
 
+.. _`#121`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/121
+.. _`#287`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/287
+.. _`#381`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/381
+.. _`#457`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/457
+.. _`#533`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/533
+.. _`#577`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/577
+.. _`#606`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/606
+.. _`#607`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/607
+.. _`#637`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/637
+.. _`#641`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/641
+.. _`#646`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/646
+.. _`#681`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/681
+.. _`#729`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/729
+.. _`#741`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/741
+.. _`#760`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/760
+.. _`#761`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/761
+.. _`#768`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/768
+.. _`#773`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/773
+.. _`#786`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/786
+.. _`#828`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/828
+.. _`#833`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/833
+.. _`#859`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/859
+.. _`#874`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/874
+.. _`#875`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/875
+.. _`#931`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/931
+.. _`#837`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/837
+.. _`#850`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/850
+.. _`#927`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/927
+.. _`#928`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/928
+.. _`#939`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/939
+.. _`#948`: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/948
 
hunk ./NEWS.rst 614
-* Release 1.5.0 (2009-08-01)
+Release 1.5.0 (2009-08-01)
+--------------------------
 
hunk ./NEWS.rst 617
-** Improvements
+Improvements
+''''''''''''
 
hunk ./NEWS.rst 620
-Uploads of immutable files now use pipelined writes, improving upload speed
-slightly (10%) over high-latency connections. (#392)
+- Uploads of immutable files now use pipelined writes, improving
+  upload speed slightly (10%) over high-latency connections. (`#392`_)
 
hunk ./NEWS.rst 623
-Processing large directories has been sped up, by removing a O(N^2) algorithm
-from the dirnode decoding path and retaining unmodified encrypted entries.
-(#750, #752)
+- Processing large directories has been sped up, by removing a O(N^2)
+  algorithm from the dirnode decoding path and retaining unmodified
+  encrypted entries.  (`#750`_, `#752`_)
 
hunk ./NEWS.rst 627
-The human-facing web interface (aka the "WUI") received a significant CSS
-makeover by Kevin Reid, making it much prettier and easier to read. The WUI
-"check" and "deep-check" forms now include a "Renew Lease" checkbox,
-mirroring the CLI --add-lease option, so leases can be added or renewed from
-the web interface.
+- The human-facing web interface (aka the "WUI") received a
+  significant CSS makeover by Kevin Reid, making it much prettier and
+  easier to read. The WUI "check" and "deep-check" forms now include a
+  "Renew Lease" checkbox, mirroring the CLI --add-lease option, so
+  leases can be added or renewed from the web interface.
 
hunk ./NEWS.rst 633
-The CLI "tahoe mv" command now refuses to overwrite directories. (#705)
+- The CLI "tahoe mv" command now refuses to overwrite
+  directories. (`#705`_)
 
hunk ./NEWS.rst 636
-The CLI "tahoe webopen" command, when run without arguments, will now bring
-up the "Welcome Page" (node status and mkdir/upload forms).
+- The CLI "tahoe webopen" command, when run without arguments, will
+  now bring up the "Welcome Page" (node status and mkdir/upload
+  forms).
 
hunk ./NEWS.rst 640
-The 3.5MB limit on mutable files was removed, so it should be possible to
-upload arbitrarily-sized mutable files. Note, however, that the data format
-and algorithm remains the same, so using mutable files still requires
-bandwidth, computation, and RAM in proportion to the size of the mutable file.
-(#694)
+- The 3.5MB limit on mutable files was removed, so it should be
+  possible to upload arbitrarily-sized mutable files. Note, however,
+  that the data format and algorithm remains the same, so using
+  mutable files still requires bandwidth, computation, and RAM in
+  proportion to the size of the mutable file.  (`#694`_)
 
hunk ./NEWS.rst 646
-This version of Tahoe-LAFS will tolerate directory entries that contain filecap
-formats which it does not recognize: files and directories from the future.
-This should improve the user experience (for 1.5.0 users) when we add new cap
-formats in the future. Previous versions would fail badly, preventing the user
-from seeing or editing anything else in those directories. These unrecognized
-objects can be renamed and deleted, but obviously not read or written. Also
-they cannot generally be copied. (#683)
+- This version of Tahoe-LAFS will tolerate directory entries that
+  contain filecap formats which it does not recognize: files and
+  directories from the future.  This should improve the user
+  experience (for 1.5.0 users) when we add new cap formats in the
+  future. Previous versions would fail badly, preventing the user from
+  seeing or editing anything else in those directories. These
+  unrecognized objects can be renamed and deleted, but obviously not
+  read or written. Also they cannot generally be copied. (`#683`_)
 
hunk ./NEWS.rst 655
-** Bugfixes
+Bugfixes
+''''''''
 
hunk ./NEWS.rst 658
-deep-check-and-repair now tolerates read-only directories, such as the ones
-produced by the "tahoe backup" CLI command. Read-only directories and mutable
-files are checked, but not repaired. Previous versions threw an exception
-when attempting the repair and failed to process the remaining contents. We
-cannot yet repair these read-only objects, but at least this version allows
-the rest of the check+repair to proceed. (#625)
+- deep-check-and-repair now tolerates read-only directories, such as
+  the ones produced by the "tahoe backup" CLI command. Read-only
+  directories and mutable files are checked, but not
+  repaired. Previous versions threw an exception when attempting the
+  repair and failed to process the remaining contents. We cannot yet
+  repair these read-only objects, but at least this version allows the
+  rest of the check+repair to proceed. (`#625`_)
 
hunk ./NEWS.rst 666
-A bug in 1.4.1 which caused a server to be listed multiple times (and
-frequently broke all connections to that server) was fixed. (#653)
+- A bug in 1.4.1 which caused a server to be listed multiple times
+  (and frequently broke all connections to that server) was
+  fixed. (`#653`_)
 
hunk ./NEWS.rst 670
-The plaintext-hashing code was removed from the Helper interface, removing
-the Helper's ability to mount a partial-information-guessing attack. (#722)
+- The plaintext-hashing code was removed from the Helper interface,
+  removing the Helper's ability to mount a
+  partial-information-guessing attack. (`#722`_)
 
hunk ./NEWS.rst 674
-** Platform/packaging changes
+Platform/packaging changes
+''''''''''''''''''''''''''
 
hunk ./NEWS.rst 677
-Tahoe-LAFS now runs on NetBSD, OpenBSD, ArchLinux, and NixOS, and on an
-embedded system based on an ARM CPU running at 266 MHz.
+- Tahoe-LAFS now runs on NetBSD, OpenBSD, ArchLinux, and NixOS, and on
+  an embedded system based on an ARM CPU running at 266 MHz.
 
hunk ./NEWS.rst 680
-Unit test timeouts have been raised to allow the tests to complete on
-extremely slow platforms like embedded ARM-based NAS boxes, which may take
-several hours to run the test suite. An ARM-specific data-corrupting bug in
-an older version of Crypto++ (5.5.2) was identified: ARM-users are encouraged
-to use recent Crypto++/pycryptopp which avoids this problem.
+- Unit test timeouts have been raised to allow the tests to complete
+  on extremely slow platforms like embedded ARM-based NAS boxes, which
+  may take several hours to run the test suite. An ARM-specific
+  data-corrupting bug in an older version of Crypto++ (5.5.2) was
+  identified: ARM-users are encouraged to use recent
+  Crypto++/pycryptopp which avoids this problem.
 
hunk ./NEWS.rst 687
-Tahoe-LAFS now requires a SQLite library, either the sqlite3 that comes
-built-in with python2.5/2.6, or the add-on pysqlite2 if you're using
-python2.4. In the previous release, this was only needed for the "tahoe backup"
-command: now it is mandatory.
+- Tahoe-LAFS now requires a SQLite library, either the sqlite3 that
+  comes built-in with python2.5/2.6, or the add-on pysqlite2 if you're
+  using python2.4. In the previous release, this was only needed for
+  the "tahoe backup" command: now it is mandatory.
 
hunk ./NEWS.rst 692
-Several minor documentation updates were made.
+- Several minor documentation updates were made.
 
hunk ./NEWS.rst 694
-To help get Tahoe-LAFS into Linux distributions like Fedora and Debian,
-packaging improvements are being made in both Tahoe-LAFS and related libraries
-like pycryptopp and zfec.
+- To help get Tahoe-LAFS into Linux distributions like Fedora and
+  Debian, packaging improvements are being made in both Tahoe-LAFS and
+  related libraries like pycryptopp and zfec.
 
hunk ./NEWS.rst 698
-The Crypto++ library included in the pycryptopp package has been upgraded to
-version 5.6.0 of Crypto++, which includes a more efficient implementation of
-SHA-256 in assembly for x86 or amd64 architectures.
+- The Crypto++ library included in the pycryptopp package has been
+  upgraded to version 5.6.0 of Crypto++, which includes a more
+  efficient implementation of SHA-256 in assembly for x86 or amd64
+  architectures.
 
hunk ./NEWS.rst 703
-** dependency updates
+dependency updates
+''''''''''''''''''
 
hunk ./NEWS.rst 706
- foolscap-0.4.1
- no python-2.4.0 or 2.4.1 (2.4.2 is good)
-  (they contained a bug in base64.b32decode)
- avoid python-2.6 on windows with mingw: compiler issues
- python2.4 requires pysqlite2 (2.5,2.6 does not)
- no python-3.x
- pycryptopp-0.5.15
+- foolscap-0.4.1
+- no python-2.4.0 or 2.4.1 (2.4.2 is good) (they contained a bug in base64.b32decode)
+- avoid python-2.6 on windows with mingw: compiler issues
+- python2.4 requires pysqlite2 (2.5,2.6 does not)
+- no python-3.x
+- pycryptopp-0.5.15
 
hunk ./NEWS.rst 713
+Release 1.4.1 (2009-04-13)
+--------------------------
 
hunk ./NEWS.rst 716
-* Release 1.4.1 (2009-04-13)
+Garbage Collection
+''''''''''''''''''
 
hunk ./NEWS.rst 719
-** Garbage Collection
+- The big feature for this release is the implementation of garbage
+  collection, allowing Tahoe storage servers to delete shares for old
+  deleted files. When enabled, this uses a "mark and sweep" process:
+  clients are responsible for updating the leases on their shares
+  (generally by running "tahoe deep-check --add-lease"), and servers
+  are allowed to delete any share which does not have an up-to-date
+  lease. The process is described in detail in
+  docs/garbage-collection.txt .
 
hunk ./NEWS.rst 728
-The big feature for this release is the implementation of garbage collection,
-allowing Tahoe storage servers to delete shares for old deleted files. When
-enabled, this uses a "mark and sweep" process: clients are responsible for
-updating the leases on their shares (generally by running "tahoe deep-check
---add-lease"), and servers are allowed to delete any share which does not
-have an up-to-date lease. The process is described in detail in
-docs/garbage-collection.txt .
+  The server must be configured to enable garbage-collection, by
+  adding directives to the [storage] section that define an age limit
+  for shares. The default configuration will not delete any shares.
 
hunk ./NEWS.rst 732
-The server must be configured to enable garbage-collection, by adding
-directives to the [storage] section that define an age limit for shares. The
-default configuration will not delete any shares.
+  Both servers and clients should be upgraded to this release to make
+  the garbage-collection as pleasant as possible. 1.2.0 servers have
+  code to perform the update-lease operation but it suffers from a
+  fatal bug, while 1.3.0 servers have update-lease but will return an
+  exception for unknown storage indices, causing clients to emit an
+  Incident for each exception, slowing the add-lease process down to a
+  crawl. 1.1.0 servers did not have the add-lease operation at all.
 
hunk ./NEWS.rst 740
-Both servers and clients should be upgraded to this release to make the
-garbage-collection as pleasant as possible. 1.2.0 servers have code to
-perform the update-lease operation but it suffers from a fatal bug, while
-1.3.0 servers have update-lease but will return an exception for unknown
-storage indices, causing clients to emit an Incident for each exception,
-slowing the add-lease process down to a crawl. 1.1.0 servers did not have the
-add-lease operation at all.
+Security/Usability Problems Fixed
+'''''''''''''''''''''''''''''''''
 
hunk ./NEWS.rst 743
-** Security/Usability Problems Fixed
+- A super-linear algorithm in the Merkle Tree code was fixed, which
+  previously caused e.g. download of a 10GB file to take several hours
+  before the first byte of plaintext could be produced. The new
+  "alacrity" is about 2 minutes. A future release should reduce this
+  to a few seconds by fixing ticket `#442`_.
 
hunk ./NEWS.rst 749
-A super-linear algorithm in the Merkle Tree code was fixed, which previously
-caused e.g. download of a 10GB file to take several hours before the first
-byte of plaintext could be produced. The new "alacrity" is about 2 minutes. A
-future release should reduce this to a few seconds by fixing ticket #442.
+- The previous version permitted a small timing attack (due to our use
+  of strcmp) against the write-enabler and lease-renewal/cancel
+  secrets. An attacker who could measure response-time variations of
+  approximatly 3ns against a very noisy background time of about 15ms
+  might be able to guess these secrets. We do not believe this attack
+  was actually feasible. This release closes the attack by first
+  hashing the two strings to be compared with a random secret.
 
hunk ./NEWS.rst 757
-The previous version permitted a small timing attack (due to our use of
-strcmp) against the write-enabler and lease-renewal/cancel secrets. An
-attacker who could measure response-time variations of approximatly 3ns
-against a very noisy background time of about 15ms might be able to guess
-these secrets. We do not believe this attack was actually feasible. This
-release closes the attack by first hashing the two strings to be compared
-with a random secret.
+webapi changes
+''''''''''''''
 
hunk ./NEWS.rst 760
-** webapi changes
+- In most cases, HTML tracebacks will only be sent if an "Accept:
+  text/html" header was provided with the HTTP request. This will
+  generally cause browsers to get an HTMLized traceback but send
+  regular text/plain tracebacks to non-browsers (like the CLI
+  clients). More errors have been mapped to useful HTTP error codes.
 
hunk ./NEWS.rst 766
-In most cases, HTML tracebacks will only be sent if an "Accept: text/html"
-header was provided with the HTTP request. This will generally cause browsers
-to get an HTMLized traceback but send regular text/plain tracebacks to
-non-browsers (like the CLI clients). More errors have been mapped to useful
-HTTP error codes.
+- The streaming webapi operations (deep-check and manifest) now have a
+  way to indicate errors (an output line that starts with "ERROR"
+  instead of being legal JSON). See docs/frontends/webapi.txt for
+  details.
 
hunk ./NEWS.rst 771
-The streaming webapi operations (deep-check and manifest) now have a way to
-indicate errors (an output line that starts with "ERROR" instead of being
-legal JSON). See docs/frontends/webapi.txt for details.
+- The storage server now has its own status page (at /storage), linked
+  from the Welcome page. This page shows progress and results of the
+  two new share-crawlers: one which merely counts shares (to give an
+  estimate of how many files/directories are being stored in the
+  grid), the other examines leases and reports how much space would be
+  freed if GC were enabled. The page also shows how much disk space is
+  present, used, reserved, and available for the Tahoe server, and
+  whether the server is currently running in "read-write" mode or
+  "read-only" mode.
 
hunk ./NEWS.rst 781
-The storage server now has its own status page (at /storage), linked from the
-Welcome page. This page shows progress and results of the two new
-share-crawlers: one which merely counts shares (to give an estimate of how
-many files/directories are being stored in the grid), the other examines
-leases and reports how much space would be freed if GC were enabled. The page
-also shows how much disk space is present, used, reserved, and available for
-the Tahoe server, and whether the server is currently running in "read-write"
-mode or "read-only" mode.
+- When a directory node cannot be read (perhaps because of insufficent
+  shares), a minimal webapi page is created so that the "more-info"
+  links (including a Check/Repair operation) will still be accessible.
 
hunk ./NEWS.rst 785
-When a directory node cannot be read (perhaps because of insufficent shares),
-a minimal webapi page is created so that the "more-info" links (including a
-Check/Repair operation) will still be accessible.
+- A new "reliability" page was added, with the beginnings of work on a
+  statistical loss model. You can tell this page how many servers you
+  are using and their independent failure probabilities, and it will
+  tell you the likelihood that an arbitrary file will survive each
+  repair period. The "numpy" package must be installed to access this
+  page. A partial paper, written by Shawn Willden, has been added to
+  docs/proposed/lossmodel.lyx .
 
hunk ./NEWS.rst 793
-A new "reliability" page was added, with the beginnings of work on a
-statistical loss model. You can tell this page how many servers you are using
-and their independent failure probabilities, and it will tell you the
-likelihood that an arbitrary file will survive each repair period. The
-"numpy" package must be installed to access this page. A partial paper,
-written by Shawn Willden, has been added to docs/proposed/lossmodel.lyx .
+CLI changes
+'''''''''''
 
hunk ./NEWS.rst 796
-** CLI changes
+- "tahoe check" and "tahoe deep-check" now accept an "--add-lease"
+  argument, to update a lease on all shares. This is the "mark" side
+  of garbage collection.
 
hunk ./NEWS.rst 800
-"tahoe check" and "tahoe deep-check" now accept an "--add-lease" argument, to
-update a lease on all shares. This is the "mark" side of garbage collection.
+- In many cases, CLI error messages have been improved: the ugly
+  HTMLized traceback has been replaced by a normal python traceback.
 
hunk ./NEWS.rst 803
-In many cases, CLI error messages have been improved: the ugly HTMLized
-traceback has been replaced by a normal python traceback.
+- "tahoe deep-check" and "tahoe manifest" now have better error
+  reporting.  "tahoe cp" is now non-verbose by default.
 
hunk ./NEWS.rst 806
-"tahoe deep-check" and "tahoe manifest" now have better error reporting.
-"tahoe cp" is now non-verbose by default.
+- "tahoe backup" now accepts several "--exclude" arguments, to ignore
+  certain files (like editor temporary files and version-control
+  metadata) during backup.
 
hunk ./NEWS.rst 810
-"tahoe backup" now accepts several "--exclude" arguments, to ignore certain
-files (like editor temporary files and version-control metadata) during
-backup.
+- On windows, the CLI now accepts local paths like "c:\dir\file.txt",
+  which previously was interpreted as a Tahoe path using a "c:" alias.
 
hunk ./NEWS.rst 813
-On windows, the CLI now accepts local paths like "c:\dir\file.txt", which
-previously was interpreted as a Tahoe path using a "c:" alias.
+- The "tahoe restart" command now uses "--force" by default (meaning
+  it will start a node even if it didn't look like there was one
+  already running).
 
hunk ./NEWS.rst 817
-The "tahoe restart" command now uses "--force" by default (meaning it will
-start a node even if it didn't look like there was one already running).
+- The "tahoe debug consolidate" command was added. This takes a series
+  of independent timestamped snapshot directories (such as those
+  created by the allmydata.com windows backup program, or a series of
+  "tahoe cp -r" commands) and creates new snapshots that used shared
+  read-only directories whenever possible (like the output of "tahoe
+  backup"). In the most common case (when the snapshots are fairly
+  similar), the result will use significantly fewer directories than
+  the original, allowing "deep-check" and similar tools to run much
+  faster. In some cases, the speedup can be an order of magnitude or
+  more.  This tool is still somewhat experimental, and only needs to
+  be run on large backups produced by something other than "tahoe
+  backup", so it was placed under the "debug" category.
 
hunk ./NEWS.rst 830
-The "tahoe debug consolidate" command was added. This takes a series of
-independent timestamped snapshot directories (such as those created by the
-allmydata.com windows backup program, or a series of "tahoe cp -r" commands)
-and creates new snapshots that used shared read-only directories whenever
-possible (like the output of "tahoe backup"). In the most common case (when
-the snapshots are fairly similar), the result will use significantly fewer
-directories than the original, allowing "deep-check" and similar tools to run
-much faster. In some cases, the speedup can be an order of magnitude or more.
-This tool is still somewhat experimental, and only needs to be run on large
-backups produced by something other than "tahoe backup", so it was placed
-under the "debug" category.
+- "tahoe cp -r --caps-only tahoe:dir localdir" is a diagnostic tool
+  which, instead of copying the full contents of files into the local
+  directory, merely copies their filecaps. This can be used to verify
+  the results of a "consolidation" operation.
 
hunk ./NEWS.rst 835
-"tahoe cp -r --caps-only tahoe:dir localdir" is a diagnostic tool which,
-instead of copying the full contents of files into the local directory,
-merely copies their filecaps. This can be used to verify the results of a
-"consolidation" operation.
+other fixes
+'''''''''''
 
hunk ./NEWS.rst 838
-** other fixes
+- The codebase no longer rauses RuntimeError as a kind of
+  assert(). Specific exception classes were created for each previous
+  instance of RuntimeError.
 
hunk ./NEWS.rst 842
-The codebase no longer rauses RuntimeError as a kind of assert(). Specific
-exception classes were created for each previous instance of RuntimeError.
+ -Many unit tests were changed to use a non-network test harness,
+  speeding them up considerably.
 
hunk ./NEWS.rst 845
-Many unit tests were changed to use a non-network test harness, speeding them
-up considerably.
+- Deep-traversal operations (manifest and deep-check) now walk
+  individual directories in alphabetical order. Occasional turn breaks
+  are inserted to prevent a stack overflow when traversing directories
+  with hundreds of entries.
 
hunk ./NEWS.rst 850
-Deep-traversal operations (manifest and deep-check) now walk individual
-directories in alphabetical order. Occasional turn breaks are inserted to
-prevent a stack overflow when traversing directories with hundreds of
-entries.
+- The experimental SFTP server had its path-handling logic changed
+  slightly, to accomodate more SFTP clients, although there are still
+  issues (`#645`_).
 
hunk ./NEWS.rst 854
-The experimental SFTP server had its path-handling logic changed slightly, to
-accomodate more SFTP clients, although there are still issues (#645).
 
hunk ./NEWS.rst 855
+Release 1.3.0 (2009-02-13)
+--------------------------
 
hunk ./NEWS.rst 858
-* Release 1.3.0 (2009-02-13)
+Checker/Verifier/Repairer
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 861
-** Checker/Verifier/Repairer
+- The primary focus of this release has been writing a checker /
+  verifier / repairer for files and directories.  "Checking" is the
+  act of asking storage servers whether they have a share for the
+  given file or directory: if there are not enough shares available,
+  the file or directory will be unrecoverable. "Verifying" is the act
+  of downloading and cryptographically asserting that the server's
+  share is undamaged: it requires more work (bandwidth and CPU) than
+  checking, but can catch problems that simple checking
+  cannot. "Repair" is the act of replacing missing or damaged shares
+  with new ones.
 
hunk ./NEWS.rst 872
-The primary focus of this release has been writing a checker / verifier /
-repairer for files and directories.  "Checking" is the act of asking storage
-servers whether they have a share for the given file or directory: if there
-are not enough shares available, the file or directory will be
-unrecoverable. "Verifying" is the act of downloading and cryptographically
-asserting that the server's share is undamaged: it requires more work
-(bandwidth and CPU) than checking, but can catch problems that simple
-checking cannot. "Repair" is the act of replacing missing or damaged shares
-with new ones.
+- This release includes a full checker, a partial verifier, and a
+  partial repairer. The repairer is able to handle missing shares: new
+  shares are generated and uploaded to make up for the missing
+  ones. This is currently the best application of the repairer: to
+  replace shares that were lost because of server departure or
+  permanent drive failure.
 
hunk ./NEWS.rst 879
-This release includes a full checker, a partial verifier, and a partial
-repairer. The repairer is able to handle missing shares: new shares are
-generated and uploaded to make up for the missing ones. This is currently the
-best application of the repairer: to replace shares that were lost because of
-server departure or permanent drive failure.
+- The repairer in this release is somewhat able to handle corrupted
+  shares. The limitations are:
 
hunk ./NEWS.rst 882
-The repairer in this release is somewhat able to handle corrupted shares. The
-limitations are:
+ - Immutable verifier is incomplete: not all shares are used, and not
+   all fields of those shares are verified. Therefore the immutable
+   verifier has only a moderate chance of detecting corrupted shares.
+ - The mutable verifier is mostly complete: all shares are examined,
+   and most fields of the shares are validated.
+ - The storage server protocol offers no way for the repairer to
+   replace or delete immutable shares. If corruption is detected, the
+   repairer will upload replacement shares to other servers, but the
+   corrupted shares will be left in place.
+ - read-only directories and read-only mutable files must be repaired
+   by someone who holds the write-cap: the read-cap is
+   insufficient. Moreover, the deep-check-and-repair operation will
+   halt with an error if it attempts to repair one of these read-only
+   objects.
+ - Some forms of corruption can cause both download and repair
+   operations to fail. A future release will fix this, since download
+   should be tolerant of any corruption as long as there are at least
+   'k' valid shares, and repair should be able to fix any file that is
+   downloadable.
 
hunk ./NEWS.rst 902
- * Immutable verifier is incomplete: not all shares are used, and not all
-   fields of those shares are verified. Therefore the immutable verifier has
-   only a moderate chance of detecting corrupted shares.
- * The mutable verifier is mostly complete: all shares are examined, and most
-   fields of the shares are validated.
- * The storage server protocol offers no way for the repairer to replace or
-   delete immutable shares. If corruption is detected, the repairer will
-   upload replacement shares to other servers, but the corrupted shares will
-   be left in place.
- * read-only directories and read-only mutable files must be repaired by
-   someone who holds the write-cap: the read-cap is insufficient. Moreover,
-   the deep-check-and-repair operation will halt with an error if it attempts
-   to repair one of these read-only objects.
- * Some forms of corruption can cause both download and repair operations to
-   fail. A future release will fix this, since download should be tolerant of
-   any corruption as long as there are at least 'k' valid shares, and repair
-   should be able to fix any file that is downloadable.
+- If the downloader, verifier, or repairer detects share corruption,
+  the servers which provided the bad shares will be notified (via a
+  file placed in the BASEDIR/storage/corruption-advisories directory)
+  so their operators can manually delete the corrupted shares and
+  investigate the problem. In addition, the "incident gatherer"
+  mechanism will automatically report share corruption to an incident
+  gatherer service, if one is configured. Note that corrupted shares
+  indicate hardware failures, serious software bugs, or malice on the
+  part of the storage server operator, so a corrupted share should be
+  considered highly unusual.
 
hunk ./NEWS.rst 913
-If the downloader, verifier, or repairer detects share corruption, the
-servers which provided the bad shares will be notified (via a file placed in
-the BASEDIR/storage/corruption-advisories directory) so their operators can
-manually delete the corrupted shares and investigate the problem. In
-addition, the "incident gatherer" mechanism will automatically report share
-corruption to an incident gatherer service, if one is configured. Note that
-corrupted shares indicate hardware failures, serious software bugs, or malice
-on the part of the storage server operator, so a corrupted share should be
-considered highly unusual.
+- By periodically checking/repairing all files and directories,
+  objects in the Tahoe filesystem remain resistant to recoverability
+  failures due to missing and/or broken servers.
 
hunk ./NEWS.rst 917
-By periodically checking/repairing all files and directories, objects in the
-Tahoe filesystem remain resistant to recoverability failures due to missing
-and/or broken servers.
+- This release includes a wapi mechanism to initiate checks on
+  individual files and directories (with or without verification, and
+  with or without automatic repair). A related mechanism is used to
+  initiate a "deep-check" on a directory: recursively traversing the
+  directory and its children, checking (and/or verifying/repairing)
+  everything underneath. Both mechanisms can be run with an
+  "output=JSON" argument, to obtain machine-readable check/repair
+  status results. These results include a copy of the filesystem
+  statistics from the "deep-stats" operation (including total number
+  of files, size histogram, etc). If repair is possible, a "Repair"
+  button will appear on the results page.
 
hunk ./NEWS.rst 929
-This release includes a wapi mechanism to initiate checks on individual
-files and directories (with or without verification, and with or without
-automatic repair). A related mechanism is used to initiate a "deep-check" on
-a directory: recursively traversing the directory and its children, checking
-(and/or verifying/repairing) everything underneath. Both mechanisms can be
-run with an "output=JSON" argument, to obtain machine-readable check/repair
-status results. These results include a copy of the filesystem statistics
-from the "deep-stats" operation (including total number of files, size
-histogram, etc). If repair is possible, a "Repair" button will appear on the
-results page.
+- The client web interface now features some extra buttons to initiate
+  check and deep-check operations. When these operations finish, they
+  display a results page that summarizes any problems that were
+  encountered. All long-running deep-traversal operations, including
+  deep-check, use a start-and-poll mechanism, to avoid depending upon
+  a single long-lived HTTP connection. docs/frontends/webapi.txt has
+  details.
 
hunk ./NEWS.rst 937
-The client web interface now features some extra buttons to initiate check
-and deep-check operations. When these operations finish, they display a
-results page that summarizes any problems that were encountered. All
-long-running deep-traversal operations, including deep-check, use a
-start-and-poll mechanism, to avoid depending upon a single long-lived HTTP
-connection. docs/frontends/webapi.txt has details.
+Efficient Backup
+''''''''''''''''
 
hunk ./NEWS.rst 940
-** Efficient Backup
+- The "tahoe backup" command is new in this release, which creates
+  efficient versioned backups of a local directory. Given a local
+  pathname and a target Tahoe directory, this will create a read-only
+  snapshot of the local directory in $target/Archives/$timestamp. It
+  will also create $target/Latest, which is a reference to the latest
+  such snapshot. Each time you run "tahoe backup" with the same source
+  and target, a new $timestamp snapshot will be added. These snapshots
+  will share directories that have not changed since the last backup,
+  to speed up the process and minimize storage requirements. In
+  addition, a small database is used to keep track of which local
+  files have been uploaded already, to avoid uploading them a second
+  time. This drastically reduces the work needed to do a "null backup"
+  (when nothing has changed locally), making "tahoe backup' suitable
+  to run from a daily cronjob.
 
hunk ./NEWS.rst 955
-The "tahoe backup" command is new in this release, which creates efficient
-versioned backups of a local directory. Given a local pathname and a target
-Tahoe directory, this will create a read-only snapshot of the local directory
-in $target/Archives/$timestamp. It will also create $target/Latest, which is
-a reference to the latest such snapshot. Each time you run "tahoe backup"
-with the same source and target, a new $timestamp snapshot will be added.
-These snapshots will share directories that have not changed since the last
-backup, to speed up the process and minimize storage requirements. In
-addition, a small database is used to keep track of which local files have
-been uploaded already, to avoid uploading them a second time. This
-drastically reduces the work needed to do a "null backup" (when nothing has
-changed locally), making "tahoe backup' suitable to run from a daily cronjob.
+  Note that the "tahoe backup" CLI command must be used in conjunction
+  with a 1.3.0-or-newer Tahoe client node; there was a bug in the
+  1.2.0 webapi implementation that would prevent the last step (create
+  $target/Latest) from working.
 
hunk ./NEWS.rst 960
-Note that the "tahoe backup" CLI command must be used in conjunction with a
-1.3.0-or-newer Tahoe client node; there was a bug in the 1.2.0 webapi
-implementation that would prevent the last step (create $target/Latest) from
-working.
+Large Files
+'''''''''''
 
hunk ./NEWS.rst 963
-** Large Files
+- The 12GiB (approximate) immutable-file-size limitation is
+  lifted. This release knows how to handle so-called "v2 immutable
+  shares", which permit immutable files of up to about 18 EiB (about
+  3*10^14). These v2 shares are created if the file to be uploaded is
+  too large to fit into v1 shares. v1 shares are created if the file
+  is small enough to fit into them, so that files created with
+  tahoe-1.3.0 can still be read by earlier versions if they are not
+  too large. Note that storage servers also had to be changed to
+  support larger files, and this release is the first release in which
+  they are able to do that. Clients will detect which servers are
+  capable of supporting large files on upload and will not attempt to
+  upload shares of a large file to a server which doesn't support it.
 
hunk ./NEWS.rst 976
-The 12GiB (approximate) immutable-file-size limitation is lifted. This
-release knows how to handle so-called "v2 immutable shares", which permit
-immutable files of up to about 18 EiB (about 3*10^14). These v2 shares are
-created if the file to be uploaded is too large to fit into v1 shares. v1
-shares are created if the file is small enough to fit into them, so that
-files created with tahoe-1.3.0 can still be read by earlier versions if they
-are not too large. Note that storage servers also had to be changed to
-support larger files, and this release is the first release in which they are
-able to do that. Clients will detect which servers are capable of supporting
-large files on upload and will not attempt to upload shares of a large file
-to a server which doesn't support it.
+FTP/SFTP Server
+'''''''''''''''
 
hunk ./NEWS.rst 979
-** FTP/SFTP Server
+- Tahoe now includes experimental FTP and SFTP servers. When
+  configured with a suitable method to translate username+password
+  into a root directory cap, it provides simple access to the virtual
+  filesystem. Remember that FTP is completely unencrypted: passwords,
+  filenames, and file contents are all sent over the wire in
+  cleartext, so FTP should only be used on a local (127.0.0.1)
+  connection. This feature is still in development: there are no unit
+  tests yet, and behavior with respect to Unicode filenames is
+  uncertain. Please see docs/frontends/FTP-and-SFTP.txt for
+  configuration details. (`#512`_, `#531`_)
 
hunk ./NEWS.rst 990
-Tahoe now includes experimental FTP and SFTP servers. When configured with a
-suitable method to translate username+password into a root directory cap, it
-provides simple access to the virtual filesystem. Remember that FTP is
-completely unencrypted: passwords, filenames, and file contents are all sent
-over the wire in cleartext, so FTP should only be used on a local (127.0.0.1)
-connection. This feature is still in development: there are no unit tests
-yet, and behavior with respect to Unicode filenames is uncertain. Please see
-docs/frontends/FTP-and-SFTP.txt for configuration details. (#512, #531)
+CLI Changes
+'''''''''''
 
hunk ./NEWS.rst 993
-** CLI Changes
+- This release adds the 'tahoe create-alias' command, which is a
+  combination of 'tahoe mkdir' and 'tahoe add-alias'. This also allows
+  you to start using a new tahoe directory without exposing its URI in
+  the argv list, which is publicly visible (through the process table)
+  on most unix systems.  Thanks to Kevin Reid for bringing this issue
+  to our attention.
 
hunk ./NEWS.rst 1000
-This release adds the 'tahoe create-alias' command, which is a combination of
-'tahoe mkdir' and 'tahoe add-alias'. This also allows you to start using a
-new tahoe directory without exposing its URI in the argv list, which is
-publicly visible (through the process table) on most unix systems.  Thanks to
-Kevin Reid for bringing this issue to our attention.
+- The single-argument form of "tahoe put" was changed to create an
+  unlinked file. I.e. "tahoe put bar.txt" will take the contents of a
+  local "bar.txt" file, upload them to the grid, and print the
+  resulting read-cap; the file will not be attached to any
+  directories. This seemed a bit more useful than the previous
+  behavior (copy stdin, upload to the grid, attach the resulting file
+  into your default tahoe: alias in a child named 'bar.txt').
 
hunk ./NEWS.rst 1008
-The single-argument form of "tahoe put" was changed to create an unlinked
-file. I.e. "tahoe put bar.txt" will take the contents of a local "bar.txt"
-file, upload them to the grid, and print the resulting read-cap; the file
-will not be attached to any directories. This seemed a bit more useful than
-the previous behavior (copy stdin, upload to the grid, attach the resulting
-file into your default tahoe: alias in a child named 'bar.txt').
+- "tahoe put" was also fixed to handle mutable files correctly: "tahoe
+  put bar.txt URI:SSK:..." will read the contents of the local bar.txt
+  and use them to replace the contents of the given mutable file.
 
hunk ./NEWS.rst 1012
-"tahoe put" was also fixed to handle mutable files correctly: "tahoe put
-bar.txt URI:SSK:..." will read the contents of the local bar.txt and use them
-to replace the contents of the given mutable file.
+- The "tahoe webopen" command was modified to accept aliases. This
+  means "tahoe webopen tahoe:" will cause your web browser to open to
+  a "wui" page that gives access to the directory associated with the
+  default "tahoe:" alias. It should also accept leading slashes, like
+  "tahoe webopen tahoe:/stuff".
 
hunk ./NEWS.rst 1018
-The "tahoe webopen" command was modified to accept aliases. This means "tahoe
-webopen tahoe:" will cause your web browser to open to a "wui" page that
-gives access to the directory associated with the default "tahoe:" alias. It
-should also accept leading slashes, like "tahoe webopen tahoe:/stuff".
+- Many esoteric debugging commands were moved down into a "debug"
+  subcommand:
 
hunk ./NEWS.rst 1021
-Many esoteric debugging commands were moved down into a "debug" subcommand:
+ - tahoe debug dump-cap
+ - tahoe debug dump-share
+ - tahoe debug find-shares
+ - tahoe debug catalog-shares
+ - tahoe debug corrupt-share
 
hunk ./NEWS.rst 1027
- tahoe debug dump-cap
- tahoe debug dump-share
- tahoe debug find-shares
- tahoe debug catalog-shares
- tahoe debug corrupt-share
-
-The last command ("tahoe debug corrupt-share") flips a random bit of the
-given local sharefile. This is used to test the file verifying/repairing
-code, and obviously should not be used on user data.
+   The last command ("tahoe debug corrupt-share") flips a random bit
+   of the given local sharefile. This is used to test the file
+   verifying/repairing code, and obviously should not be used on user
+   data.
 
 The cli might not correctly handle arguments which contain non-ascii
 characters in Tahoe v1.3 (although depending on your platform it
hunk ./NEWS.rst 1038
 characters on the command-line in utf-8 encoding).  See
 http://tahoe-lafs.org/trac/tahoe/ticket/565 for details.
 
-** Web changes
+Web changes
+'''''''''''
 
hunk ./NEWS.rst 1041
-The "default webapi port", used when creating a new client node (and in the
-getting-started documentation), was changed from 8123 to 3456, to reduce
-confusion when Tahoe accessed through a Firefox browser on which the
-"Torbutton" extension has been installed. Port 8123 is occasionally used as a
-Tor control port, so Torbutton adds 8123 to Firefox's list of "banned ports"
-to avoid CSRF attacks against Tor. Once 8123 is banned, it is difficult to
-diagnose why you can no longer reach a Tahoe node, so the Tahoe default was
-changed. Note that 3456 is reserved by IANA for the "vat" protocol, but there
-are argueably more Torbutton+Tahoe users than vat users these days. Note that
-this will only affect newly-created client nodes. Pre-existing client nodes,
-created by earlier versions of tahoe, may still be listening on 8123.
+- The "default webapi port", used when creating a new client node (and
+  in the getting-started documentation), was changed from 8123 to
+  3456, to reduce confusion when Tahoe accessed through a Firefox
+  browser on which the "Torbutton" extension has been installed. Port
+  8123 is occasionally used as a Tor control port, so Torbutton adds
+  8123 to Firefox's list of "banned ports" to avoid CSRF attacks
+  against Tor. Once 8123 is banned, it is difficult to diagnose why
+  you can no longer reach a Tahoe node, so the Tahoe default was
+  changed. Note that 3456 is reserved by IANA for the "vat" protocol,
+  but there are argueably more Torbutton+Tahoe users than vat users
+  these days. Note that this will only affect newly-created client
+  nodes. Pre-existing client nodes, created by earlier versions of
+  tahoe, may still be listening on 8123.
 
hunk ./NEWS.rst 1055
-All deep-traversal operations (start-manifest, start-deep-size,
-start-deep-stats, start-deep-check) now use a start-and-poll approach,
-instead of using a single (fragile) long-running synchronous HTTP connection.
-All these "start-" operations use POST instead of GET. The old "GET
-manifest", "GET deep-size", and "POST deep-check" operations have been
-removed.
+- All deep-traversal operations (start-manifest, start-deep-size,
+  start-deep-stats, start-deep-check) now use a start-and-poll
+  approach, instead of using a single (fragile) long-running
+  synchronous HTTP connection. All these "start-" operations use POST
+  instead of GET. The old "GET manifest", "GET deep-size", and "POST
+  deep-check" operations have been removed.
 
hunk ./NEWS.rst 1062
-The new "POST start-manifest" operation, when it finally completes, results
-in a table of (path,cap), instead of the list of verifycaps produced by the
-old "GET manifest". The table is available in several formats: use
-output=html, output=text, or output=json to choose one. The JSON output also
-includes stats, and a list of verifycaps and storage-index strings.
+- The new "POST start-manifest" operation, when it finally completes,
+  results in a table of (path,cap), instead of the list of verifycaps
+  produced by the old "GET manifest". The table is available in
+  several formats: use output=html, output=text, or output=json to
+  choose one. The JSON output also includes stats, and a list of
+  verifycaps and storage-index strings. The "return_to=" and
+  "when_done=" arguments have been removed from the t=check and
+  deep-check operations.
 
hunk ./NEWS.rst 1071
-The "return_to=" and "when_done=" arguments have been removed from the
-t=check and deep-check operations.
+- The top-level status page (/status) now has a machine-readable form,
+  via "/status/?t=json". This includes information about the
+  currently-active uploads and downloads, which may be useful for
+  frontends that wish to display progress information. There is no
+  easy way to correlate the activities displayed here with recent wapi
+  requests, however.
 
hunk ./NEWS.rst 1078
-The top-level status page (/status) now has a machine-readable form, via
-"/status/?t=json". This includes information about the currently-active
-uploads and downloads, which may be useful for frontends that wish to display
-progress information. There is no easy way to correlate the activities
-displayed here with recent wapi requests, however.
+- Any files in BASEDIR/public_html/ (configurable) will be served in
+  response to requests in the /static/ portion of the URL space. This
+  will simplify the deployment of javascript-based frontends that can
+  still access wapi calls by conforming to the (regrettable)
+  "same-origin policy".
 
hunk ./NEWS.rst 1084
-Any files in BASEDIR/public_html/ (configurable) will be served in response
-to requests in the /static/ portion of the URL space. This will simplify the
-deployment of javascript-based frontends that can still access wapi calls
-by conforming to the (regrettable) "same-origin policy".
+- The welcome page now has a "Report Incident" button, which is tied
+  into the "Incident Gatherer" machinery. If the node is attached to
+  an incident gatherer (via log_gatherer.furl), then pushing this
+  button will cause an Incident to be signalled: this means recent log
+  events are aggregated and sent in a bundle to the gatherer. The user
+  can push this button after something strange takes place (and they
+  can provide a short message to go along with it), and the relevant
+  data will be delivered to a centralized incident-gatherer for later
+  processing by operations staff.
 
hunk ./NEWS.rst 1094
-The welcome page now has a "Report Incident" button, which is tied into the
-"Incident Gatherer" machinery. If the node is attached to an incident
-gatherer (via log_gatherer.furl), then pushing this button will cause an
-Incident to be signalled: this means recent log events are aggregated and
-sent in a bundle to the gatherer. The user can push this button after
-something strange takes place (and they can provide a short message to go
-along with it), and the relevant data will be delivered to a centralized
-incident-gatherer for later processing by operations staff.
+- The "HEAD" method should now work correctly, in addition to the
+  usual "GET", "PUT", and "POST" methods. "HEAD" is supposed to return
+  exactly the same headers as "GET" would, but without any of the
+  actual response body data. For mutable files, this now does a brief
+  mapupdate (to figure out the size of the file that would be
+  returned), without actually retrieving the file's contents.
 
hunk ./NEWS.rst 1101
-The "HEAD" method should now work correctly, in addition to the usual "GET",
-"PUT", and "POST" methods. "HEAD" is supposed to return exactly the same
-headers as "GET" would, but without any of the actual response body data. For
-mutable files, this now does a brief mapupdate (to figure out the size of the
-file that would be returned), without actually retrieving the file's
-contents.
+- The "GET" operation on files can now support the HTTP "Range:"
+  header, allowing requests for partial content. This allows certain
+  media players to correctly stream audio and movies out of a Tahoe
+  grid. The current implementation uses a disk-based cache in
+  BASEDIR/private/cache/download , which holds the plaintext of the
+  files being downloaded. Future implementations might not use this
+  cache. GET for immutable files now returns an ETag header.
 
hunk ./NEWS.rst 1109
-The "GET" operation on files can now support the HTTP "Range:" header,
-allowing requests for partial content. This allows certain media players to
-correctly stream audio and movies out of a Tahoe grid. The current
-implementation uses a disk-based cache in BASEDIR/private/cache/download ,
-which holds the plaintext of the files being downloaded. Future
-implementations might not use this cache. GET for immutable files now returns
-an ETag header.
+- Each file and directory now has a "Show More Info" web page, which
+  contains much of the information that was crammed into the directory
+  page before. This includes readonly URIs, storage index strings,
+  object type, buttons to control checking/verifying/repairing, and
+  deep-check/deep-stats buttons (for directories). For mutable files,
+  the "replace contents" upload form has been moved here too. As a
+  result, the directory page is now much simpler and cleaner, and
+  several potentially-misleading links (like t=uri) are now gone.
 
hunk ./NEWS.rst 1118
-Each file and directory now has a "Show More Info" web page, which contains
-much of the information that was crammed into the directory page before. This
-includes readonly URIs, storage index strings, object type, buttons to
-control checking/verifying/repairing, and deep-check/deep-stats buttons (for
-directories). For mutable files, the "replace contents" upload form has been
-moved here too. As a result, the directory page is now much simpler and
-cleaner, and several potentially-misleading links (like t=uri) are now gone.
+- Slashes are discouraged in Tahoe file/directory names, since they
+  cause problems when accessing the filesystem through the
+  wapi. However, there are a couple of accidental ways to generate
+  such names. This release tries to make it easier to correct such
+  mistakes by escaping slashes in several places, allowing slashes in
+  the t=info and t=delete commands, and in the source (but not the
+  target) of a t=rename command.
 
hunk ./NEWS.rst 1126
-Slashes are discouraged in Tahoe file/directory names, since they cause
-problems when accessing the filesystem through the wapi. However, there are
-a couple of accidental ways to generate such names. This release tries to
-make it easier to correct such mistakes by escaping slashes in several
-places, allowing slashes in the t=info and t=delete commands, and in the
-source (but not the target) of a t=rename command.
+Packaging
+'''''''''
 
hunk ./NEWS.rst 1129
-** Packaging
+- Tahoe's dependencies have been extended to require the
+  "[secure_connections]" feature from Foolscap, which will cause
+  pyOpenSSL to be required and/or installed. If OpenSSL and its
+  development headers are already installed on your system, this can
+  occur automatically. Tahoe now uses pollreactor (instead of the
+  default selectreactor) to work around a bug between pyOpenSSL and
+  the most recent release of Twisted (8.1.0). This bug only affects
+  unit tests (hang during shutdown), and should not impact regular
+  use.
 
hunk ./NEWS.rst 1139
-Tahoe's dependencies have been extended to require the "[secure_connections]"
-feature from Foolscap, which will cause pyOpenSSL to be required and/or
-installed. If OpenSSL and its development headers are already installed on
-your system, this can occur automatically. Tahoe now uses pollreactor
-(instead of the default selectreactor) to work around a bug between pyOpenSSL
-and the most recent release of Twisted (8.1.0). This bug only affects unit
-tests (hang during shutdown), and should not impact regular use.
+- The Tahoe source code tarballs now come in two different forms:
+  regular and "sumo". The regular tarball contains just Tahoe, nothing
+  else. When building from the regular tarball, the build process will
+  download any unmet dependencies from the internet (starting with the
+  index at PyPI) so it can build and install them. The "sumo" tarball
+  contains copies of all the libraries that Tahoe requires (foolscap,
+  twisted, zfec, etc), so using the "sumo" tarball should not require
+  any internet access during the build process. This can be useful if
+  you want to build Tahoe while on an airplane, a desert island, or
+  other bandwidth-limited environments.
 
hunk ./NEWS.rst 1150
-The Tahoe source code tarballs now come in two different forms: regular and
-"sumo". The regular tarball contains just Tahoe, nothing else. When building
-from the regular tarball, the build process will download any unmet
-dependencies from the internet (starting with the index at PyPI) so it can
-build and install them. The "sumo" tarball contains copies of all the
-libraries that Tahoe requires (foolscap, twisted, zfec, etc), so using the
-"sumo" tarball should not require any internet access during the build
-process. This can be useful if you want to build Tahoe while on an airplane,
-a desert island, or other bandwidth-limited environments.
+- Similarly, tahoe-lafs.org now hosts a "tahoe-deps" tarball which
+  contains the latest versions of all these dependencies. This
+  tarball, located at
+  http://tahoe-lafs.org/source/tahoe/deps/tahoe-deps.tar.gz, can be
+  unpacked in the tahoe source tree (or in its parent directory), and
+  the build process should satisfy its downloading needs from it
+  instead of reaching out to PyPI.  This can be useful if you want to
+  build Tahoe from a darcs checkout while on that airplane or desert
+  island.
 
hunk ./NEWS.rst 1160
-Similarly, tahoe-lafs.org now hosts a "tahoe-deps" tarball which contains the
-latest versions of all these dependencies. This tarball, located at
-http://tahoe-lafs.org/source/tahoe/deps/tahoe-deps.tar.gz, can be unpacked in
-the tahoe source tree (or in its parent directory), and the build process
-should satisfy its downloading needs from it instead of reaching out to PyPI.
-This can be useful if you want to build Tahoe from a darcs checkout while on
-that airplane or desert island.
+- Because of the previous two changes ("sumo" tarballs and the
+  "tahoe-deps" bundle), most of the files have been removed from
+  misc/dependencies/ . This brings the regular Tahoe tarball down to
+  2MB (compressed), and the darcs checkout (without history) to about
+  7.6MB. A full darcs checkout will still be fairly large (because of
+  the historical patches which included the dependent libraries), but
+  a 'lazy' one should now be small.
 
hunk ./NEWS.rst 1168
-Because of the previous two changes ("sumo" tarballs and the "tahoe-deps"
-bundle), most of the files have been removed from misc/dependencies/ . This
-brings the regular Tahoe tarball down to 2MB (compressed), and the darcs
-checkout (without history) to about 7.6MB. A full darcs checkout will still
-be fairly large (because of the historical patches which included the
-dependent libraries), but a 'lazy' one should now be small.
+- The default "make" target is now an alias for "setup.py build",
+  which itself is an alias for "setup.py develop --prefix support",
+  with some extra work before and after (see setup.cfg). Most of the
+  complicated platform-dependent code in the Makefile was rewritten in
+  Python and moved into setup.py, simplifying things considerably.
 
hunk ./NEWS.rst 1174
-The default "make" target is now an alias for "setup.py build", which itself
-is an alias for "setup.py develop --prefix support", with some extra work
-before and after (see setup.cfg). Most of the complicated platform-dependent
-code in the Makefile was rewritten in Python and moved into setup.py,
-simplifying things considerably.
+- Likewise, the "make test" target now delegates most of its work to
+  "setup.py test", which takes care of getting PYTHONPATH configured
+  to access the tahoe code (and dependencies) that gets put in
+  support/lib/ by the build_tahoe step. This should allow unit tests
+  to be run even when trial (which is part of Twisted) wasn't already
+  installed (in this case, trial gets installed to support/bin because
+  Twisted is a dependency of Tahoe).
 
hunk ./NEWS.rst 1182
-Likewise, the "make test" target now delegates most of its work to "setup.py
-test", which takes care of getting PYTHONPATH configured to access the tahoe
-code (and dependencies) that gets put in support/lib/ by the build_tahoe
-step. This should allow unit tests to be run even when trial (which is part
-of Twisted) wasn't already installed (in this case, trial gets installed to
-support/bin because Twisted is a dependency of Tahoe).
+- Tahoe is now compatible with the recently-released Python 2.6 ,
+  although it is recommended to use Tahoe on Python 2.5, on which it
+  has received more thorough testing and deployment.
 
hunk ./NEWS.rst 1186
-Tahoe is now compatible with the recently-released Python 2.6 , although it
-is recommended to use Tahoe on Python 2.5, on which it has received more
-thorough testing and deployment.
+- Tahoe is now compatible with simplejson-2.0.x . The previous release
+  assumed that simplejson.loads always returned unicode strings, which
+  is no longer the case in 2.0.x .
 
hunk ./NEWS.rst 1190
-Tahoe is now compatible with simplejson-2.0.x . The previous release assumed
-that simplejson.loads always returned unicode strings, which is no longer the
-case in 2.0.x .
+Grid Management Tools
+'''''''''''''''''''''
 
hunk ./NEWS.rst 1193
-** Grid Management Tools
+- Several tools have been added or updated in the misc/ directory,
+  mostly munin plugins that can be used to monitor a storage grid.
 
hunk ./NEWS.rst 1196
-Several tools have been added or updated in the misc/ directory, mostly munin
-plugins that can be used to monitor a storage grid.
+ - The misc/spacetime/ directory contains a "disk watcher" daemon
+   (startable with 'tahoe start'), which can be configured with a set
+   of HTTP URLs (pointing at the wapi '/statistics' page of a bunch of
+   storage servers), and will periodically fetch
+   disk-used/disk-available information from all the servers. It keeps
+   this information in an Axiom database (a sqlite-based library
+   available from divmod.org). The daemon computes time-averaged rates
+   of disk usage, as well as a prediction of how much time is left
+   before the grid is completely full.
 
hunk ./NEWS.rst 1206
-The misc/spacetime/ directory contains a "disk watcher" daemon (startable
-with 'tahoe start'), which can be configured with a set of HTTP URLs
-(pointing at the wapi '/statistics' page of a bunch of storage servers),
-and will periodically fetch disk-used/disk-available information from all the
-servers. It keeps this information in an Axiom database (a sqlite-based
-library available from divmod.org). The daemon computes time-averaged rates
-of disk usage, as well as a prediction of how much time is left before the
-grid is completely full.
+ - The misc/munin/ directory contains a new set of munin plugins
+   (tahoe_diskleft, tahoe_diskusage, tahoe_doomsday) which talk to the
+   disk-watcher and provide graphs of its calculations.
 
hunk ./NEWS.rst 1210
-The misc/munin/ directory contains a new set of munin plugins
-(tahoe_diskleft, tahoe_diskusage, tahoe_doomsday) which talk to the
-disk-watcher and provide graphs of its calculations.
+ - To support the disk-watcher, the Tahoe statistics component
+   (visible through the wapi at the /statistics/ URL) now includes
+   disk-used and disk-available information. Both are derived through
+   an equivalent of the unix 'df' command (i.e. they ask the kernel
+   for the number of free blocks on the partition that encloses the
+   BASEDIR/storage directory). In the future, the disk-available
+   number will be further influenced by the local storage policy: if
+   that policy says that the server should refuse new shares when less
+   than 5GB is left on the partition, then "disk-available" will
+   report zero even though the kernel sees 5GB remaining.
 
hunk ./NEWS.rst 1221
-To support the disk-watcher, the Tahoe statistics component (visible through
-the wapi at the /statistics/ URL) now includes disk-used and disk-available
-information. Both are derived through an equivalent of the unix 'df' command
-(i.e. they ask the kernel for the number of free blocks on the partition that
-encloses the BASEDIR/storage directory). In the future, the disk-available
-number will be further influenced by the local storage policy: if that policy
-says that the server should refuse new shares when less than 5GB is left on
-the partition, then "disk-available" will report zero even though the kernel
-sees 5GB remaining.
+ - The 'tahoe_overhead' munin plugin interacts with an
+   allmydata.com-specific server which reports the total of the
+   'deep-size' reports for all active user accounts, compares this
+   with the disk-watcher data, to report on overhead percentages. This
+   provides information on how much space could be recovered once
+   Tahoe implements some form of garbage collection.
 
hunk ./NEWS.rst 1228
-The 'tahoe_overhead' munin plugin interacts with an allmydata.com-specific
-server which reports the total of the 'deep-size' reports for all active user
-accounts, compares this with the disk-watcher data, to report on overhead
-percentages. This provides information on how much space could be recovered
-once Tahoe implements some form of garbage collection.
+Configuration Changes: single INI-format tahoe.cfg file
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''
 
hunk ./NEWS.rst 1231
-** Configuration Changes: single INI-format tahoe.cfg file
+- The Tahoe node is now configured with a single INI-format file,
+  named "tahoe.cfg", in the node's base directory. Most of the
+  previous multiple-separate-files are still read for backwards
+  compatibility (the embedded SSH debug server and the
+  advertised_ip_addresses files are the exceptions), but new
+  directives will only be added to tahoe.cfg . The "tahoe
+  create-client" command will create a tahoe.cfg for you, with sample
+  values commented out. (ticket `#518`_)
 
hunk ./NEWS.rst 1240
-The Tahoe node is now configured with a single INI-format file, named
-"tahoe.cfg", in the node's base directory. Most of the previous
-multiple-separate-files are still read for backwards compatibility (the
-embedded SSH debug server and the advertised_ip_addresses files are the
-exceptions), but new directives will only be added to tahoe.cfg . The "tahoe
-create-client" command will create a tahoe.cfg for you, with sample values
-commented out. (ticket #518)
+- tahoe.cfg now has controls for the foolscap "keepalive" and
+  "disconnect" timeouts (`#521`_).
 
hunk ./NEWS.rst 1243
-tahoe.cfg now has controls for the foolscap "keepalive" and "disconnect"
-timeouts (#521).
+- tahoe.cfg now has controls for the encoding parameters:
+  "shares.needed" and "shares.total" in the "[client]" section. The
+  default parameters are still 3-of-10.
 
hunk ./NEWS.rst 1247
-tahoe.cfg now has controls for the encoding parameters: "shares.needed" and
-"shares.total" in the "[client]" section. The default parameters are still
-3-of-10.
+- The inefficient storage 'sizelimit' control (which established an
+  upper bound on the amount of space that a storage server is allowed
+  to consume) has been replaced by a lightweight 'reserved_space'
+  control (which establishes a lower bound on the amount of remaining
+  space). The storage server will reject all writes that would cause
+  the remaining disk space (as measured by a '/bin/df' equivalent) to
+  drop below this value. The "[storage]reserved_space=" tahoe.cfg
+  parameter controls this setting. (note that this only affects
+  immutable shares: it is an outstanding bug that reserved_space does
+  not prevent the allocation of new mutable shares, nor does it
+  prevent the growth of existing mutable shares).
 
hunk ./NEWS.rst 1259
-The inefficient storage 'sizelimit' control (which established an upper bound
-on the amount of space that a storage server is allowed to consume) has been
-replaced by a lightweight 'reserved_space' control (which establishes a lower
-bound on the amount of remaining space). The storage server will reject all
-writes that would cause the remaining disk space (as measured by a '/bin/df'
-equivalent) to drop below this value. The "[storage]reserved_space="
-tahoe.cfg parameter controls this setting. (note that this only affects
-immutable shares: it is an outstanding bug that reserved_space does not
-prevent the allocation of new mutable shares, nor does it prevent the growth
-of existing mutable shares).
+Other Changes
+'''''''''''''
 
hunk ./NEWS.rst 1262
-** Other Changes
+- Clients now declare which versions of the protocols they
+  support. This is part of a new backwards-compatibility system:
+  http://tahoe-lafs.org/trac/tahoe/wiki/Versioning .
 
hunk ./NEWS.rst 1266
-Clients now declare which versions of the protocols they support. This is
-part of a new backwards-compatibility system:
-http://tahoe-lafs.org/trac/tahoe/wiki/Versioning .
+- The version strings for human inspection (as displayed on the
+  Welcome web page, and included in logs) now includes a platform
+  identifer (frequently including a linux distribution name, processor
+  architecture, etc).
 
hunk ./NEWS.rst 1271
-The version strings for human inspection (as displayed on the Welcome web
-page, and included in logs) now includes a platform identifer (frequently
-including a linux distribution name, processor architecture, etc).
+- Several bugs have been fixed, including one that would cause an
+  exception (in the logs) if a wapi download operation was cancelled
+  (by closing the TCP connection, or pushing the "stop" button in a
+  web browser).
 
hunk ./NEWS.rst 1276
-Several bugs have been fixed, including one that would cause an exception (in
-the logs) if a wapi download operation was cancelled (by closing the TCP
-connection, or pushing the "stop" button in a web browser).
+- Tahoe now uses Foolscap "Incidents", writing an "incident report"
+  file to logs/incidents/ each time something weird occurs. These
+  reports are available to an "incident gatherer" through the flogtool
+  command. For more details, please see the Foolscap logging
+  documentation. An incident-classifying plugin function is provided
+  in misc/incident-gatherer/classify_tahoe.py .
 
hunk ./NEWS.rst 1283
-Tahoe now uses Foolscap "Incidents", writing an "incident report" file to
-logs/incidents/ each time something weird occurs. These reports are available
-to an "incident gatherer" through the flogtool command. For more details,
-please see the Foolscap logging documentation. An incident-classifying plugin
-function is provided in misc/incident-gatherer/classify_tahoe.py .
+- If clients detect corruption in shares, they now automatically
+  report it to the server holding that share, if it is new enough to
+  accept the report.  These reports are written to files in
+  BASEDIR/storage/corruption-advisories .
 
hunk ./NEWS.rst 1288
-If clients detect corruption in shares, they now automatically report it to
-the server holding that share, if it is new enough to accept the report.
-These reports are written to files in BASEDIR/storage/corruption-advisories .
+- The 'nickname' setting is now defined to be a UTF-8 -encoded string,
+  allowing non-ascii nicknames.
 
hunk ./NEWS.rst 1291
-The 'nickname' setting is now defined to be a UTF-8 -encoded string, allowing
-non-ascii nicknames.
+- The 'tahoe start' command will now accept a --syslog argument and
+  pass it through to twistd, making it easier to launch non-Tahoe
+  nodes (like the cpu-watcher) and have them log to syslogd instead of
+  a local file. This is useful when running a Tahoe node out of a USB
+  flash drive.
 
hunk ./NEWS.rst 1297
-The 'tahoe start' command will now accept a --syslog argument and pass it
-through to twistd, making it easier to launch non-Tahoe nodes (like the
-cpu-watcher) and have them log to syslogd instead of a local file. This is
-useful when running a Tahoe node out of a USB flash drive.
+- The Mac GUI in src/allmydata/gui/ has been improved.
 
hunk ./NEWS.rst 1299
-The Mac GUI in src/allmydata/gui/ has been improved.
 
hunk ./NEWS.rst 1300
+Release 1.2.0 (2008-07-21)
+--------------------------
 
hunk ./NEWS.rst 1303
-* Release 1.2.0 (2008-07-21)
+Security
+''''''''
 
hunk ./NEWS.rst 1306
-** Security
+- This release makes the immutable-file "ciphertext hash tree"
+  mandatory.  Previous releases allowed the uploader to decide whether
+  their file would have an integrity check on the ciphertext or not. A
+  malicious uploader could use this to create a readcap that would
+  download as one file or a different one, depending upon which shares
+  the client fetched first, with no errors raised. There are other
+  integrity checks on the shares themselves, preventing a storage
+  server or other party from violating the integrity properties of the
+  read-cap: this failure was only exploitable by the uploader who
+  gives you a carefully constructed read-cap. If you download the file
+  with Tahoe 1.2.0 or later, you will not be vulnerable to this
+  problem. `#491`_
 
hunk ./NEWS.rst 1319
-This release makes the immutable-file "ciphertext hash tree" mandatory.
-Previous releases allowed the uploader to decide whether their file would
-have an integrity check on the ciphertext or not. A malicious uploader could
-use this to create a readcap that would download as one file or a different
-one, depending upon which shares the client fetched first, with no errors
-raised. There are other integrity checks on the shares themselves, preventing
-a storage server or other party from violating the integrity properties of
-the read-cap: this failure was only exploitable by the uploader who gives you
-a carefully constructed read-cap. If you download the file with Tahoe 1.2.0
-or later, you will not be vulnerable to this problem. #491
+  This change does not introduce a compatibility issue, because all
+  existing versions of Tahoe will emit the ciphertext hash tree in
+  their shares.
 
hunk ./NEWS.rst 1323
-This change does not introduce a compatibility issue, because all existing
-versions of Tahoe will emit the ciphertext hash tree in their shares.
+Dependencies
+''''''''''''
 
hunk ./NEWS.rst 1326
-** Dependencies
+- Tahoe now requires Foolscap-0.2.9 . It also requires pycryptopp 0.5
+  or newer, since earlier versions had a bug that interacted with
+  specific compiler versions that could sometimes result in incorrect
+  encryption behavior. Both packages are included in the Tahoe source
+  tarball in misc/dependencies/ , and should be built automatically
+  when necessary.
 
hunk ./NEWS.rst 1333
-Tahoe now requires Foolscap-0.2.9 . It also requires pycryptopp 0.5 or newer,
-since earlier versions had a bug that interacted with specific compiler
-versions that could sometimes result in incorrect encryption behavior. Both
-packages are included in the Tahoe source tarball in misc/dependencies/ , and
-should be built automatically when necessary.
+Web API
+'''''''
 
hunk ./NEWS.rst 1336
-** Web API
+- Web API directory pages should now contain properly-slash-terminated
+  links to other directories. They have also stopped using absolute
+  links in forms and pages (which interfered with the use of a
+  front-end load-balancing proxy).
 
hunk ./NEWS.rst 1341
-Web API directory pages should now contain properly-slash-terminated links to
-other directories. They have also stopped using absolute links in forms and
-pages (which interfered with the use of a front-end load-balancing proxy).
+- The behavior of the "Check This File" button changed, in conjunction
+  with larger internal changes to file checking/verification. The
+  button triggers an immediate check as before, but the outcome is
+  shown on its own page, and does not get stored anywhere. As a
+  result, the web directory page no longer shows historical checker
+  results.
 
hunk ./NEWS.rst 1348
-The behavior of the "Check This File" button changed, in conjunction with
-larger internal changes to file checking/verification. The button triggers an
-immediate check as before, but the outcome is shown on its own page, and does
-not get stored anywhere. As a result, the web directory page no longer shows
-historical checker results.
+- A new "Deep-Check" button has been added, which allows a user to
+  initiate a recursive check of the given directory and all files and
+  directories reachable from it. This can cause quite a bit of work,
+  and has no intermediate progress information or feedback about the
+  process. In addition, the results of the deep-check are extremely
+  limited. A later release will improve this behavior.
 
hunk ./NEWS.rst 1355
-A new "Deep-Check" button has been added, which allows a user to initiate a
-recursive check of the given directory and all files and directories
-reachable from it. This can cause quite a bit of work, and has no
-intermediate progress information or feedback about the process. In addition,
-the results of the deep-check are extremely limited. A later release will
-improve this behavior.
+- The web server's behavior with respect to non-ASCII (unicode)
+  filenames in the "GET save=true" operation has been improved. To
+  achieve maximum compatibility with variously buggy web browsers, the
+  server does not try to figure out the character set of the inbound
+  filename. It just echoes the same bytes back to the browser in the
+  Content-Disposition header. This seems to make both IE7 and Firefox
+  work correctly.
 
hunk ./NEWS.rst 1363
-The web server's behavior with respect to non-ASCII (unicode) filenames in
-the "GET save=true" operation has been improved. To achieve maximum
-compatibility with variously buggy web browsers, the server does not try to
-figure out the character set of the inbound filename. It just echoes the same
-bytes back to the browser in the Content-Disposition header. This seems to
-make both IE7 and Firefox work correctly.
+Checker/Verifier/Repairer
+'''''''''''''''''''''''''
 
hunk ./NEWS.rst 1366
-** Checker/Verifier/Repairer
+- Tahoe is slowly acquiring convenient tools to check up on file
+  health, examine existing shares for errors, and repair files that
+  are not fully healthy. This release adds a mutable
+  checker/verifier/repairer, although testing is very limited, and
+  there are no web interfaces to trigger repair yet. The "Check"
+  button next to each file or directory on the wapi page will perform
+  a file check, and the "deep check" button on each directory will
+  recursively check all files and directories reachable from there
+  (which may take a very long time).
 
hunk ./NEWS.rst 1376
-Tahoe is slowly acquiring convenient tools to check up on file health,
-examine existing shares for errors, and repair files that are not fully
-healthy. This release adds a mutable checker/verifier/repairer, although
-testing is very limited, and there are no web interfaces to trigger repair
-yet. The "Check" button next to each file or directory on the wapi page
-will perform a file check, and the "deep check" button on each directory will
-recursively check all files and directories reachable from there (which may
-take a very long time).
+  Future releases will improve access to this functionality.
 
hunk ./NEWS.rst 1378
-Future releases will improve access to this functionality.
+Operations/Packaging
+''''''''''''''''''''
 
hunk ./NEWS.rst 1381
-** Operations/Packaging
+- A "check-grid" script has been added, along with a Makefile
+  target. This is intended (with the help of a pre-configured node
+  directory) to check upon the health of a Tahoe grid, uploading and
+  downloading a few files. This can be used as a monitoring tool for a
+  deployed grid, to be run periodically and to signal an error if it
+  ever fails. It also helps with compatibility testing, to verify that
+  the latest Tahoe code is still able to handle files created by an
+  older version.
 
hunk ./NEWS.rst 1390
-A "check-grid" script has been added, along with a Makefile target. This is
-intended (with the help of a pre-configured node directory) to check upon the
-health of a Tahoe grid, uploading and downloading a few files. This can be
-used as a monitoring tool for a deployed grid, to be run periodically and to
-signal an error if it ever fails. It also helps with compatibility testing,
-to verify that the latest Tahoe code is still able to handle files created by
-an older version.
+- The munin plugins from misc/munin/ are now copied into any generated
+  debian packages, and are made executable (and uncompressed) so they
+  can be symlinked directly from /etc/munin/plugins/ .
 
hunk ./NEWS.rst 1394
-The munin plugins from misc/munin/ are now copied into any generated debian
-packages, and are made executable (and uncompressed) so they can be symlinked
-directly from /etc/munin/plugins/ .
+- Ubuntu "Hardy" was added as a supported debian platform, with a
+  Makefile target to produce hardy .deb packages. Some notes have been
+  added to docs/debian.txt about building Tahoe on a debian/ubuntu
+  system.
 
hunk ./NEWS.rst 1399
-Ubuntu "Hardy" was added as a supported debian platform, with a Makefile
-target to produce hardy .deb packages. Some notes have been added to
-docs/debian.txt about building Tahoe on a debian/ubuntu system.
+- Storage servers now measure operation rates and
+  latency-per-operation, and provides results through the /statistics
+  web page as well as the stats gatherer. Munin plugins have been
+  added to match.
 
hunk ./NEWS.rst 1404
-Storage servers now measure operation rates and latency-per-operation, and
-provides results through the /statistics web page as well as the stats
-gatherer. Munin plugins have been added to match.
+Other
+'''''
 
hunk ./NEWS.rst 1407
-** Other
+- Tahoe nodes now use Foolscap "incident logging" to record unusual
+  events to their NODEDIR/logs/incidents/ directory. These incident
+  files can be examined by Foolscap logging tools, or delivered to an
+  external log-gatherer for further analysis. Note that Tahoe now
+  requires Foolscap-0.2.9, since 0.2.8 had a bug that complained about
+  "OSError: File exists" when trying to create the incidents/
+  directory for a second time.
 
hunk ./NEWS.rst 1415
-Tahoe nodes now use Foolscap "incident logging" to record unusual events to
-their NODEDIR/logs/incidents/ directory. These incident files can be examined
-by Foolscap logging tools, or delivered to an external log-gatherer for
-further analysis. Note that Tahoe now requires Foolscap-0.2.9, since 0.2.8
-had a bug that complained about "OSError: File exists" when trying to create
-the incidents/ directory for a second time.
+- If no servers are available when retrieving a mutable file (like a
+  directory), the node now reports an error instead of hanging
+  forever. Earlier releases would not only hang (causing the wapi
+  directory listing to get stuck half-way through), but the internal
+  dirnode serialization would cause all subsequent attempts to
+  retrieve or modify the same directory to hang as well. `#463`_
 
hunk ./NEWS.rst 1422
-If no servers are available when retrieving a mutable file (like a
-directory), the node now reports an error instead of hanging forever. Earlier
-releases would not only hang (causing the wapi directory listing to get
-stuck half-way through), but the internal dirnode serialization would cause
-all subsequent attempts to retrieve or modify the same directory to hang as
-well. #463
+- A minor internal exception (reported in logs/twistd.log, in the
+  "stopProducing" method) was fixed, which complained about
+  "self._paused_at not defined" whenever a file download was stopped
+  from the web browser end.
 
hunk ./NEWS.rst 1427
-A minor internal exception (reported in logs/twistd.log, in the
-"stopProducing" method) was fixed, which complained about "self._paused_at
-not defined" whenever a file download was stopped from the web browser end.
 
hunk ./NEWS.rst 1428
+Release 1.1.0 (2008-06-11)
+--------------------------
 
hunk ./NEWS.rst 1431
-* Release 1.1.0 (2008-06-11)
+CLI: new "alias" model
+''''''''''''''''''''''
 
hunk ./NEWS.rst 1434
-** CLI: new "alias" model
+- The new CLI code uses an scp/rsync -like interface, in which
+  directories in the Tahoe storage grid are referenced by a
+  colon-suffixed alias. The new commands look like:
 
hunk ./NEWS.rst 1438
-The new CLI code uses an scp/rsync -like interface, in which directories in
-the Tahoe storage grid are referenced by a colon-suffixed alias. The new
-commands look like:
- tahoe cp local.txt tahoe:virtual.txt
- tahoe ls work:subdir
+ - tahoe cp local.txt tahoe:virtual.txt
+ - tahoe ls work:subdir
 
hunk ./NEWS.rst 1441
-More functionality is available through the CLI: creating unlinked files and
-directories, recursive copy in or out of the storage grid, hardlinks, and
-retrieving the raw read- or write- caps through the 'ls' command. Please read
-docs/CLI.txt for complete details.
+- More functionality is available through the CLI: creating unlinked
+  files and directories, recursive copy in or out of the storage grid,
+  hardlinks, and retrieving the raw read- or write- caps through the
+  'ls' command. Please read docs/CLI.txt for complete details.
 
hunk ./NEWS.rst 1446
-** wapi: new pages, new commands
+wapi: new pages, new commands
+'''''''''''''''''''''''''''''
 
hunk ./NEWS.rst 1449
-Several new pages were added to the web API:
+- Several new pages were added to the web API:
 
hunk ./NEWS.rst 1451
- /helper_status : to describe what a Helper is doing
- /statistics : reports node uptime, CPU usage, other stats
- /file : for easy file-download URLs, see #221
- /cap == /uri : future compatibility
+ - /helper_status : to describe what a Helper is doing
+ - /statistics : reports node uptime, CPU usage, other stats
+ - /file : for easy file-download URLs, see `#221`_
+ - /cap == /uri : future compatibility
 
hunk ./NEWS.rst 1456
-The localdir=/localfile= and t=download operations were removed. These
-required special configuration to enable anyways, but this feature was a
-security problem, and was mostly obviated by the new "cp -r" command.
+- The localdir=/localfile= and t=download operations were
+  removed. These required special configuration to enable anyways, but
+  this feature was a security problem, and was mostly obviated by the
+  new "cp -r" command.
 
hunk ./NEWS.rst 1461
-Several new options to the GET command were added:
+- Several new options to the GET command were added:
 
hunk ./NEWS.rst 1463
- t=deep-size : add up the size of all immutable files reachable from the directory
- t=deep-stats : return a JSON-encoded description of number of files, size
+ -  t=deep-size : add up the size of all immutable files reachable from the directory
+ -  t=deep-stats : return a JSON-encoded description of number of files, size
                 distribution, total size, etc
 
hunk ./NEWS.rst 1467
-POST is now preferred over PUT for most operations which cause side-effects.
-
-Most wapi calls now accept overwrite=, and default to overwrite=true .
+- POST is now preferred over PUT for most operations which cause
+  side-effects.
 
hunk ./NEWS.rst 1470
-"POST /uri/DIRCAP/parent/child?t=mkdir" is now the preferred API to create
-multiple directories at once, rather than ...?t=mkdir-p .
+- Most wapi calls now accept overwrite=, and default to overwrite=true
 
hunk ./NEWS.rst 1472
-PUT to a mutable file ("PUT /uri/MUTABLEFILECAP", "PUT /uri/DIRCAP/child")
-will modify the file in-place.
+- "POST /uri/DIRCAP/parent/child?t=mkdir" is now the preferred API to
+  create multiple directories at once, rather than ...?t=mkdir-p .
 
hunk ./NEWS.rst 1475
-** more munin graphs in misc/munin/
+- PUT to a mutable file ("PUT /uri/MUTABLEFILECAP", "PUT
+  /uri/DIRCAP/child") will modify the file in-place.
 
hunk ./NEWS.rst 1478
-  tahoe-introstats
-  tahoe-rootdir-space
-  tahoe_estimate_files
-  mutable files published/retrieved
-  tahoe_cpu_watcher
-  tahoe_spacetime
+- more munin graphs in misc/munin/
 
hunk ./NEWS.rst 1480
-** New Dependencies
+ - tahoe-introstats
+ - tahoe-rootdir-space
+ - tahoe_estimate_files
+ - mutable files published/retrieved
+ - tahoe_cpu_watcher
+ - tahoe_spacetime
 
hunk ./NEWS.rst 1487
-  zfec 1.1.0
-  foolscap 0.2.8
-  pycryptopp 0.5
-  setuptools (now required at runtime)
+New Dependencies
+''''''''''''''''
+-  zfec 1.1.0
+-  foolscap 0.2.8
+-  pycryptopp 0.5
+-  setuptools (now required at runtime)
 
hunk ./NEWS.rst 1494
-** New Mutable-File Code
+New Mutable-File Code
+'''''''''''''''''''''
 
hunk ./NEWS.rst 1497
-The mutable-file handling code (mostly used for directories) has been
-completely rewritten. The new scheme has a better API (with a modify()
-method) and is less likely to lose data when several uncoordinated writers
-change a file at the same time.
+- The mutable-file handling code (mostly used for directories) has
+  been completely rewritten. The new scheme has a better API (with a
+  modify() method) and is less likely to lose data when several
+  uncoordinated writers change a file at the same time.
 
hunk ./NEWS.rst 1502
-In addition, a single Tahoe process will coordinate its own writes. If you
-make two concurrent directory-modifying wapi calls to a single tahoe node,
-it will internally make one of them wait for the other to complete. This
-prevents auto-collision (#391).
+- In addition, a single Tahoe process will coordinate its own
+  writes. If you make two concurrent directory-modifying wapi calls to
+  a single tahoe node, it will internally make one of them wait for
+  the other to complete. This prevents auto-collision (`#391`_).
 
hunk ./NEWS.rst 1507
-The new mutable-file code also detects errors during publish better. Earlier
-releases might believe that a mutable file was published when in fact it
-failed.
+- The new mutable-file code also detects errors during publish
+  better. Earlier releases might believe that a mutable file was
+  published when in fact it failed.
 
hunk ./NEWS.rst 1511
-** other features
+other features
+''''''''''''''
 
hunk ./NEWS.rst 1514
-The node now monitors its own CPU usage, as a percentage, measured every 60
-seconds. 1/5/15 minute moving averages are available on the /statistics web
-page and via the stats-gathering interface.
+- The node now monitors its own CPU usage, as a percentage, measured
+  every 60 seconds. 1/5/15 minute moving averages are available on the
+  /statistics web page and via the stats-gathering interface.
 
hunk ./NEWS.rst 1518
-Clients now accelerate reconnection to all servers after being offline
-(#374). When a client is offline for a long time, it scales back reconnection
-attempts to approximately once per hour, so it may take a while to make the
-first attempt, but once any attempt succeeds, the other server connections
-will be retried immediately.
+- Clients now accelerate reconnection to all servers after being
+  offline (`#374`_). When a client is offline for a long time, it
+  scales back reconnection attempts to approximately once per hour, so
+  it may take a while to make the first attempt, but once any attempt
+  succeeds, the other server connections will be retried immediately.
 
hunk ./NEWS.rst 1524
-A new "offloaded KeyGenerator" facility can be configured, to move RSA key
-generation out from, say, a wapi node, into a separate process. RSA keys
-can take several seconds to create, and so a wapi node which is being used
-for directory creation will be unavailable for anything else during this
-time. The Key Generator process will pre-compute a small pool of keys, to
-speed things up further. This also takes better advantage of multi-core CPUs,
-or SMP hosts.
+- A new "offloaded KeyGenerator" facility can be configured, to move
+  RSA key generation out from, say, a wapi node, into a separate
+  process. RSA keys can take several seconds to create, and so a wapi
+  node which is being used for directory creation will be unavailable
+  for anything else during this time. The Key Generator process will
+  pre-compute a small pool of keys, to speed things up further. This
+  also takes better advantage of multi-core CPUs, or SMP hosts.
 
hunk ./NEWS.rst 1532
-The node will only use a potentially-slow "du -s" command at startup (to
-measure how much space has been used) if the "sizelimit" parameter has been
-configured (to limit how much space is used). Large storage servers should
-turn off sizelimit until a later release improves the space-management code,
-since "du -s" on a terabyte filesystem can take hours.
+- The node will only use a potentially-slow "du -s" command at startup
+  (to measure how much space has been used) if the "sizelimit"
+  parameter has been configured (to limit how much space is
+  used). Large storage servers should turn off sizelimit until a later
+  release improves the space-management code, since "du -s" on a
+  terabyte filesystem can take hours.
 
hunk ./NEWS.rst 1539
-The Introducer now allows new announcements to replace old ones, to avoid
-buildups of obsolete announcements.
+- The Introducer now allows new announcements to replace old ones, to
+  avoid buildups of obsolete announcements.
 
hunk ./NEWS.rst 1542
-Immutable files are limited to about 12GiB (when using the default 3-of-10
-encoding), because larger files would be corrupted by the four-byte
-share-size field on the storage servers (#439). A later release will remove
-this limit. Earlier releases would allow >12GiB uploads, but the resulting
-file would be unretrievable.
+- Immutable files are limited to about 12GiB (when using the default
+  3-of-10 encoding), because larger files would be corrupted by the
+  four-byte share-size field on the storage servers (`#439`_). A later
+  release will remove this limit. Earlier releases would allow >12GiB
+  uploads, but the resulting file would be unretrievable.
 
hunk ./NEWS.rst 1548
-The docs/ directory has been rearranged, with old docs put in
-docs/historical/ and not-yet-implemented ones in docs/proposed/ .
+- The docs/ directory has been rearranged, with old docs put in
+  docs/historical/ and not-yet-implemented ones in docs/proposed/ .
 
hunk ./NEWS.rst 1551
-The Mac OS-X FUSE plugin has a significant bug fix: earlier versions would
-corrupt writes that used seek() instead of writing the file in linear order.
-The rsync tool is known to perform writes in this order. This has been fixed.
+- The Mac OS-X FUSE plugin has a significant bug fix: earlier versions
+  would corrupt writes that used seek() instead of writing the file in
+  linear order.  The rsync tool is known to perform writes in this
+  order. This has been fixed.
replace ./docs/how_to_make_a_tahoe-lafs_release.rst [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./misc/debian/rules.sid [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./misc/debian_helpers/etch/debian/rules [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./misc/debian_helpers/lenny/debian/rules [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./misc/debian_helpers/sid/debian/rules [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./relnotes.txt [A-Za-z_0-9\-\.] NEWS NEWS.rst
replace ./src/allmydata/test/test_repairer.py [A-Za-z_0-9\-\.] NEWS NEWS.rst
}

Context:

[TAG allmydata-tahoe-1.8.2
warner@lothar.com**20110131020101] 
Patch bundle hash:
903f7d1562c0cc3ff327a5f00ba332dbe7bf5ca5