Tue, 27 Jan 2015 10:14:23 -0500 osutil: fix leak of stat in makestat when Py_BuildValue fails stable
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:14:23 -0500] rev 23962
osutil: fix leak of stat in makestat when Py_BuildValue fails Spotted with cpychecker.
Tue, 27 Jan 2015 10:12:55 -0500 osutil.c: clean up space before a tab stable
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:12:55 -0500] rev 23961
osutil.c: clean up space before a tab
Tue, 27 Jan 2015 10:10:04 -0500 dirs: fix leak of iterator in dirs_fromiter stable
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:10:04 -0500] rev 23960
dirs: fix leak of iterator in dirs_fromiter Spotted with cpychecker.
Tue, 27 Jan 2015 10:07:04 -0500 diffhelpers: verify hline was created before using it stable
Augie Fackler <augie@google.com> [Tue, 27 Jan 2015 10:07:04 -0500] rev 23959
diffhelpers: verify hline was created before using it Found with cpychecker.
Sun, 25 Jan 2015 22:55:10 -0500 largefiles: revert to lfilesrepo.status() being an unfiltered method stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Jan 2015 22:55:10 -0500] rev 23958
largefiles: revert to lfilesrepo.status() being an unfiltered method This effectively reverts 67d63ec85eb7, which caused some normal file copies to not be displayed as copies. Other normal file copies could be displayed- the exact reason isn't clear. This also adds two tests that were failing prior to this backout, so that this can be sorted out next cycle. The difference between copy cases that worked and those that didn't seemed to be in copies.pathcopies(). When largefiles isn't enabled for the changed test, or lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'. That wasn't true otherwise, which fell through to the _chain() method. In this case, the copy is removed in the criss cross loop. 'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type in the failing case. I tried adding the ancestor method to the lfilesctx class to change the type of the ancestor context, however the context when printed as a string then gains a '+'. This points to it being a context.committablectx, which clearly isn't correct for an ancestor. Possibly the problem is the lfilesctx needs to subclass context.committablectx in some cases, but context.changectx in others, within the same invocation? I'm not sure how to pull that off, and backing out this change is safer during the freeze. As to the status changing when a path is specified, I haven't looked into it yet.
Sun, 25 Jan 2015 20:13:54 -0600 test-tools: portability tweak stable
Matt Mackall <mpm@selenic.com> [Sun, 25 Jan 2015 20:13:54 -0600] rev 23957
test-tools: portability tweak
Sun, 25 Jan 2015 20:20:27 +0900 revset: fix ancestors(null) to include null revision (issue4512) stable
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Jan 2015 20:20:27 +0900] rev 23956
revset: fix ancestors(null) to include null revision (issue4512) Since 13c0327eeb6f, null parent is explicitly excluded. So, there is no reason to have nullrev in the initial seen set.
Sat, 10 Jan 2015 13:14:00 +0900 log: use rev() to build revset of --follow option from numeric revision stable
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 13:14:00 +0900] rev 23955
log: use rev() to build revset of --follow option from numeric revision startrev can be -1.
Sat, 10 Jan 2015 12:56:38 +0900 revset: allow rev(-1) to indicate null revision (BC) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 12:56:38 +0900] rev 23954
revset: allow rev(-1) to indicate null revision (BC) This can simplify the conversion from numeric revision to string. Without it, we have to handle -1 specially because repo['-1'] != repo[-1]. The -1 revision is not officially documented, but this change makes sense assuming that "rev(%d)" exists for scripting or third-party tools.
Fri, 23 Jan 2015 20:30:49 -0800 extensions: don't quit loading extensions in the middle if traceback is on stable
Siddharth Agarwal <sid0@fb.com> [Fri, 23 Jan 2015 20:30:49 -0800] rev 23953
extensions: don't quit loading extensions in the middle if traceback is on This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if loading an extension failed when --traceback was on, then at some point morphed into a 'return 1' in a function that otherwise returns nothing. At this point, if ui.traceback is enabled and if loading an extension fails for whatever reason, including one as innocent as it not being present, we leave any extensions loaded so far in a bogus half-initialized state. That doesn't really make any sense.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip