~sschwarzer/ftputil

Explicitly remove `__pycache__` under `.tox`

It seems that `find` by default doesn't recurse into "hidden"
directories and having `.tox/__pycache__` leads to problems in
`make dist`.
Remove `docs` target from `Makefile`

This is no longer supported.
Improve `README.release`
Remove Trac-specific todo items

We no longer have a version field or milestones.
Remove `make docs`

`make docs` is no longer necessary or supported. It was used to create
HTML pages from the reStructuredText files (which no longer exist).
Remove update item for `README.txt`

`README.txt` in the repository root directory has been changed to
`README.md`, and that file no longer contains version-specific
information.

There's a file `doc/README.txt`, but that just mentions where to find
the documentation now, so this file doesn't contain version-specific
information either.
Run `make patch` to update version/date
Add new release 5.0.4 to `versions` page
Add announcement for version 5.0.4
Update version to 5.0.4
Explain cache invalidation in `FTPHost.rename`
Make cache invalidation in `rename` more robust

Always invalidate the stat cache entries for source and target, even if
an exception occurs. Check the recent commits with the changes to
`rmdir` and `remove` for the rationale.

ticket: 150
Invalidate cache for source and target

In `FTPHost.rename`, invalidate the stat cache for source and target.
This is obviously important for the source, but also for the target, in
case another file system item existed at the path before the rename.

Thanks to Maxim Martynov for the bug report and patch. :-)

ticket: 150
Test cache invalidation for `FTPHost.rename`

The missing cache invalidation was reported by Maxim Martynov, and he
provided the patch in the following commit. Thanks!

ticket: 150
Set up first file for deletion

This is important if the rename fails and the file stays at its old
location.
Always invalidate the cache after attempted removal

When calling `FTPHost.rmdir` or `FTPHost.remove`, always invalidate the
stat cache for the directory or file, respectively.

If an exception occurs, the most likely cause is that the removal
failed, in which case it would be correct to keep the cache entry.
However, if the directory or file was actually deleted on the server,
but something went wrong while finishing the server/client transaction,
keeping the cache entry after the exception would be a mistake.

If we delete the cache entry even if the directory or file wasn't
removed, that shouldn't be a problem because stat queries for the
item will just retrieve the stat information from the server again
(and then we'll know for sure whether the removal succeeded).
Test `rmdir` call on existing directory
Add more integration test docstrings
Add more integration test docstrings
Reorder removal tests

Order tests according to complexity of tested methods:

- `remove` (works on file)
- `rmdir` (works on empty directory)
- `rmtree` (works on whole directory tree, whether empty or not)
Next