Sat, 30 Apr 2016 17:26:48 -0700 debian: fix lintian warning about debhelper stable
Sean Farley <sean@farley.io> [Sat, 30 Apr 2016 17:26:48 -0700] rev 29047
debian: fix lintian warning about debhelper It seems this is correct but does it work on older distros? I ran the docker-jessie rule and didn't get any warnings.
Sat, 30 Apr 2016 17:29:12 -0700 builddeb: remove chmod as lintian tells us stable
Sean Farley <sean@farley.io> [Sat, 30 Apr 2016 17:29:12 -0700] rev 29046
builddeb: remove chmod as lintian tells us It turns out we just need debian/rules to be executable, so we do just that.
Sat, 30 Apr 2016 11:51:45 -0700 builddeb: use codename in version stable
Sean Farley <sean@farley.io> [Sat, 30 Apr 2016 11:51:45 -0700] rev 29045
builddeb: use codename in version Apparently, this is needed to allow ppas to be built for multiple distros.
Sat, 30 Apr 2016 18:39:39 +0200 rebase: restrict rebase destination to the pulled set (issue5214) stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 30 Apr 2016 18:39:39 +0200] rev 29044
rebase: restrict rebase destination to the pulled set (issue5214) Before this patch, `hg pull --rebase` would be a strict sequence of `hg pull` followed by `hg rebase` if anything was pulled. Now that rebase pick his default destination the same way than merge, than `hg rebase` step would abort in the case the repo already had multiple anonymous heads (because of the ambiguity). (changed in fac3a24be50e) The intend of the user with `hg pull --rebase` is clearly to rebase on pulled content. This used to be (mostly) enforced by the former default destination for rebase, "tipmost changeset of the branch" as the tipmost would likely a changeset that just got pulled. But this intended was no longer enforced with the new defaul destination (unified with merge). This changeset makes use of the '_destspace' mechanism introduced in the previous changeset to enforce this. This partially fixes issue5214 as no change at all have been made to the new handling of the case with bookmark (unified with merge).
Sat, 30 Apr 2016 18:41:08 +0200 destutil: add the ability to specify a search space for rebase destination stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 30 Apr 2016 18:41:08 +0200] rev 29043
destutil: add the ability to specify a search space for rebase destination In the 'hg pull --rebase', we don't want to pick a rebase destination unrelated to the pull, we lay down basic infrastructure to allow such restriction on stable (before 3.8 release) in this case. See issue 5214 for details. Actual usage and test will be in the next patch.
Sat, 30 Apr 2016 09:26:47 -0700 sslutil: restore old behavior not requiring a hostname argument (issue5210) stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 30 Apr 2016 09:26:47 -0700] rev 29042
sslutil: restore old behavior not requiring a hostname argument (issue5210) This effectively backs out changeset 1fde84d42f9c. The http library behind ui.http2=true isn't specifying the hostname. It is the day before the expected 3.8 release and we don't want to ship a regression. I'll try to restore this requirement in the 3.9 release cycle as part of planned improvements to Mercurial's SSL/TLS interactions.
Thu, 28 Apr 2016 16:38:15 -0500 tests: test a variety of cache invariants stable
Matt Mackall <mpm@selenic.com> [Thu, 28 Apr 2016 16:38:15 -0500] rev 29041
tests: test a variety of cache invariants We've historically had a problem maintaining the expected invariants on our caches, especially when introducing new caches. This tests documents the invariants and exercises them across most of our existing cache files.
Thu, 28 Apr 2016 16:26:18 -0500 repoview: ignore unwritable hidden cache stable
Matt Mackall <mpm@selenic.com> [Thu, 28 Apr 2016 16:26:18 -0500] rev 29040
repoview: ignore unwritable hidden cache The atomictemp.close() file attempts to do a rename, which can fail. Moving the close inside the exception handler fixes it. This doesn't fit well with the with: pattern, as it's the finalizer that's failing.
Thu, 28 Apr 2016 15:40:43 -0500 tags: silence hgtagsfnodes reading failures stable
Matt Mackall <mpm@selenic.com> [Thu, 28 Apr 2016 15:40:43 -0500] rev 29039
tags: silence hgtagsfnodes reading failures tryread() doesn't handle "is a directory" errors and presumably others. We might not want to globally swallow such tryread errors, so we replace with our own try/except handling. An upcoming test will use directories as a portable stand-in for various bizarre circumstances that cache read/write code should be robust to.
Thu, 28 Apr 2016 15:35:54 -0500 tags: silence cache parsing errors stable
Matt Mackall <mpm@selenic.com> [Thu, 28 Apr 2016 15:35:54 -0500] rev 29038
tags: silence cache parsing errors Follow our standard STFU cache-handling pattern
Sun, 01 May 2016 00:12:56 -0300 i18n-pt_BR: synchronized with 18c1b107898e stable
Wagner Bruna <wbruna@yahoo.com> [Sun, 01 May 2016 00:12:56 -0300] rev 29037
i18n-pt_BR: synchronized with 18c1b107898e
Wed, 27 Apr 2016 01:07:40 -0700 ubuntu-xenial-ppa: add makefile rule stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 01:07:40 -0700] rev 29036
ubuntu-xenial-ppa: add makefile rule
Wed, 27 Apr 2016 01:02:56 -0700 ubuntu-wily-ppa: add makefile rule stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 01:02:56 -0700] rev 29035
ubuntu-wily-ppa: add makefile rule
Wed, 27 Apr 2016 00:27:10 -0700 ubuntu-trusty-ppa: add makefile rule stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 00:27:10 -0700] rev 29034
ubuntu-trusty-ppa: add makefile rule
Wed, 27 Apr 2016 00:18:18 -0700 ubuntu-xenial: add makefile rule to build deb stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 00:18:18 -0700] rev 29033
ubuntu-xenial: add makefile rule to build deb
Wed, 27 Apr 2016 00:10:49 -0700 ubuntu-wily: add makefile rule to build deb stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 00:10:49 -0700] rev 29032
ubuntu-wily: add makefile rule to build deb
Tue, 26 Apr 2016 23:33:17 -0700 make: turn ubuntu docker into template stable
Sean Farley <sean@farley.io> [Tue, 26 Apr 2016 23:33:17 -0700] rev 29031
make: turn ubuntu docker into template This allows us to easily add more ubuntu docker targets (which following patches will do). Also, we no longer need the mkdir command.
Wed, 27 Apr 2016 14:02:18 -0700 revsets: add docs for '%' operator stable
Sean Farley <sean@farley.io> [Wed, 27 Apr 2016 14:02:18 -0700] rev 29030
revsets: add docs for '%' operator
Wed, 27 Apr 2016 19:24:31 -0700 graft: fix printing of --continue command stable
Adam Simpkins <simpkins@fb.com> [Wed, 27 Apr 2016 19:24:31 -0700] rev 29029
graft: fix printing of --continue command Properly shell quote arguments, to avoid printing commands that won't work when run literally. For example, a date string with timestamp needs to be quoted: --date '1456953053 28800'
Fri, 29 Apr 2016 14:14:00 -0500 hghave: remove unused check for bdist_mpkg stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Fri, 29 Apr 2016 14:14:00 -0500] rev 29028
hghave: remove unused check for bdist_mpkg
Wed, 27 Apr 2016 10:20:36 -0500 osx: create a modern package including manpages stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Wed, 27 Apr 2016 10:20:36 -0500] rev 29027
osx: create a modern package including manpages Instead of using bdist_mpkg, we use the modern Apple-provided tools to build an OS X Installer package directly. This has several advantages: * Avoids bdist_mpkg which seems to be barely maintained and is hard to use. * Creates a single unified .pkg instead of a .mpkg. * The package we produce is in the modern, single-file format instead of a directory bundle that we have to zip up for download. In addition, this way of building the package now correctly: * Installs the manpages, bringing the `make osx`-generated package in line with the official Mac packages we publish on the website. * Installs files with the correct permissions instead of encoding the UID of the user who happened to build the package. Thanks to Augie for updating the test expectations.
Wed, 27 Apr 2016 11:45:55 -0400 hghave: add check for OS X packaging tools stable
Augie Fackler <augie@google.com> [Wed, 27 Apr 2016 11:45:55 -0400] rev 29026
hghave: add check for OS X packaging tools
Mon, 18 Apr 2016 23:59:55 -0400 tests: add test for Mac OS X package construction stable
Augie Fackler <augie@google.com> [Mon, 18 Apr 2016 23:59:55 -0400] rev 29025
tests: add test for Mac OS X package construction
Mon, 18 Apr 2016 23:59:28 -0400 osx: add support for keeping mpkgs stable
Augie Fackler <augie@google.com> [Mon, 18 Apr 2016 23:59:28 -0400] rev 29024
osx: add support for keeping mpkgs This is a bit of a hack, but I don't really want to mount a dmg during a test, and I don't see an option with hdiutil to take a dmg and spit out a folder, so this is what we've got for now.
Mon, 18 Apr 2016 23:57:22 -0400 osx: add support for dumping built dmg into OUTPUTDIR stable
Augie Fackler <augie@google.com> [Mon, 18 Apr 2016 23:57:22 -0400] rev 29023
osx: add support for dumping built dmg into OUTPUTDIR
Mon, 18 Apr 2016 23:55:58 -0400 hghave: add check for bdist_mpkg stable
Augie Fackler <augie@google.com> [Mon, 18 Apr 2016 23:55:58 -0400] rev 29022
hghave: add check for bdist_mpkg
Wed, 27 Apr 2016 22:45:52 -0400 verify: don't init subrepo when missing one is referenced (issue5128) (API) stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 27 Apr 2016 22:45:52 -0400] rev 29021
verify: don't init subrepo when missing one is referenced (issue5128) (API) Initializing a subrepo when one doesn't exist is the right thing to do when the parent is being updated, but in few other cases. Unfortunately, there isn't enough context in the subrepo module to distinguish this case. This same issue can be caused with other subrepo aware commands, so there is a general issue here beyond the scope of this fix. A simpler attempt I tried was to add an '_updating' boolean to localrepo, and set/clear it around the call to mergemod.update() in hg.updaterepo(). That mostly worked, but doesn't handle the case where archive will clone the subrepo if it is missing. (I vaguely recall that there may be other commands that will clone if needed like this, but certainly not all do. It seems both handy, and a bit surprising for what should be a read only operation. It might be nice if all commands did this consistently, but we probably need Angel's subrepo caching first, to not make a mess of the working directory.) I originally handled 'Exception' in order to pick up the Aborts raised in subrepo.state(), but this turns out to be unnecessary because that is called once and cached by ctx.sub() when iterating the subrepos. It was suggested in the bug discussion to skip looking at the subrepo links unless -S is specified. I don't really like that idea because missing a subrepo or (less likely, but worse) a corrupt .hgsubstate is a problem of the parent repo when checking out a revision. The -S option seems like a better fit for functionality that would recurse into each subrepo and do a full verification. Ultimately, the default value for 'allowcreate' should probably be flipped, but since the default behavior was to allow creation, this is less risky for now.
Thu, 28 Apr 2016 08:52:13 -0700 setup: detect Python DLL filename from loaded DLL stable
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 28 Apr 2016 08:52:13 -0700] rev 29020
setup: detect Python DLL filename from loaded DLL Attempting to build Mercurial from source using MinGW from msys2 on Windows produces a hg.exe that attempts to load e.g. python27.dll. MinGW prefixes its library name with "lib" and adds a period between the major and minor versions. e.g. "libpython2.7.dll." Before this patch, hg.exe files in a MinGW environment would either fail to find a Python DLL or would attempt to load a non-MinGW DLL, which would summarily explode. Either way, hg.exe wouldn't work. This patch improves the code that determines the Python DLL filename to actually use the loaded Python DLL instead of inferring it. Basically we take the handle of the loaded DLL from sys.dllhandle and call a Windows API to try to resolve that handle to a filename.
Wed, 27 Apr 2016 09:23:39 -0700 exewrapper: add .dll to LoadLibrary() argument stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 27 Apr 2016 09:23:39 -0700] rev 29019
exewrapper: add .dll to LoadLibrary() argument LoadLibrary() changes behavior depending on whether the argument passed to it contains a period. From the MSDN docs: If no file name extension is specified in the lpFileName parameter, the default library extension .dll is appended. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file. As the subsequent patch will show, some environments on Windows define their Python library as e.g. "libpython2.7.dll." The existing code would pass "libpython2.7" into LoadLibrary(). It would assume "7" was the file extension and look for a "libpython2.dll" to load. By passing ".dll" into LoadLibrary(), we force it to search for the exact basename we want, even if it contains a period.
Wed, 27 Apr 2016 14:02:54 -0700 update: correct description of --check option stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 27 Apr 2016 14:02:54 -0700] rev 29018
update: correct description of --check option The old "update across branches if no uncommitted changes" made it sound like updating across branches (with no uncommitted changes) was allowed only with this option, which was not true. Also, the option did not care whether it was linear or across branches. Instead, it checked that there were no uncommitted changes. Let's explain what it does instead of trying to suggest what happens without it.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip