Thu, 19 Jul 2012 23:35:13 -0400 largefiles: ensure addlargefiles() doesn't add a standin as a largefile stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 23:35:13 -0400] rev 17232
largefiles: ensure addlargefiles() doesn't add a standin as a largefile An easy way to force this (and cause a traceback) prior to the fix for 3507 was $ touch large $ hg add --large large $ hg ci -m "add" $ hg remove large $ touch large $ hg addremove --config largefiles.patterns=**large This patch also detected (and corrected) a previous test where a standin got added as a largefile (without a traceback).
Thu, 19 Jul 2012 11:12:05 -0400 largefiles: fix a traceback when addremove follows a remove (issue3507) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 11:12:05 -0400] rev 17231
largefiles: fix a traceback when addremove follows a remove (issue3507) The problem only occurred if a file was removed with 'hg rm' (as opposed to the OS utilities), and then addremove was run before a commit. Both normal and large files were affected. Ensuring that the file exists prior to an lstat() for size seems like the Right Thing. But oddly enough, the missing file that was causing lstat() to blow up was a standin when a largefile was removed, which seems fishy, because a standin should never be added as a largefile. I was then able to get a standin added as a largefile (whose name is 'large') with hg addremove --config largefiles.patterns=**large which also causes a backtrace. That will be fixed next.
Thu, 19 Jul 2012 10:00:15 -0400 largefiles: defer lfdirstate.drop() until after commit (issue3364) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 10:00:15 -0400] rev 17230
largefiles: defer lfdirstate.drop() until after commit (issue3364) The example in comment #9 of the bug writeup must be run exactly- it was the commit after the rm and prior to the addremove that screwed things up, because that commit noticed that the largefile was missing, called drop(), and then the original commit function did nothing (due to the file in the '!' state). The addremove command properly put it into the 'R' state, but it remained stuck in that state (because commit insisted 'nothing changed'). Without the commit prior to addremove, the problem didn't occur. Maybe this is an indication that lfdirstate needs to take a few more hints from the regular dirstate, regardless of what _it_ thinks the state is- similar inconsistency is probably still possible with this patch if the original commit succeeds but the lfdirstate write fails.
Thu, 19 Jul 2012 06:30:59 -0400 largefiles: fix addremove with -R option stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Jul 2012 06:30:59 -0400] rev 17229
largefiles: fix addremove with -R option If a file was missing, the missing list contained a path relative to the repo. When building the matcher from that list, the file name ended up concatenated to cwd, causing the command to abort with '<file> not under root'. This rebuilds the missing list with paths relative to cwd.
Thu, 19 Jul 2012 21:20:56 +0200 dispatch: fix traceback when extension was tested with newer versions only stable
Thomas Arendsen Hein <thomas@intevation.de> [Thu, 19 Jul 2012 21:20:56 +0200] rev 17228
dispatch: fix traceback when extension was tested with newer versions only The "worst" extension still is the one tested with the lowest tested version below the current version of Mercurial, but if an extension with was only tested with newer versions, it is considered a candidate for a bad extension, too. In this case extensions which have been tested with higher versions of Mercurial are considered better. This allows finding the oldest extension if ct can't be calculated correctly and therefore defaults to an empty tuple, and it involves less changes to the comparison logic during the current code freeze.
Thu, 19 Jul 2012 16:50:52 +0200 test-extension.t: use fixed version string instead of current tag stable
Thomas Arendsen Hein <thomas@intevation.de> [Thu, 19 Jul 2012 16:50:52 +0200] rev 17227
test-extension.t: use fixed version string instead of current tag Currently tests break with the current tag being 2.3-rc and tags set by the user could affect this test, too.
Wed, 18 Jul 2012 19:09:06 -0500 Added tag 2.3-rc for changeset a06e2681dd17 stable
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:09:06 -0500] rev 17226
Added tag 2.3-rc for changeset a06e2681dd17
Wed, 18 Jul 2012 19:08:25 -0500 merge default into stable for 2.3 code freeze stable 2.3-rc
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:08:25 -0500] rev 17225
merge default into stable for 2.3 code freeze
Wed, 18 Jul 2012 19:08:11 -0500 merge with crew
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:08:11 -0500] rev 17224
merge with crew
Thu, 19 Jul 2012 00:54:33 +0200 merge with stable
Martin Geisler <martin@geisler.net> [Thu, 19 Jul 2012 00:54:33 +0200] rev 17223
merge with stable
Thu, 19 Jul 2012 00:53:27 +0200 windows: removed duplicate termwidth definition stable
Martin Geisler <martin@geisler.net> [Thu, 19 Jul 2012 00:53:27 +0200] rev 17222
windows: removed duplicate termwidth definition Changeset dbf91976f900 caused this when the "from win32 import *" line was replaced with explicit import statements: the wildcard import was at the bottom of the file and so windows.termwidth was overwritten by win32.termwidth as indented, but the new explicit import statements were at the top and so win32.termwidth got lost. With the switch to ctypes, win32 can always be imported and so the fallback termwidth in windows is no longer needed.
Fri, 13 Jul 2012 13:21:20 +0200 httprepo: ensure Content-Type header exists when pushing data
Pierre-Yves.David@ens-lyon.org [Fri, 13 Jul 2012 13:21:20 +0200] rev 17221
httprepo: ensure Content-Type header exists when pushing data Otherwise the wireprotocol just hangs while trying to send data. (And nothing is received at the other side)
Fri, 13 Jul 2012 22:15:11 +0200 obsolete: obsstore.add now takes a list of markers.
Pierre-Yves.David@ens-lyon.org [Fri, 13 Jul 2012 22:15:11 +0200] rev 17220
obsolete: obsstore.add now takes a list of markers. This allow efficient IO and it greatly simplify the merging of markers.
Thu, 12 Jul 2012 19:58:07 +0200 obsolete: refactor writemarkers to only encode them
Pierre-Yves.David@ens-lyon.org [Thu, 12 Jul 2012 19:58:07 +0200] rev 17219
obsolete: refactor writemarkers to only encode them The function is now able to write the version header as necessary. The function now yield bytes to be written to a stream. This should ease later use of this function for wireprotocol based exchanged. Prepare the public use of the writemarker by wireprotocol function.
Sat, 14 Jul 2012 18:29:46 +0200 update: put rules for uncommitted changes into verbose help section
Adrian Buehlmann <adrian@cadifra.com> [Sat, 14 Jul 2012 18:29:46 +0200] rev 17218
update: put rules for uncommitted changes into verbose help section
Fri, 06 Jul 2012 18:41:25 +0200 hooks: print out more information when loading a python hook fails
Simon Heimberg <simohe@besonet.ch> [Fri, 06 Jul 2012 18:41:25 +0200] rev 17217
hooks: print out more information when loading a python hook fails When loading a python hook with file syntax fails, there is no information that this happened while loading a hook. When the python file does not exist even the file name is not printed. (Only that a file is missing.) This patch adds this information and a test for loading a non existing file and a directory not being a python module.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 +30000 tip