Patrick Mezard <patrick@mezard.eu> [Thu, 26 Apr 2012 21:44:00 +0200] rev 16523
patch: include file name in binary patch error messages
$ hg import --no-commit ../mercurial_1915035238540490516.patch
applying ../mercurial_1915035238540490516.patch
abort: could not extract binary data
Becomes:
abort: could not extract "binary2" binary data
Patrick Mezard <patrick@mezard.eu> [Sat, 21 Apr 2012 19:58:18 +0200] rev 16522
patch: display a nice error for invalid base85 data
Before, import was terminating with a traceback. Now it says:
$ hg import --no-commit ../bad.patch
applying ../bad.patch
abort: could not decode binary patch: bad base85 character at position 66
Patrick Mezard <patrick@mezard.eu> [Thu, 26 Apr 2012 14:24:46 +0200] rev 16521
revset: fix adds/modifies/removes and patterns (issue3403)
The fast path was triggered if the argument was not like "type:value", with
type a known pattern type. This is wrong for several reasons:
- path:value is valid for the fast path
- '*' is interpreted as a glob by default and is not valid for fast path
Fast path detection is now done after the pattern is parsed, and the normalized
path is extracted for direct comparison. All this seems a bit complicated, it
is tempting to drop the fast path completely. Also, the hasfile() revset does
something similar (only check .files()), without a fast path. If the fast path
is really that efficient maybe it should be used there too.
Note that:
$ log 'modifies("set:modified()")'
is different from:
$ log 'modifies("*")'
because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences.
Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>
Matt Mackall <mpm@selenic.com> [Thu, 26 Apr 2012 13:18:47 -0500] rev 16520
merge with i18n
Wagner Bruna <wbruna@yahoo.com> [Tue, 24 Apr 2012 21:09:27 -0300] rev 16519
i18n-pt_BR: synchronized with e3c7ca15cde2
Wagner Bruna <wbruna@yahoo.com> [Tue, 24 Apr 2012 20:54:56 -0300] rev 16518
merge with i18n
Wagner Bruna <wbruna@yahoo.com> [Tue, 24 Apr 2012 10:06:17 -0300] rev 16517
i18n-pt_BR: synchronized with 83622954b64d
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Apr 2012 13:19:22 -0400] rev 16516
largefiles: notice dirty large files in a subrepo
Summary and commit use dirty() to check the status of a subrepository,
so this overrides dirty() in the subrepo in the same manner as
status() to check the large files instead of their standins.
Previously, if only a large file was changed in a subrepo, summary in
the top level repo would not report the subrepo was dirty and commit
-S would report nothing changed. If any type of file was changed in
the top repo and only a large file in the subrepo, commit -S would not
commit the changes to the subrepo.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Apr 2012 03:47:34 -0400] rev 16515
largefiles: fix status -S reporting of subrepos (issue3231)
Wrapping the status command will only invoke overridestatus() and set
the lfstatus field for the top level repository. Wrapping the status
function is required to set the field on child repositories.
Previously, status -S would report large files in a subrepo as '?'
regardless of their actual states, and was inconsistent with what
status would report from within that subrepo.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 26 Apr 2012 02:41:20 +0900] rev 16514
i18n: use locale insensitive format for datetimes as intermediate representation (issue3398)
on some non "en" locale environments, "hg convert" is aborted, because
"util.parsedate()" fails.
it fails in "memctx.__init__()" called by "putcommit()" of "convert".
in "hg convert", datetimes gotten from source repository
are usually formatted by "util.datestr()" with default format "%a %b
%d %H:%M:%S %Y %1%2".
but on some environments, "%a" and "%b" may cause locale sensitive
string, and such string may cause parse error in "util.parsedate()".
this path uses "%Y-%m-%d %H:%M:%S %1%2" as intermediate representation
format for datetimes, because it consists only of locale insensitive
elements.
datetimes in above format are only used for passing them from
conversion logic to memctx object, so it doesn't have to be formatted
by locale sensitive one.
this patch just avoids locale sensitivity problem of "datestr()" and
"parsedate()" combintion.