Thu, 20 Dec 2012 11:52:50 +0100 branchmap: simplify _branchtags using a new _cacheabletip method
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Dec 2012 11:52:50 +0100] rev 18112
branchmap: simplify _branchtags using a new _cacheabletip method The current _branchtags method is a remnant of an older, much larger function. Its only remaining role is to help MQ to alter the version of branchcache we store on disk. As MQ mutates the repository it ensures persistent cache does not contain anything it is likely to alter. This changeset makes explicit the stable vs volatile part of repository and reduces the MQ specific code to the computation of this limit. The main _branchtags code now handles this possible limit in all cases. This will help to extract the branchmap logic from the repository. The new code of _branchtags is a bit duplicated, but as I expect major refactoring of this section I'm not keen to setup factorisation function here.
Thu, 20 Dec 2012 21:26:30 +0100 hook: disable demandimport before importing hooks
Dirkjan Ochtman <dirkjan@ochtman.nl> [Thu, 20 Dec 2012 21:26:30 +0100] rev 18111
hook: disable demandimport before importing hooks This solved an obscure bug for me. In upgrading Distribute on the server, a patch was added to has a try: import a except ImportError thing that's only supposed to work with Python 3.3. I'm using 2.7. My hook failed with an ImportError because of this. It seems kind of sensible to turn off demandimport before importing the hook, since the except ImportError pattern is used quite a bit in Python code (including in other Distribute code).
Thu, 20 Dec 2012 15:18:41 +0100 test-pathencode: accept --seed parameter in hex as well
Adrian Buehlmann <adrian@cadifra.com> [Thu, 20 Dec 2012 15:18:41 +0100] rev 18110
test-pathencode: accept --seed parameter in hex as well test-pathencode.py outputs the seed value in hex if it finds a deviation. This change allows to specify the seed value as a command line parameter for test-pathencode.py in hex as well.
Thu, 13 Dec 2012 23:37:53 +0100 subrepo: append subrepo path to subrepo error messages
Angel Ezquerra <angel.ezquerra@gmail.com> [Thu, 13 Dec 2012 23:37:53 +0100] rev 18109
subrepo: append subrepo path to subrepo error messages This change appends the subrepo path to subrepo errors. That is, when there is an error performing an operation a subrepo, rather than displaying a message such as: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! hint: did you forget to merge? use push -f to force mercurial will show: pushing subrepo MYSUBREPO to PATH searching for changes abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO) hint: did you forget to merge? use push -f to force The rationale for this change is that the current error messages make it hard for TortoiseHg (and similar tools) to tell the user which subrepo caused the push failure. The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)" multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception after the extra message is appended. The decorator will then "ignore" (i.e. just re-raise) the exception and never add the message again. A small drawback of this method is that part of the exception trace is lost when the exception is catched and re-raised by the annotatesubrepoerror decorator. Also, because the state() function already printed the subrepo path when it threw an error, that error has been changed to avoid duplicating the subrepo path in the error message. Note that I have also updated several subrepo related tests to reflect these changes.
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip