Martin Geisler <mg@lazybytes.net> [Sun, 24 May 2009 23:53:28 +0200] rev 8616
zsh-comp: explain how to use for non-global install
Martin Geisler <mg@lazybytes.net> [Sun, 24 May 2009 22:37:20 +0200] rev 8615
use ui instead of repo.ui when the former is in scope
Matt Mackall <mpm@selenic.com> [Sun, 24 May 2009 16:38:29 -0500] rev 8614
cmdutils: Take over glob expansion duties from util
Matt Mackall <mpm@selenic.com> [Sun, 24 May 2009 16:37:34 -0500] rev 8613
match: fix _patsplit breakage with drive letters
Patrick Mezard <pmezard@gmail.com> [Sun, 24 May 2009 18:31:01 +0200] rev 8612
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.
Patrick Mezard <pmezard@gmail.com> [Sun, 24 May 2009 18:30:59 +0200] rev 8611
convert: better feedback when filtering out empty revisions
Original patch by Herbert Griebel <herbertg@gmx.at>
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 17:09:12 +0900] rev 8610
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.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 19:26:15 +0900] rev 8609
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.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 19:22:29 +0900] rev 8608
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.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 16:54:05 +0900] rev 8607
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.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 22 May 2009 10:26:56 +0900] rev 8606
inotify: use a decorator instead of dispatching calls
Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 22 May 2009 09:57:53 +0900] rev 8605
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.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 15:55:58 +0900] rev 8604
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
Henrik Stuart <hg@hstuart.dk> [Sun, 24 May 2009 17:07:27 +0200] rev 8603
i18n-da: typo
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Sun, 24 May 2009 16:33:22 +0200] rev 8602
merge with crew