- Sep 30, 2015
-
-
Matt Mackall authored
-
- Jun 03, 2015
-
-
Steve Borho authored
This makes the root install folder (on Windows) nice and tidy. The only files left in the root folder are: hg.exe python27.dll COPYING.rtf ReadMe.html the last of which was probably out-of-date 7 years ago
-
- May 15, 2015
-
-
Matt Mackall authored
This will raise a syntax error for people who attempt to use Py2.4, but that's already going to fail and we have no way to keep other 2.6isms from creeping in since we've removed the check-code rules and the buildbot.
-
- May 14, 2015
-
-
Adrian Buehlmann authored
-
Adrian Buehlmann authored
-
Adrian Buehlmann authored
see e1fb276d4619
-
- Apr 12, 2015
-
-
Augie Fackler authored
-
- May 09, 2015
-
-
Pierre-Yves David authored
The last blocker for dropping Python 2.4 was Centos 5. We now provide our own Mercurial package for Centos 5 with a bundled Python2.7. I'm therefore happy to officially drop compatibility with Python 2.4 (and Python 2.5 that nobody really cares about). This open the season for code cleanup. It is war's prize to take all vantage.
-
- Apr 12, 2015
-
-
Augie Fackler authored
-
- Jan 13, 2015
-
-
Augie Fackler authored
This lets us iterate manifests in order, but do a _lot_ less work in the common case when we only care about a few manifest entries. Many thanks to Mike Edgar for reviewing this in advance of it going out to the list, which caught many things I missed. This version of the patch includes C89 fixes from Sean Farley and many correctness/efficiency cleanups from Martin von Zweigbergk. Thanks to both!
-
- Feb 22, 2015
-
-
Joan Massich authored
These extensions are slower on pypy because pypy has a JIT compiler. And also, they often do not compile (it depends on the pypy configuration).
-
- Mar 02, 2015
-
-
Jesus Cea authored
Many files and translations have an outdated copyright date. Change that to the correct "2005-2015" dates.
-
- Dec 24, 2014
-
-
Ludovic Chabant authored
Some Python installations like the ones available from the optware project for the Synology DiskStation NASes don't have that package, which means running the setup script will crash and exit right away. Instead, we now just use an empty/fake class for the HackedMingw32CCompiler, which we likely won't use anyway.
-
- Dec 12, 2014
-
-
Siddharth Agarwal authored
For a Mercurial built on the merge from stable into default right after 3.2.2 was released -- 19ebd2f88fc7 -- the version number produced was "3.2.2+4". This is potentially misleading, since in reality the built Mercurial includes many more changes compared to 3.2.2. Change the versioning scheme so that we take into consideration all the changes present in the current revision that aren't present in the latest tag. For 19ebd2f88fc7 the new versioning scheme results in a version number of "3.2.2+256". This gives users a much better idea of how many changes have actually happened since the latest release. Since changessincelatesttag is always greater than or equal to the latesttagdistance, this will produce version numbers that are always greater than or equal to the old scheme. Thus there's minimal compatibility risk.
-
Siddharth Agarwal authored
changessincelatesttag gives one a better idea of how much the code has changed since. Since changessincelatesttag is always greater than or equal to the latesttagdistance (see previous patch for why), this will always produce version numbers greater than or equal to the previous scheme.
-
- Nov 25, 2014
-
-
Jeff Sickel authored
-
- Sep 04, 2014
-
-
Mads Kiilerich authored
This helps providing a more consistent user experience on all platforms and with all packaging. The exact location of default.d depends on how Mercurial is installed and whether it is 'frozen'. The exact location should never be relevant to users and is intentionally not explained in details in the documentation. It will however always be next to the help and templates files. Note that setting HGRCPATH also disables these defaults. I don't know if that should be considered a bug or a feature.
-
- Oct 01, 2014
-
-
Kyle Lippincott authored
-
- Sep 26, 2014
-
-
Mads Kiilerich authored
This will give PKI-secure behaviour out of the box, without any configuration. Setting web.cacerts to any value or empty will disable this trick. This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which didn't have certificate validation at all.
-
- Aug 31, 2014
-
-
Mads Kiilerich authored
OS X would offer to expand the zip so the (multi file) installer inside it could be run ... but that would leave the expanded zip folder around. Instead, use a .dmg file that automatically will be mounted - that seems more common on OS X. Still, there is two levels of levels of clicking before actually launching the installer. Having a single file installer would be better ... but seems to be hard. A more feasible improvement would be some fancy layout inside the .dmg .
-
- Aug 15, 2014
-
-
Mads Kiilerich authored
This will make sure we get import errors, even if demandimport is enabled. This will also mute some pyflakes 'imported but unused' warnings.
-
- Jul 06, 2014
-
-
durin42 authored
-
- Jul 05, 2014
-
-
Alex Gaynor authored
Specifically this is observed to happen on the PyPy one gets from homebrew
-
- May 27, 2014
-
-
Matt Mackall authored
Was failing on "5.1\n".
-
- May 05, 2014
-
-
Thomas Arendsen Hein authored
"make clean" already removed __index__.py[cdo], but not the __index__.py (automatically generated by "python setup.py build_hgextindex"). "setup.py build_hgextindex" did not generate a new index if file __index__.py[cdo] already existed, because if __index__.py was removed, the compiled file containing the old information was imported and used. Generate an empty file (with a new timestamp to generate a new .py[cdo]) instead and make mercurial.extensions ignore the unset docs attribute. One of the problems was a failed test-help.t, to reproduce: $ rm hgext/__index__.py* $ echo 'docs = {"mq": "dummy"}' > hgext/__index__.py $ make test-help.t With this a "make clean" or "python setup.py build_hgextindex" helps.
-
- Apr 15, 2014
-
-
Kent Frazier authored
-
- Mar 12, 2014
-
-
durin42 authored
-
- Sep 19, 2013
-
-
durin42 authored
This should keep the file portable to both python2 and python3.
-
- Mar 12, 2014
-
-
durin42 authored
The latter are both faster and more consistent across Python 2 and 3.
-
- Mar 04, 2014
-
-
Matt Mackall authored
-
- Mar 01, 2014
-
-
Matt Mackall authored
This extension has always had correctness issues and has been unmaintained for years. It is now removed in favor of the third-party hgwatchman which is maintained and appears to be correct. Users with inotify enabled in their config files will fall back to standard status performance.
-
- Sep 13, 2013
-
-
Wei, Elson authored
Before, if mercurial/util.h was modified but *.c wasn't, no extension was rebuilt.
-
- Apr 12, 2013
-
-
kiilerix authored
-
- Apr 10, 2013
-
-
Bryan O'Sullivan authored
This is over twice as fast as the Python dirs code. Upcoming changes will nearly double its speed again. perfdirs results for a working dir with 170,000 files: Python 638 msec C 244
-
- Apr 02, 2013
-
-
Isaac Jurado authored
This modification was missing from the fa91ddfc3f36 changeset.
-
- Mar 04, 2013
-
-
Benoit Boissinot authored
Fix version detection with recent hg versions.
-
Benoit Boissinot authored
This allows updating PyPI with just 'setup.py register' (assuming the user is an owner or maintainer of the PyPI package).
-
- Nov 13, 2012
-
-
Bryan O'Sullivan authored
I just spent 1.5 days trying to debug a failing buildbot because setup.py was silently dropping the errors that were being printed by in-place hg.
-
- Aug 07, 2012
-
-
Adrian Buehlmann authored
We give up using CPython's PythonXX.lib import libraries (and Python.h), and now "manually" call the LoadLibrary() / GetProcAddress() Windows API's instead. If there is a "hg-python" subdirectory (the canonical directory name for HackableMercurial's private Python copy) next to the hg.exe, we load the pythonXX.dll from there (feeding an absolute path to LoadLibrary) and we set Py_SetPythonHome() to that directory, so that the Python libraries are used from there as well. If there is no "hg-python" subdir found next to the hg.exe, we do not feed an absolute path to LoadLibrary. This continues to allow to find a globally installed Python DLL, as before this change - that is, without having to edit, delete, rename, or configure anything. Note that the hg.exe built is still bound to a *specific* major version of the pythonXX.dll (e.g. python27.dll). What version it is, is inferred from the version of the python interpreter that was used when calling setup.py. For example C:\python27_x86\python.exe setup.py build_hgexe -i --compiler=mingw32 builds a hg.exe (using the mingw32 tool chain) bound to (x86) Python 2.7. And C:\python27_x86\python.exe setup.py build_hgexe -i builds the same using the Microsoft C compiler/linker. (Note that the Microsoft toolchain combined with x64 CPython can be used to build an x64 hg.exe.) setup.py is changed to write the name of the pythonlib into the generated header file "mercurial/hgpythonlib.h", which is #included by exewrapper.c. For a Python 2.7 build, it for example contains: #define HGPYTHONLIB "python27" exewrapper.c then uses HGPYTHONLIB for the name of the Python dll to load. We don't want to track mercurial/hgpythonlib.h, so we add it to .hgignore.
-
- Oct 05, 2012
-
-
Bryan O'Sullivan authored
The old calculation code failed to properly identify revs that weren't tagged, leaving us with a version of "unknown" most of the time during development.
-