Thu, 17 Mar 2016 00:36:01 +0000 filemerge: indicate that local/other are p1/p2
timeless <timeless@mozdev.org> [Thu, 17 Mar 2016 00:36:01 +0000] rev 28578
filemerge: indicate that local/other are p1/p2
Sat, 19 Mar 2016 10:10:09 -0700 sslutil: use preferred formatting for import syntax
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 19 Mar 2016 10:10:09 -0700] rev 28577
sslutil: use preferred formatting for import syntax
Sat, 19 Mar 2016 08:28:24 -0700 largefiles: add some docstrings
Mads Kiilerich <madski@unity3d.com> [Sat, 19 Mar 2016 08:28:24 -0700] rev 28576
largefiles: add some docstrings
Sat, 19 Mar 2016 08:27:54 -0700 largefiles: drop partial support for not having a user cache
Mads Kiilerich <madski@unity3d.com> [Sat, 19 Mar 2016 08:27:54 -0700] rev 28575
largefiles: drop partial support for not having a user cache 971c55ce03b8 introduced support for not having a "global" user cache. In the rare cases where the environment didn't provide the location of the current home directory, the usercachepath function could return None. That functionality has since bitrotten and several code paths did not correctly check for usercachepath returning None: $ HOME= XDG_CACHE_HOME= hg up --config extensions.largefiles= getting changed largefiles abort: unknown largefiles usercache location Dropping the partial support for it is thus not really a backward compatibility breaking change. Thus: consistently fail early if the usercache location is unknown. It is relevant to be able to control where the largefiles are stored and how they propagate, but that should probably be done differently. The dysfunctional code just gets in the way.
Sat, 19 Mar 2016 08:23:55 -0700 largefiles: refactor usercachepath - extract user cache path function
Mads Kiilerich <madski@unity3d.com> [Sat, 19 Mar 2016 08:23:55 -0700] rev 28574
largefiles: refactor usercachepath - extract user cache path function It is convenient to have the user cache location explicitly.
Wed, 10 Feb 2016 02:23:27 +0100 shelve: adds restoring newly created branch (issue5048) (BC)
liscju <piotr.listkiewicz@gmail.com> [Wed, 10 Feb 2016 02:23:27 +0100] rev 28573
shelve: adds restoring newly created branch (issue5048) (BC) Before this patch shelve never preserved branch information, so after applying unshelve branch was the same as it was on working copy no matter in which branch shelve took place. This patch makes bare shelving(with no files specified, without interactive,include and exclude option) remembers information if the working directory was on newly created branch ,in other words working directory was on different branch than its first parent. In this situation unshelving restores branch information to the working directory.
Mon, 07 Mar 2016 22:58:11 +0100 shelve: make non bare shelve not saving branch information in bundle
liscju <piotr.listkiewicz@gmail.com> [Mon, 07 Mar 2016 22:58:11 +0100] rev 28572
shelve: make non bare shelve not saving branch information in bundle This patch prepares for restoring newly created branch only on bare shelve later because information about new-branch will be preserved only when shelve was bare and working copy branch was different than branch of its parent. In other case information about new-branch will be gone, so unshelve will not recognise that shelve was made on new-branch and it will not restore branch information from the bundle to the working directory.
Sat, 12 Mar 2016 18:36:31 +0100 shelve: preserve newly created branch on non-bare shelve in wctx (BC)
liscju <piotr.listkiewicz@gmail.com> [Sat, 12 Mar 2016 18:36:31 +0100] rev 28571
shelve: preserve newly created branch on non-bare shelve in wctx (BC) Before this patch current branch in working context wasnt preserved after shelve, this patch makes it restore after update.
Fri, 18 Mar 2016 16:14:57 -0400 crecord: rewrite a comment about filtering patches
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 18 Mar 2016 16:14:57 -0400] rev 28570
crecord: rewrite a comment about filtering patches I couldn't parse the previous version. I think the rewrite better expresses the intent of that comment.
Thu, 17 Mar 2016 20:52:06 +0000 run-tests: teach _processoutput to handle multiple lines of churn
timeless <timeless@mozdev.org> [Thu, 17 Mar 2016 20:52:06 +0000] rev 28569
run-tests: teach _processoutput to handle multiple lines of churn Instead of treating expected output as happening in a precise order, and assuming that if a line is missing it will never happen, assume that expected output is a prioritized list of likely matching lines. This means that if: foo/bar (glob) baz/bad (glob) changes to: baz/bad foo/bar instead of generating: baz/bad foo/bar For which we've lost both (glob) markers, we will match both lines and generate: baz/bad (glob) foo/bar (glob) This retains any special annotations we have for lines.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip