Tue, 15 Jun 2010 19:49:56 -0300 osutil.c: Support for py3k added.
Renato Cunha <renatoc@gmail.com> [Tue, 15 Jun 2010 19:49:56 -0300] rev 11359
osutil.c: Support for py3k added. This patch adds support for py3k in osutil.c. This is accomplished by including a header file responsible for abstracting the API differences between python 2 and python 3. listdir_stat_type is also changed in the following way: A previous call to PyObject_HEAD_INIT is substituted to a call to PyVarObject_HEAD_INIT, which makes the object buildable in both python 2.x and 3.x without weird warnings. After testing on windows, some modifications were also made in the posixfile function, as it calls PyFile_FromFile and PyFile_SetBufSize, which are gone in py3k. In py3k the PyFile_* API is, actually a wrapper over the io module, and code has been adapted accordingly to fit py3k.
Tue, 15 Jun 2010 19:49:56 -0300 util.h: Utility macros for handling different Python APIs.
Renato Cunha <renatoc@gmail.com> [Tue, 15 Jun 2010 19:49:56 -0300] rev 11358
util.h: Utility macros for handling different Python APIs. If we are in py3k, a IS_PY3K symbol is defined. Apart from that, byte strings use the API defined in Python 2.6+ (_?PyBytes_.*). For Python < 2.6, the bytes API is defined accordingly for mercurial usage (shameless copy from bytesobject.h from Python's code). Some macros were backported from 2.6, as inspired by rPath's pycompat.h.
Wed, 16 Jun 2010 12:22:14 +0200 relink: ensure deterministic directory walk in collect
Martin Geisler <mg@aragost.com> [Wed, 16 Jun 2010 12:22:14 +0200] rev 11357
relink: ensure deterministic directory walk in collect
Wed, 16 Jun 2010 15:20:22 +0530 help: add "glossary" topic
Faheem Mitha <faheem@email.unc.edu> [Wed, 16 Jun 2010 15:20:22 +0530] rev 11356
help: add "glossary" topic Joint work with Vishakh Harikumar, Pradeepkumar Gayam, David Champion, Mark Booth, timeless, Matt Mackall, Heinrik Stuart, Greg Ward, and Martin Geisler.
Thu, 10 Jun 2010 15:35:06 +0200 relink/progress: Adding progress for collecting stage
timeless <timeless@gmail.com> [Thu, 10 Jun 2010 15:35:06 +0200] rev 11355
relink/progress: Adding progress for collecting stage
Thu, 10 Jun 2010 13:09:50 +0200 relink/progress: Adding progress for pruning stage
timeless <timeless@gmail.com> [Thu, 10 Jun 2010 13:09:50 +0200] rev 11354
relink/progress: Adding progress for pruning stage
Mon, 14 Jun 2010 16:06:52 -0400 merge: when current branch has 1 or > 2 heads, actually abort.
Greg Ward <greg-hg@gerg.ca> [Mon, 14 Jun 2010 16:06:52 -0400] rev 11353
merge: when current branch has 1 or > 2 heads, actually abort. Currently merge just prints abort-like messages to stderr and then exits with a misleading status 0 (cleverly disguised as "False"). With this change it raises Abort, just like every other fatal error.
Tue, 15 Jun 2010 16:10:32 -0400 tags: remove inactive debugging code.
Greg Ward <greg-hg@gerg.ca> [Tue, 15 Jun 2010 16:10:32 -0400] rev 11352
tags: remove inactive debugging code. It was left in just in case things went wrong with the tag cache in Mercurial 1.4, so we could easily crank up the verbosity with a one-line change. There have been no problems in 1.4 or 1.5, so it should be safe to drop this now.
Tue, 15 Jun 2010 15:02:54 -0400 tags: remove the old non-caching implementation of findglobaltags().
Greg Ward <greg-hg@gerg.ca> [Tue, 15 Jun 2010 15:02:54 -0400] rev 11351
tags: remove the old non-caching implementation of findglobaltags(). It was left behind just in case the tag cache blew up in Mercurial 1.4, so we could easily revert to the non-caching code. There have been no problems with the tag cache in 1.4 or 1.5, so it should be safe to get rid of this code now.
Tue, 15 Jun 2010 17:15:31 +0200 keyword: postpone manifest calculation in kwtemplater.overwrite
Christian Ebert <blacktrash@gmx.net> [Tue, 15 Jun 2010 17:15:31 +0200] rev 11350
keyword: postpone manifest calculation in kwtemplater.overwrite We can check for file existence in the working directory (needed in case of recording) by simply using the given context and calculate the manifest only when there are in fact candidates for expansion/shrinking.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip