Thu, 20 Dec 2012 12:17:44 +0100 bundlerepo: use _cacheabletip mechanism in bundlerepo
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 12:17:44 +0100] rev 18115
bundlerepo: use _cacheabletip mechanism in bundlerepo Instead of preventing any cache write we allow writing cache for all content of the original repo. The motivation for this change is to drop the custom _writebranchcache of bundlerepo to help extraction of the branchmap logic out of localrepo.
Thu, 20 Dec 2012 13:23:29 +0100 branchmap: merge _branchtags into updatebranchcache
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 13:23:29 +0100] rev 18114
branchmap: merge _branchtags into updatebranchcache Now that nobody overwrite it, there is no reasons for `_branchtags` to remains separated from `updatebranchcache`.
Wed, 19 Dec 2012 17:39:49 +0100 branchmap: factorise access to changelog in updatebranchcache
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 17:39:49 +0100] rev 18113
branchmap: factorise access to changelog in updatebranchcache This prepares merge of `updatebranchcache` and `_branchtags`.
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`
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip