The old default behaviour of hgwebdir was to maintain a list of
repositories permanently. This interacted badly with persistent
application hosting software such as WSGI containers. If a new repository
was published, it would potentially never appear in the top-level list
of repositories.
This change causes the hgwebdir configuration and list of repositories
served to be refreshed periodically (at most every 20 seconds).
If a hg repository including working directory is a reparse point (directory
symlinked or a junction point), then using os.removedirs will remove the
reparse point erroneously. This is fixed by only removing directories if they
are empty.
When performing a strip operation on a repository, it is vital that all the
truncations are performed, or that none of them are. This is done by adding
support for writing a number of entries in a single operation.
Co-contributor: Sune Foldager <cryo@cyanite.org>
Before this patch, hgwebdir suddenly showed up empty for a webdir-conf file
that was for some reason not trusted. This was previously not a problem because
the trust mechanism wasn't required for the very separate webdir-conf.
This cleans up code and allows specification of values more globally. For
example, it's now possible to specify web.contact in webdir-conf for all
repositories without a specified contact set.
Currently, Watcher is a class in inotify.linux.watcher, but it's also a class
in inotify.server . To complicate things further more, the latter has a
'watcher' attribute, an instance of the former class.
When it comes to the 'watcher' attribute of the Server class in inotify.server,
one can get quite confused: is it a Watcher object from inotify.server, or from
inotify.linux.watcher?
Changes:
* in inotify.linux.watcher : nothing
* in inotify.server :
** Watcher class is renamed to RepoWatcher
** server.watcher is renamed to server.repowatcher
RfC2822 mandates a line length limit of 998 byte + CRLF.
Python mail tools break lines at 990 byte. To prevent
that, we quoted-printable encode overly long lines.
The posixfile_nt code hits the win32 file API directly, which
essentially amounts to performing a system call for every read and
write. This is slow.
We add a C extension that lets us use a Python file object instead,
but preserve our desired POSIX-like semantics (the ability to rename
or delete a file that is being accessed).
If the C extension is not available (e.g. in a VPS environment
without a compiler), we fall back to the posixfile_nt code.
