statichttprepo: handle remote not supporting Range headers - If remote does not support Range header, 200 is answered instead of 206. The HTTPRangeHandler left these responses unchanged, so the data has to be sliced by the receiver. - httprangereader file pointer was not updated.

convert: better feedback when filtering out empty revisions Original patch by Herbert Griebel <herbertg@gmx.at>

inotify: server: use a common 'pollable' interface for server & repowatcher Mainly for documentation purposes: it easily explains the role of handle_event and handle_timeout, and why both server & repowatcher implement those methods.

inotify: process all inotify events in one batch When several inotify events happen, we don't have to process each event separately, calling everytime repowatcher.read_events() to fetch events from the underlying watcher: it is sufficient to call once read_events, to fetch all the events from the watcher.

inotify: rename handle_event to handle_pollevent to avoid confusion event here refers to poll events, and are different from events read in server.read_events for example, where those events are inotify events.

inotify: handle_event: do not use event and fd parameters. event is particularly confusing given the context (is it an inotify event? a polling event?) and is never used. Remove it. fd has very little use, and it gives the false impression that event handling depends on fd. It's wrong: the same behavior is triggered, for all events.

inotify: use a decorator instead of dispatching calls

inotify: do not defer inotify events processing Doing a part of the event processing and deferring the rest is a bad habit: it complexifies the code, and it does not respect event ordering! Moreover, there is already a timeout handling, so that inotify events are only processed when a treshold is exceeded: there is no requirement to delay anymore the events processing.

inotify: do not recurse in handle_timeout(): call it explicitely, not in scan() When in handle_timeout, scan() is called when a repertory is created/modified. But the first line of scan calls handle_timeout. This had the consequence of calling recursively handle_timeout: * several calls to read_events (but only the first one retrieves events) * every time that an event is queued for a deferred action, the next time that scan() is called, handle_timeout is called, the event queue is treated, even if all the events haven't been read/queued yet. This could lead to inconsistencies

i18n-da: typo