immutable: defensive programming: assert that the encrypted readable gave you no more than the number of bytes you asked for
(There is a bug in the current DownUpConnector which can cause it to give more bytes than you asked for on one request, and then less on the next, effectively shifting some of the bytes to an earlier request, but I think this bug never gets triggered in practice.)

docs: suggest Python 2.5 -- Python 2.6 is not as well tested yet

immutable: tests: sigh, raise, again the limit of how many extra writes you can do and still pass this test
Obviously requiring the code under test to perform within some limit isn't very meaningful if we raise the limit whenever the test goes outside of it.
But I still don't want to remove the test code which measures how many writes (and, elsewhere, how many reads) a client does in order to fulfill these duties.
Let this number -- now 20 -- stand as an approximation of the inefficiency of our code divided by my mental model of how many operations are actually optimal for these duties.

immutable: tests: assert that verifier gives a clean bill of health after corruption and repair (the previous patch mistakenly did this only after deletion and repair), and also test whether deleting seven other shares and then downloading works.  Also count the number of shares stored in the local filesystem.

immutable: test: add a test after attempting to repair from corruption: does a full verify run give the file a clean bill of health?  If not, the you haven't successfully repaired it.
This will make the repairer tests more consistent -- less accidentally passing due to getting lucky.

immutable: tests: put shares back to their pristine condition in between each test of corrupting-and-repairing them
This is important, because if the repairer doesn't completely repair all kinds of corruption (as the current one doesn't), then the successive tests get messed up by assuming that the shares were uncorrupted when the test first set about to corrupt them.

upload: add a think-of-the-compatibility note to UploadResults

helper #609: uploading client should ignore old helper's UploadResults, which were in a different format

test_runner: skip all spawnProcess-using tests on cygwin, since spawnProcess just hangs forever

test_runner.py: revert the CreateNode section to using runner() inline, rather than spawning a process, to get more precise coverage

storage #596: announce 'tolerates-immutable-read-overrun' to the version announcement, to indicate that a read() on an immutable share where offset+length is beyond the end of the file will return a truncated string instead of raising an exception

test_upload: add test of maximum-immutable-share-size, to complete the last item of #538

docs/specifications: add an outline of the spec documents we'd like to have some day

test_cli.Backup: capture stderr when sqlite is unavailable

docs: add mac/README.txt to explain the first few basic facts about what the files are in this directory

test_repairer: wrap comments to 80cols, my laptop does not have a wide screen. No functional changes.

immutable/checker: wrap comments to 80cols, my laptop does not have a wide screen. No functional changes.

test/common.py: in share-layout-reading code, use '>L' consistently, since '>l' doesn't specify the signedness and the windows tests appear to be failing with an endianness-like problem (version==0x01000000). Also use binary mode when editing sharefiles

test_cli: increase timeout on test_backup, since our dapper buildslave is really slow

backupdb.py: catch OperationalError on duplicate-insert too, since pysqlite2 on dapper raises it instead of IntegrityError

test_backupdb.py: reset the check-timers after one step, otherwise a slow host can false-fail

NEWS: announce the #598 'tahoe backup' command

docs/CLI: document 'tahoe backup'

test_cli.backup: oops, fix test to work even when sqlite is unavailable

#598: add cli+backupdb tests, improve user display, update docs, move docs out of proposed/

#598: add backupdb to 'tahoe backup' command, enable it by default

add sqlite-based backupdb, for #598 and others (including 'tahoe cp'). Not enabled yet.

setup: require new bundled setuptools-0.6c12dev

setup: bundle setuptools-0.6c12dev (our own toothpick of setuptools) this version completes my patch to fix http://bugs.python.org/setuptools/issue54 , which is necessary for tahoe to build with --prefix=support without doing a lot of PYTHONPATH gymnastics around the call to setup.py

setup: remove old bundled setuptools-0.6c11dev (our own toothpick of setuptools)

setup: add a case to execute "python .../twistd.py" if "twistd" is not found

doc: specify Python >= 2.4.2

setup: merge recent patches that change the set of bundled tools in misc/dependencies/

setup: bundle new setuptools_trial

setup: remove old bundled setuptools_trial

setup: bundle new setuptools_darcs

setup: remove old bundled setuptools_darcs

roll back the upgrade of the bundled setuptools_trial from 0.5 to 0.5.1
Upgrading setuptools trial in that way leads to a very tricky problem in setuptools's handling of recursive installation of the build-time dependencies of build-time dependencies...

rolling back:

Tue Feb  3 22:17:18 MST 2009  zooko@zooko.com
  * setup: bundle new setuptools_trial-0.5.1

    A ./misc/dependencies/setuptools_trial-0.5.1.tar
Tue Feb  3 22:17:32 MST 2009  zooko@zooko.com
  * setup: remove old bundled setuptools_trial

    R ./misc/dependencies/setuptools_trial-0.5.tar

setup: remove a couple of horrible work-arounds in setup.py now that we rely on our own toothpick of setuptools which fixes those issues
also specify that we need our latest revision (11dev) of our toothpick of setuptools
also *always* setup_require setuptools_darcs at module import time.  Formerly we added setup_require setuptools_darcs only if the PKG-INFO file were not already created.  There is some weird, irreproducible bug to do with setuptool_darcs, and I guess that the fact that whether it is required or not depends on that autogenerated file might have something to do with it.  Anyway, this is simpler.

setup: remove old bundled setuptools_trial

setup: bundle new setuptools_trial-0.5.1

setup: bundle new setuptools_darcs-1.2.5

setup: remove old bundled setuptools_darcs

setup: remove bundled darcsver in gzipped format

setup: bundle darcsver in ungzipped format

docs: mention issues using flogtool on Windows

webapi: add verifycap (spelled 'verify_url') to the t=json output on files and directories. Closes #559.

setup: stop trying to add specific dirs to site-dirs to work-around setuptools #17

setup: require and automatically use setuptools-0.6c11dev (our own toothpick of setuptools) which is bundled

setup: remove old bundled setuptools-0.6c10dev (our own toothpick of setuptools)

setup: bundle setuptools-0.6c11dev (our own toothpick of setuptools)
Hopefully this one fixes the issue with easy_install not searching the sys.path for packages that were requested to be installed, (setuptools #17), thus allowing us to do away with the "--site-dirs=" kludges, which are currently breaking some of our buildbots.

CLI: tahoe_check: stop escaping the JSON output when using --raw

#598: first cut of 'tahoe backup' command: no backupdb, but yes shared-unchanged-directories and Archives/TIMESTAMP and Latest/

CLI: move node-url -should-end-in-slash code into a common place, so other tools can rely upon it later

tahoe_ls: CLI command should return rc=0, not None

setup: add site-dirs for Debian and for some (?) Mac OS X

misc/dependencies: update setuptools_trial from 0.4 to 0.5

.darcs-boringfile: ignore bin/tahoe and bin/tahoe-script.py, since both are now generated

Makefile: fix 'clean' target to remove bin/tahoe and bin/tahoe-script.py, since both are now generated

storage: disable test_large_share again: my linux laptop has less than 4 GiB free

web/directory: add a link from readwrite directories to a read-only version, and fix the 'SI=xxx' header to actually use the storage index, not the writekey

uri: add abbrev_si() method, which returns the abbreviated storage index

setup: make sure you use darcsver whenever you are going to run trial
This fixes the bug Brian had where he ran "python ./setup.py trial" and the allmydata-tahoe version number came out as 0.0.0.

setup: require setuptools_trial >= 0.5, and delegate to it the job of deciding which Twisted reactor to use for the current platform

Makefile: use 'setup.py test' for test/quicktest targets (instead of
'setup.py trial'). 'setup.py trial' clobbers the tahoe .egg's PKG-INFO
"Version:" field (resetting it to 0.0.0), possibly because it isn't invoking
the darcsver subcommand that 'setup.py test' does before it runs the 'trial'
subcommand.

This slows down quicktest by another couple of seconds (see #591) and adds
more noise to its output, but without this change, 'make test' and 'make
quicktest' fail on test_runner (which spawns bin/tahoe as a subprocess, and
with a mangled Version:, the setuptools-based entry point script refuses to
recognize our source tree as a usable version of Tahoe).

Makefile: remove the obsolete stats-gatherer-run target

setup: remove the "build three times in a row" kludge now that #229 is fixed, and spell build "build" instead of "build_tahoe"

setup: require darcsver >= 1.2.0 and rely exclusively on darcsver to set the version string

setup: add new bundled darcsver-1.2.0

setup: remove old bundled darcsver-1.1.8

setup: add doc explaining why we set zip_safe=False

setup: setup.cfg aliases get expanded only once, so put everything you want to happen during the "test" step in the alias

setup: invoke darcsver whenever doing an sdist

setup: more verbose assertion failure in test_runner

setup: subclass setuptools.Command instead of distutils Command
There's almost no difference between them, but let's be consistent try to use the setuptools API as it was intended.

setup: temporarily comment-out the horrible kludge to work-around setuptools #17, while I figure out how to solve it better

setup: always create a support dir and populate it with a site-packages and add same to the PYTHONPATH, just in case someone is going to do "build", "develop", or "test" or something else which triggers a build
I think there must be a much better solution for this -- probably to fix setuptools #54 and ship our own fork of setuptools and rely on it.

setup: if any of "build", "develop", or "test" appear in the sys.argv then that means we'll be doing a develop, so add the workarounds for setuptools #17 in any case
I think there must be a much better solution for this -- probably to fix setuptools #17 and ship our own fork of setuptools and rely on it.

setup: add metadata indicating compatibility with python 2.6

setup: a new improved way to create tahoe executables
Create the 'tahoe-script.py' file under the 'bin' directory. The 'tahoe-script.py' file is exactly the same as the 'tahoe-script.template' script except that the shebang line is rewritten to use our sys.executable for the interpreter. On Windows, create a tahoe.exe will execute it.  On non-Windows, make a symlink to it from 'tahoe'.  The tahoe.exe will be copied from the setuptools egg's cli.exe and this will work from a zip-safe and non-zip-safe setuptools egg.

storage: enable the test of a share larger than 2 GiB; this will probably be too expensive on Mac OS X, but I think it won't be on all the other platforms ; I will probably set it to SkipTest if the sys.platform is Mac after seeing the results of this buildbot run

setup: bundle darcsver-1.1.8

setup: remove old bundled dependency darcsver-1.1.5

CLI: fix examples in tahoe put --help

trivial: remove unused imports noticed by pyflakes

setup: fix test_runner to invoke bin/tahoe.exe instead of bin/tahoe if on Windows (this is what happens when a user invokes bin/tahoe on Windows)

setup: fix test_runner to assert that lines which are output to stderr must end with a punctuation mark (apparently re.search("x$", "x\r\n") does not match.  :-()

setup: fix test_runner.RunNode.test_baddir -- it was left incomplete and broken by a recent patch

setup: hack the sys.argv to set poll reactor if "python ./setup.py test" in addition to if "python ./setup.py trial"; remove another hack which has been moved setup.cfg; remove setup_requires Twisted since now we actually setup_require setuptools_trial and it install_requires Twisted.

setup: go ahead and check for noise in test_client_no_noise

setup: always run "build" before running "test"

setup: add a test for a warning message from importing nevow, marked as TODO, comment-out the assertion of no-noise inside other test_runner tests

setup: always run build_tahoe before running tests

diskwatcher: cache growth results (which take 30s to generate) for 3 minutes, to help munin, which invokes it 6 times in a row every 5 minutes

make streaming-manifest stop doing work after the HTTP connection is dropped

setup: sys.exit() raises a SystemExit exception on Python 2.4 on Solaris -- fix it so that bin/tahoe doesn't interpret this as its brother having been non-executable

setup: find a "bin/tahoe" executable to test based on allmydata.__file__ instead of based on the CWD
This means that the tests still work if you are executing them from a CWD other than the src dir -- *if* the "bin/tahoe" is found at os.path.dirname(os.path.dirname(os.path.dirname(allmydata.__file__))).
If no file is found at that location, then just skip the tests of executing the "tahoe" executable, because we don't want to accidentally run those tests against an executable from a different version of tahoe.

rollback the #591 fix, since it breaks quicktest entirely

#509: remove non-streaming 'tahoe manifest' CLI form

CLI.txt: improve docs on 'tahoe manifest' to cover --verify-cap, --repair-cap, and streaming JSON