Martin Geisler <mg@aragost.com> [Mon, 23 Jul 2012 15:55:22 -0600] rev 17235
encoding: use s.decode to trigger UnicodeDecodeError
When calling encode on a str, the string is first decoded using the
default encoding and then encoded. So
s.encode('ascii') == s.decode().encode('ascii')
We don't care about the encode step here -- we're just after the
UnicodeDecodeError raised by decode if it finds a non-ASCII character.
This way is also marginally faster since it saves the construction of
the extra str object.
Adrian Buehlmann <adrian@cadifra.com> [Sun, 22 Jul 2012 13:16:45 +0200] rev 17234
test-largefiles: fix test failing on vfat file systems
The usercache hardlinks files for filesystems that support hardlinks. So when
this test is run on a filesystem that supports hardlinking, we have a link
in r7 and in the usercache, pointing to the same file contents (4cdac4d8...).
vfat does not support hardlinks, the file in the cache and in the store of
r7 are thus independent.
For the test to pass on vfat, we need to corrupt *both* the largefile in the
usercache and in the store of r7. Corrupting only one of them is not sufficient.
Fixes:
--- /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t
+++ /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t.err
@@ -997,9 +997,11 @@
$ hg push -R r7 http://localhost:$HGPORT1
pushing to http://localhost:$HGPORT1/
searching for changes
- remote: largefiles: failed to put 4cdac4d8b084d0b599525cf732437fb337d422a8 into store: largefile contents do not match hash
- abort: remotestore: could not put $TESTTMP/r7/.hg/largefiles/4cdac4d8b084d0b599525cf732437fb337d422a8 to remote store http://localhost:$HGPORT1/ (glob)
- [255]
+ searching for changes
+ remote: adding changesets
+ remote: adding manifests
+ remote: adding file changes
+ remote: added 2 changesets with 2 changes to 2 files
$ rm -rf empty
Push a largefiles repository to a served empty repository
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 22:10:52 -0400] rev 17233
largefiles: mark as a first party extension
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).
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.
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.
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.
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.
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.
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:09:06 -0500] rev 17226
Added tag 2.3-rc for changeset a06e2681dd17
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:08:25 -0500] rev 17225
merge default into stable for 2.3 code freeze
Matt Mackall <mpm@selenic.com> [Wed, 18 Jul 2012 19:08:11 -0500] rev 17224
merge with crew
Martin Geisler <martin@geisler.net> [Thu, 19 Jul 2012 00:54:33 +0200] rev 17223
merge with 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.
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)
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.