parsers: statically initializing tp_new to PyType_GenericNew is not portable As detailed on http://docs.python.org/extending/newtypes.html (quote): "In this case, we can just use the default implementation provided by the API function PyType_GenericNew(). We’d like to just assign this to the tp_new slot, but we can’t, for portability sake. On some platforms or compilers, we can’t statically initialize a structure member with a function defined in another C module, so, instead, we’ll assign the tp_new slot in the module initialization function just before calling PyType_Ready()." Fixes "gcc (GCC) 3.4.5 (mingw-vista special r3)" complaining with: mercurial/parsers.c:1096: error: initializer element is not constant mercurial/parsers.c:1096: error: (near initialization for `indexType.tp_new')

merge with stable

context: add copies method with caching

filectx: handle some other simple cases for finding merge ancestor

graft: remark on empty graft

filectx: make ancestor require actx When grafting or rebasing, we need to know the target ancestor.

pure/base85: align exception type/msg on base85.c brendan mentioned on IRC that b64decode raises a TypeError too, but while the previous exception type may be better in general, it is much easier to make it behave like the related C code and changes nothing for mercurial itself.

parsers: fix refcount bug on corrupt index When we encounter a corrupt index, we "fail" the init but our destructor still gets called. On some systems, this was causing us to attempt to decref a dangling to self->data.

subrepo: do not traceback on .hgsubstate parsing errors Note that aborting in subrepo.state() prevents "repairing" commands like revert to be issued. The user will have to edit the .hgsubstate manually (but he probably had already otherwise this would not be failing). The same behaviour already happens with invalid .hgsub entries.

subrepo: ignore blank lines in .hgsubstate (issue3424) Reported by Sebastian Krysmanski <infomail@lordb.de>