Thu, 20 Dec 2012 13:49:31 -0600 tests: fix some slash-based Windows failures
Kevin Bullock <kbullock@ringworld.org> [Thu, 20 Dec 2012 13:49:31 -0600] rev 18108
tests: fix some slash-based Windows failures
Thu, 20 Dec 2012 11:40:04 -0800 inotify: on Python < 2.6, socket.error lacks errno
Bryan O'Sullivan <bryano@fb.com> [Thu, 20 Dec 2012 11:40:04 -0800] rev 18107
inotify: on Python < 2.6, socket.error lacks errno
Tue, 18 Dec 2012 01:51:08 +0100 hidden: invalidate hiddenrevs when needed
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 18 Dec 2012 01:51:08 +0100] rev 18106
hidden: invalidate hiddenrevs when needed The `hiddenrevs` cache is volatile too (It use content from `obscache`). When unsure it is invalidated when necessary. In a near future, the cache will probably be moved to `revsfiltercache`
Tue, 18 Dec 2012 02:04:37 +0100 cache: group obscache and revsfiltercache invalidation in a single function
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 18 Dec 2012 02:04:37 +0100] rev 18105
cache: group obscache and revsfiltercache invalidation in a single function Both caches are very volatile and needs invalidation on the same kind of event. revsfiltercache actually depends on the content of revsfiltercache.
Mon, 17 Dec 2012 17:27:12 +0100 clfilter: use filtering in `visibleheads`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Dec 2012 17:27:12 +0100] rev 18104
clfilter: use filtering in `visibleheads` This is the second real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on `heads`function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.
Mon, 17 Dec 2012 17:42:34 +0100 clfilter: use filtering in `visiblebranchmap`
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 17:42:34 +0100] rev 18103
clfilter: use filtering in `visiblebranchmap` Here is the first real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on branchmap function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.
Mon, 17 Dec 2012 17:12:02 +0100 clfilter: introduce a "unserver" filtering mode
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 17:12:02 +0100] rev 18102
clfilter: introduce a "unserver" filtering mode This mode is for repository used as a server. It filter secret and hidden changeset out. It is put to use in later changeset.
Thu, 20 Dec 2012 17:14:07 +0100 clfilter: add a cache on repo for set of revision to filter for a given set.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Dec 2012 17:14:07 +0100] rev 18101
clfilter: add a cache on repo for set of revision to filter for a given set. Recomputing the filtered revisions at every access to changelog is far too expensive. This changeset introduce a cache for this information. This cache is hold by the repository (unfiltered repository) and invalidated when necessary. This cache is not a protected attribute (leading _) because some logic that invalidate it is not held by the local repo itself.
Thu, 20 Dec 2012 15:32:42 +0100 clfilter: add actual repo filtering mechanism
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Dec 2012 15:32:42 +0100] rev 18100
clfilter: add actual repo filtering mechanism We add a `filtered` method on repo. This method return an instance of `repoview` that behaves exactly as the original repository but with a filtered changelog attribute. Filters are identified by a "name". Planned filter are `unserved`, `hidden` and `mutable`. Filtering the repository in place what out of question as it wont not allows multiple thread to share the same repo. It would makes control of the filtering scope harder too. See the `repoview` docstring for details. A mechanism to compute filtered revision is also installed. Some caches will be installed in later commit.
Wed, 19 Dec 2012 16:56:26 -0800 inotify: pacify pestiferous pyflakes precipitously
Bryan O'Sullivan <bos@serpentine.com> [Wed, 19 Dec 2012 16:56:26 -0800] rev 18099
inotify: pacify pestiferous pyflakes precipitously
Wed, 19 Dec 2012 10:45:40 -0800 tests: make test-inotify-issue1208.t disappear
Bryan O'Sullivan <bryano@fb.com> [Wed, 19 Dec 2012 10:45:40 -0800] rev 18098
tests: make test-inotify-issue1208.t disappear
Tue, 18 Dec 2012 17:15:13 -0800 posix: move server side of unix domain sockets out of inotify
Bryan O'Sullivan <bryano@fb.com> [Tue, 18 Dec 2012 17:15:13 -0800] rev 18097
posix: move server side of unix domain sockets out of inotify We also turn the unix domain socket into a class, so that we have a sensible place to hang its logically related attributes and behaviour. We'll shortly want to reuse this in other code.
Tue, 18 Dec 2012 17:33:32 -0800 inotify: don't fall over just because of a dangling symlink
Bryan O'Sullivan <bryano@fb.com> [Tue, 18 Dec 2012 17:33:32 -0800] rev 18096
inotify: don't fall over just because of a dangling symlink Previously, the inotify server failed to start if .hg/inotify.sock was a symlink that pointed to a non-existent path. This behaviour does not seem to make any sense. Now, if we encounter a broken symlink, we unlink it and continue.
Wed, 19 Dec 2012 10:40:34 -0800 test-inotify: test symlink indirection for unix sockets
Bryan O'Sullivan <bryano@fb.com> [Wed, 19 Dec 2012 10:40:34 -0800] rev 18095
test-inotify: test symlink indirection for unix sockets The inotify code performs a delicate dance to work around the 108-byte limit on unix domain socket path names on Linux. This change sets us up to safely refactor that code without breaking it. (It is redundant with part of test-inotify-issue1208.t, but we will shortly make that test go away.)
Wed, 19 Dec 2012 10:02:43 +0100 test-pathencode: compare current pathencoding implementations
Adrian Buehlmann <adrian@cadifra.com> [Wed, 19 Dec 2012 10:02:43 +0100] rev 18094
test-pathencode: compare current pathencoding implementations We already have two implementations of the pathencoding (C and Python) and this test can perfectly well be used to probabilistically test them instead of just wasting CPU cycles and test time.
(0) -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 +30000 tip