Wed, 15 Feb 2012 23:44:10 +0200 cmdserver: invalidate the dirstate when running commands (issue3271) stable
Idan Kamara <idankk86@gmail.com> [Wed, 15 Feb 2012 23:44:10 +0200] rev 16114
cmdserver: invalidate the dirstate when running commands (issue3271) The dirstate is invalidated separately outside of invalidate() which is already being called (other callers of invalidate() seems to suggest the separation is there for a reason).
Wed, 15 Feb 2012 23:49:15 +0200 localrepo: reset _phasesdirty flag after writing stable
Idan Kamara <idankk86@gmail.com> [Wed, 15 Feb 2012 23:49:15 +0200] rev 16113
localrepo: reset _phasesdirty flag after writing
Thu, 16 Feb 2012 13:03:42 +0100 import: handle git renames and --similarity (issue3187) stable
Patrick Mezard <patrick@mezard.eu> [Thu, 16 Feb 2012 13:03:42 +0100] rev 16112
import: handle git renames and --similarity (issue3187) There is no reason to discard copy sources from the set of files considered by addremove(). It was done to handle the case where a first patch would create 'a' and a second one would move 'a' to 'b'. If these patches were applied with --no-commit, 'a' would first be marked as added, then unlinked and dropped from the dirstate but still passed to addremove(). A better fix is thus to exclude removed files which ends being dropped from the dirstate instead of removed. Reported by Jason Harris <jason@jasonfharris.com>
Thu, 16 Feb 2012 12:56:48 +0100 context: make workingctx.forget() really warn about untracked files stable
Patrick Mezard <patrick@mezard.eu> [Thu, 16 Feb 2012 12:56:48 +0100] rev 16111
context: make workingctx.forget() really warn about untracked files
Wed, 15 Feb 2012 23:01:09 +0900 largefiles: check whether specified patterns are related to largefiles strictly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Feb 2012 23:01:09 +0900] rev 16110
largefiles: check whether specified patterns are related to largefiles strictly current 'lfiles_repo.status()' implementation examines whether specified patterns are related to largefiles in working directory (not to STANDIN) or not by NOT-EMPTY-NESS of below list: [f for f in match.files() if f in lfdirstate] but it can not be assumed that all in 'match.files()' are file itself exactly, because user may only specify part of path to match whole under subdirectories recursively. above examination will mis-recognize such pattern as 'not related to largefiles', and executes normal 'status()' procedure. so, 'hg status' shows '?'(unknown) status for largefiles in working directory unexpectedly. this patch examines relation of pattern to largefiles by applying 'match()' on each entries in lfdirstate and checking wheter there is no matched entry. it may increase cost of examination, because it causes of full scan of entries in lfdirstate. so this patch uses normal for-loop instead of list comprehensions, to decrease cost when matching is found.
Fri, 10 Feb 2012 17:09:23 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 17:09:23 -0600] rev 16109
merge with stable
Fri, 10 Feb 2012 16:52:32 -0600 log: remove caching of all visited revisions (issue3253) stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 16:52:32 -0600] rev 16108
log: remove caching of all visited revisions (issue3253) Not only does this eat all available memory for some users, it's slower.
Fri, 10 Feb 2012 16:09:30 -0600 pull: backout change to return code stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 16:09:30 -0600] rev 16107
pull: backout change to return code This bit a number of people.
Fri, 10 Feb 2012 22:34:13 +0100 convert: use splicemap entries when sorting revisions (issue1748) stable
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 22:34:13 +0100] rev 16106
convert: use splicemap entries when sorting revisions (issue1748) When sorting revisions before converting them, we have to edit the revision graph using splicemap entries. Otherwise, a spliced revision may be converted before its synthetic parents. Invalid splicemap revisions are now detected before starting the conversion.
Fri, 10 Feb 2012 22:25:49 +0100 convert: turn splicemap into a simple dictionary stable
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 22:25:49 +0100] rev 16105
convert: turn splicemap into a simple dictionary Parsing the splicemap as a mapfile was a pain because map does not let us override its parsing code and splicemap entries are not key/values. Besides we had no need for mapfiles extra features. Just parse the splicemap and return a dictionary.
Fri, 10 Feb 2012 13:50:13 +0100 debugrevspec: mention --verbose to print the parsed tree
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 13:50:13 +0100] rev 16104
debugrevspec: mention --verbose to print the parsed tree
Fri, 10 Feb 2012 14:46:09 +0100 largefiles: only cache largefiles in new heads stable
Na'Tosha Bard <natosha@unity3d.com> [Fri, 10 Feb 2012 14:46:09 +0100] rev 16103
largefiles: only cache largefiles in new heads This fixes a serious performance regression in largefiles introduced in Mercurial 2.1. Caching new largefiles on pull is necessary, because otherwise largefiles will be missing (and unable to be downloaded) when the user tries to merge or rebase a new head with an old one. But this is an expensive operation and should only be done for heads that are new from the pull, rather than on all heads in the repository.
Fri, 10 Feb 2012 13:47:57 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 13:47:57 -0600] rev 16102
merge with stable
Tue, 07 Feb 2012 18:47:16 +0100 mq: restore _branchtags() fast path (issue3223) stable
Patrick Mezard <patrick@mezard.eu> [Tue, 07 Feb 2012 18:47:16 +0100] rev 16101
mq: restore _branchtags() fast path (issue3223) Since a5917346c72e, mq saves the nodeid of the first applied patch to cache/branchheads, which breaks the optimized cache handling introduced in fbf8320f25c8. The problem is the revision being committed is appended to mqrepo.applied after the commit succeeds, which means mqrepo._branchtags() performs a regular update and write the first applied patch to the branch cache. One solution is to set a context variable _committingpatch on the mqrepo while it is committing a patch and to take it in account when deciding to fast-path mqrepo._branchtags(). Not really elegant but it works. The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The cache should not have been updated with mq records. The changes to test-keyword.t are indirectly caused by a5917346c72e. Reported and analyzed by Yuya Nishihara <yuya@tcha.org> Notes: - qpush still makes a slow path _branchtags() call when checking heads. Maybe this can be optimized. - be careful when merging this patch in default as secretcommit() was renamed newcommit() right after the end of the code freeze.
Tue, 07 Feb 2012 18:47:13 +0100 mq: ensure all mq commits are made with secretcommit() stable
Patrick Mezard <patrick@mezard.eu> [Tue, 07 Feb 2012 18:47:13 +0100] rev 16100
mq: ensure all mq commits are made with secretcommit() Having a common code path helps fixing things globally.
Wed, 08 Feb 2012 17:45:10 +0100 convert/bzr: ignore nested repos when listing branches (issue3254)
Patrick Mezard <patrick@mezard.eu> [Wed, 08 Feb 2012 17:45:10 +0100] rev 16099
convert/bzr: ignore nested repos when listing branches (issue3254) Reported by A.S. Budden <abudden@gmail.com>
Wed, 08 Feb 2012 16:56:00 +0000 tests: tighten checks for octal escapes in shell printf. stable
Jim Hague <jim.hague@acm.org> [Wed, 08 Feb 2012 16:56:00 +0000] rev 16098
tests: tighten checks for octal escapes in shell printf. printf on AIX default shell ksh (89) says \1 is an invalid escape. It insists on at least 2 digits. This causes failures in test-keyword.t and test-status.t. check-code.py already looks out for \NNN and recommends using Python for outputting octal values. Extend the check to \NN and \N and fix up resulting failures.
Wed, 08 Feb 2012 20:00:52 +0100 phase: when phase cannot be reduced, hint at --force and return 1 (BC)
Patrick Mezard <patrick@mezard.eu> [Wed, 08 Feb 2012 20:00:52 +0100] rev 16097
phase: when phase cannot be reduced, hint at --force and return 1 (BC) Before, trying to change the phase of a "public" node to "draft" would result in: $ hg phase --draft . no phases changed [0] With this patch: $ hg phase --draft . cannot move 1 changesets to a more permissive phase, use --force no phases changed [1] On partial failures, the exit status is now 1 instead of 0 and the number of changed nodes is displayed while it was only with --verbose. It seems useful to tell the user that despite the apparent failure, something changed. $ hg phase --draft '5 or 7' cannot move 1 changesets to a more permissive phase, use --force phase changed for 1 changesets [1]
Thu, 09 Feb 2012 21:03:07 +0100 revset: fix alias substitution recursion (issue3240)
Patrick Mezard <patrick@mezard.eu> [Thu, 09 Feb 2012 21:03:07 +0100] rev 16096
revset: fix alias substitution recursion (issue3240) The revset aliases expansion worked like: expr = "some revset" for alias in aliases: expr = alias.process(expr) where "process" was replacing the alias with its *unexpanded* substitution, recursively. So it only worked when aliases were applied in proper dependency order. This patch rewrites the expansion process so all aliases are expanded recursively at every tree level, after parent alias rewriting and variable expansion.
Thu, 09 Feb 2012 17:54:47 -0600 update: just merge unknown file collisions
Matt Mackall <mpm@selenic.com> [Thu, 09 Feb 2012 17:54:47 -0600] rev 16095
update: just merge unknown file collisions The unknown file collision rule was introduced as an extension of the "should be clean when merging" rule. Unfortunately, it got applied to the normal update path, which should be happy to merge local changes. This patch gives us merges for unknown file collisions on update, while preserving abort for merge and update -c.
Thu, 09 Feb 2012 17:04:17 -0600 merge: don't use unknown()
Matt Mackall <mpm@selenic.com> [Thu, 09 Feb 2012 17:04:17 -0600] rev 16094
merge: don't use unknown() This removes use of unknown files for building the synthetic working directory manifest used by manifestmerge. Instead, we adopt the strategy used by _checkunknown. Side-effect: unknown files are no longer moved by remote directory renames, and now are left alone like ignored files.
Thu, 09 Feb 2012 16:50:19 -0600 merge: refactor unknown file conflict checking
Matt Mackall <mpm@selenic.com> [Thu, 09 Feb 2012 16:50:19 -0600] rev 16093
merge: refactor unknown file conflict checking Previously, we would do a full working directory walk including unknown files to perform a merge. In many cases, this was painful because unknown files greatly outnumbered tracked files and generally had no useful effect on the merge. Here we instead wait until we find a file in the destination that's not tracked locally and detect if it exists and is not ignored. This is usually cheaper but can be -more- expensive in the case where we're adding a huge number of files. On the other hand, the cost of statting the new files should be dwarfed by the cost of eventually writing them. In this version, case collisions are detected implicitly by os.path.exists and wctx[f] lookup.
Thu, 09 Feb 2012 13:16:20 -0600 update: use normal update path with --check (issue2450)
Matt Mackall <mpm@selenic.com> [Thu, 09 Feb 2012 13:16:20 -0600] rev 16092
update: use normal update path with --check (issue2450) This avoids clobbering unknown files on update by not using overwrite mode.
Mon, 06 Feb 2012 16:35:14 -0600 fetch: use update rather than clean when updating (issue3246) stable
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 16:35:14 -0600] rev 16091
fetch: use update rather than clean when updating (issue3246) We already verify the working directory is "clean" before starting so there's no advantage to clobbering the working directory.
Mon, 06 Feb 2012 15:36:44 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:36:44 -0600] rev 16090
merge with stable
Mon, 06 Feb 2012 21:17:50 +0100 mdiff: adjust hunk offsets with --ignore-blank-lines (issue3234) stable
Patrick Mezard <patrick@mezard.eu> [Mon, 06 Feb 2012 21:17:50 +0100] rev 16089
mdiff: adjust hunk offsets with --ignore-blank-lines (issue3234) When diffing the following documents with --ignore-blank-lines (-B): $ cat > a <<EOF > > > > b > x > d > EOF and: $ cat > b <<EOF > b > y > d > EOF the context lines are taken from the first document, even if the lines differ (with -w or -b) or if the number of lines differ (with -B). In the second case, we have to adjust the hunk new lines offsets or we end with inconsistent diffs like (see the @@ offsets): diff -r 0e66aa54f318 a --- a/a +++ b/a @@ -1,4 +1,3 @@ b -x +y d Note that having different context lines in a and b means the diff can be applied but is not invertible. Reported by Nicholas Riley <com-selenic@sabi.net>
Mon, 06 Feb 2012 15:22:43 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:22:43 -0600] rev 16088
merge with stable
Mon, 06 Feb 2012 15:22:34 -0600 merge with i18n
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:22:34 -0600] rev 16087
merge with i18n
Mon, 06 Feb 2012 15:22:27 -0600 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:22:27 -0600] rev 16086
merge with i18n
Mon, 06 Feb 2012 08:10:32 -0200 i18n-de: fix rst markup in command output (issue3247)
Wagner Bruna <wbruna@yahoo.com> [Mon, 06 Feb 2012 08:10:32 -0200] rev 16085
i18n-de: fix rst markup in command output (issue3247)
Mon, 06 Feb 2012 08:06:42 -0200 merge with i18n stable
Wagner Bruna <wbruna@yahoo.com> [Mon, 06 Feb 2012 08:06:42 -0200] rev 16084
merge with i18n stable
Mon, 06 Feb 2012 08:04:16 -0200 i18n-ru: fix hg command rst markup stable
Wagner Bruna <wbruna@yahoo.com> [Mon, 06 Feb 2012 08:04:16 -0200] rev 16083
i18n-ru: fix hg command rst markup
Mon, 06 Feb 2012 08:03:34 -0200 i18n-ja: fix rst markup in hg command output stable
Wagner Bruna <wbruna@yahoo.com> [Mon, 06 Feb 2012 08:03:34 -0200] rev 16082
i18n-ja: fix rst markup in hg command output
Mon, 06 Feb 2012 08:02:05 -0200 i18n-de: fix rst markup in command output (issue3247) stable
Wagner Bruna <wbruna@yahoo.com> [Mon, 06 Feb 2012 08:02:05 -0200] rev 16081
i18n-de: fix rst markup in command output (issue3247)
Sat, 04 Feb 2012 11:34:44 -0200 merge with i18n stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 04 Feb 2012 11:34:44 -0200] rev 16080
merge with i18n stable
Sat, 04 Feb 2012 11:22:01 -0200 i18n-de: fix hg command rst markup and quoting (issue3247) stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 04 Feb 2012 11:22:01 -0200] rev 16079
i18n-de: fix hg command rst markup and quoting (issue3247)
Sat, 04 Feb 2012 10:59:36 -0200 merge with i18n stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 04 Feb 2012 10:59:36 -0200] rev 16078
merge with i18n stable
Sat, 04 Feb 2012 10:55:58 -0200 i18n-de: fix rst markup in command output (issue3247) stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 04 Feb 2012 10:55:58 -0200] rev 16077
i18n-de: fix rst markup in command output (issue3247)
Sun, 05 Feb 2012 22:58:31 +0900 windows: use 'str.replace()' instead of combination of split() and join()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 05 Feb 2012 22:58:31 +0900] rev 16076
windows: use 'str.replace()' instead of combination of split() and join() 'str.replace()' is twice (or more) as fast as combination of split() and join(). combination of split() and join() in current 'util.pconvert()' implementation comes only from historical reason when win32mbcs extension was introduced.
Mon, 06 Feb 2012 12:16:29 +0900 largefiles: reduce redundant splitstandin/standin combination
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 06 Feb 2012 12:16:29 +0900] rev 16075
largefiles: reduce redundant splitstandin/standin combination assumptions: - 'lfutil.splitstandin(f)' strips 'f' of '.hglf/', if it can - 'lfile(f)' examines 'lfutil.standin(f) in manifest' - 'lfutil.standin(f)' adds '.hglf/' to 'f' and - 'f' should start with '.hglf/' there, because it is already examined by 'lfutil.isstandin(f)' then: lfile(lfutil.splitstandin(f)) => lfile(<f without '.hglf/'>) => lfutil.standin(<f without '.hglf/'>) in manifest => <<f without '.hglf/'> with '.hglf/'> in manifest => f in manifest
Mon, 06 Feb 2012 12:16:29 +0900 largefiles: reduce OR-ing of same conditions
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 06 Feb 2012 12:16:29 +0900] rev 16074
largefiles: reduce OR-ing of same conditions
Mon, 06 Feb 2012 15:10:01 -0600 subrepo: rewrite handling of subrepo state at commit (issue2403)
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:10:01 -0600] rev 16073
subrepo: rewrite handling of subrepo state at commit (issue2403) When the contents of .hgsubstate are stale (either because they've manually been tweaked or partial updates have confused it), we get confused about whether it actually needs committing. So instead, we actively consult the parent's substate and compare it the actual current state when deciding whether it needs committing. Side effect: lots of "committing subrepo" messages that didn't correspond with real commits disappear. This change is fairly invasive for a fairly obscure condition, so it's kept on the default branch.
Mon, 06 Feb 2012 15:00:08 -0600 subrepo: add basestate method
Matt Mackall <mpm@selenic.com> [Mon, 06 Feb 2012 15:00:08 -0600] rev 16072
subrepo: add basestate method This will allow us to sort out what's going on with state .hgsubstate files more precisely.
Fri, 03 Feb 2012 23:27:17 +0000 bdiff: fix malloc(0) issue in fixws() stable
Jim Hague <jim.hague@acm.org> [Fri, 03 Feb 2012 23:27:17 +0000] rev 16071
bdiff: fix malloc(0) issue in fixws() If fixws() is called on a zero-length string, malloc(0) is called and expected to return a pointer. Which it does on e.g. Linux. AIX returns NULL, which it is also legal, but the malloc() is then assumed to have failed. So ensure a valid pointer is always returned.
Mon, 06 Feb 2012 14:37:49 +0900 forget: show warning messages for forgetting in subrepo correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 06 Feb 2012 14:37:49 +0900] rev 16070
forget: show warning messages for forgetting in subrepo correctly in 'cmdutil.forget()': for f in match.files(): if match.exact(f) or not explicitonly: .... is equal to: for f in match.files(): if True: .... because 'f' from 'match.files()' should 'match.exact(f)': - 'match.files()' returns 'self._files' - 'match.exact(f)' examines 'f in self._fmap', - 'self._fmap' of match is 'set(self._files)' then, 'explicitonly' wants to suppress warning messges, if it is true (= 'cmdutil.forget()' is invoked from 'subrepo.forget()'). so, current code should be fixed as: if not explicitonly: for f in match.files(): ....
Sat, 04 Feb 2012 00:02:05 +0000 tests: fix command line overflow on ksh stable
Jim Hague <jim.hague@acm.org> [Sat, 04 Feb 2012 00:02:05 +0000] rev 16069
tests: fix command line overflow on ksh "<command> `hg manifest`" overflows the puny 1024 byte command line length limit on AIX default shell ksh. Replace with "hg manifest | xargs <command>".
Sun, 05 Feb 2012 22:58:31 +0900 use util.localpath() instead of 'str.replace()' to unify path conversion stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 05 Feb 2012 22:58:31 +0900] rev 16068
use util.localpath() instead of 'str.replace()' to unify path conversion
Sun, 05 Feb 2012 22:58:31 +0900 i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 05 Feb 2012 22:58:31 +0900] rev 16067
i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.
Sun, 05 Feb 2012 22:58:31 +0900 i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 05 Feb 2012 22:58:31 +0900] rev 16066
i18n: use util.pconvert() instead of 'str.replace()' for problematic encoding some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.
Fri, 03 Feb 2012 15:45:13 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 03 Feb 2012 15:45:13 -0600] rev 16065
merge with stable
Fri, 03 Feb 2012 19:47:09 +0100 mq: make qprev return the previous applied patch (issue3245) stable
Patrick Mezard <pmezard@gmail.com> [Fri, 03 Feb 2012 19:47:09 +0100] rev 16064
mq: make qprev return the previous applied patch (issue3245) The current behaviour is to return the previous one in the series but at the same time the implementation is buggy because it does not take guarded patches in account.
Fri, 03 Feb 2012 19:38:31 +0100 mq: fix qnext when all remaining patches are guarded stable
Patrick Mezard <pmezard@gmail.com> [Fri, 03 Feb 2012 19:38:31 +0100] rev 16063
mq: fix qnext when all remaining patches are guarded When all remaining patches are guarded, qnext used to return the last of the queue anyway.
Thu, 02 Feb 2012 10:15:13 +0100 convert/bzr: test tags conversion
Patrick Mezard <pmezard@gmail.com> [Thu, 02 Feb 2012 10:15:13 +0100] rev 16062
convert/bzr: test tags conversion
Thu, 02 Feb 2012 10:15:13 +0100 convert/bzr: handle empty bzr repositories (issue3233)
Patrick Mezard <pmezard@gmail.com> [Thu, 02 Feb 2012 10:15:13 +0100] rev 16061
convert/bzr: handle empty bzr repositories (issue3233)
Thu, 02 Feb 2012 10:15:12 +0100 convert/bzr: convert all branches (issue3229) (BC)
Patrick Mezard <pmezard@gmail.com> [Thu, 02 Feb 2012 10:15:12 +0100] rev 16060
convert/bzr: convert all branches (issue3229) (BC) Instead of opening the target bzr checkout as a single branch, we try to open it as a repository. This has the following effects: - All branches are now converted - bzr branch names are preserved. Previously, the selected branch was always converted as 'default'. Branches without a name or 'trunk' are mapped to 'default branch. - Lightweight checkouts are no longer supported. Maybe they can be, I did not try to fix that at all. Implementation notes: - This was a quick fix, I have no knowledge of bzr API besides browsing 2.0.3 sources. - The fix was only tested on OSX against bzr 2.4.2. - Tags discovery does not handle collisions. I have no idea how tags work in bzr so maybe such collisions are not possible.
Thu, 02 Feb 2012 10:15:04 +0100 convert/bzr: expect unicode metadata, encode in UTF-8 (issue3232)
Patrick Mezard <pmezard@gmail.com> [Thu, 02 Feb 2012 10:15:04 +0100] rev 16059
convert/bzr: expect unicode metadata, encode in UTF-8 (issue3232) Before this patch, metadata and file names were interpreted like: - unicode objects were converted to UTF-8 - non unicode objects were left unchanged Looking at the code and bzr being known for transcoding filenames, we expect everything to be returned as unicode objects, and we want to encode them in UTF-8, like the subversion source does. To do that, we just remove the custom implementation of .recode().
Fri, 03 Feb 2012 19:23:13 +0100 test-mq: fix sed call on OSX stable
Patrick Mezard <pmezard@gmail.com> [Fri, 03 Feb 2012 19:23:13 +0100] rev 16058
test-mq: fix sed call on OSX - The regular sed on OSX wants: -i "" not -i"" - GNU sed wants: -i"" not -i "" Backups are fine.
Mon, 30 Jan 2012 00:05:28 +0100 mq: rename secretcommit to newcommit
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Jan 2012 00:05:28 +0100] rev 16057
mq: rename secretcommit to newcommit This function create secret changeset only when mq.secret is true
Wed, 01 Feb 2012 16:28:35 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 01 Feb 2012 16:28:35 -0600] rev 16056
merge with stable
Sat, 21 Jan 2012 15:17:39 +0200 i18n-de: update po and remove fuzzies
Fabian Kreutz <fabian.kreutz@qvantel.com> [Sat, 21 Jan 2012 15:17:39 +0200] rev 16055
i18n-de: update po and remove fuzzies
Sat, 21 Jan 2012 13:49:46 +0200 i18n-de: Rework and fixes continued
Fabian Kreutz <fabian.kreutz@qvantel.com> [Sat, 21 Jan 2012 13:49:46 +0200] rev 16054
i18n-de: Rework and fixes continued
Wed, 01 Feb 2012 14:23:58 -0600 Added signature for changeset 2aa5b51f310f stable
Matt Mackall <mpm@selenic.com> [Wed, 01 Feb 2012 14:23:58 -0600] rev 16053
Added signature for changeset 2aa5b51f310f
Wed, 01 Feb 2012 14:23:55 -0600 Added tag 2.1 for changeset 2aa5b51f310f stable
Matt Mackall <mpm@selenic.com> [Wed, 01 Feb 2012 14:23:55 -0600] rev 16052
Added tag 2.1 for changeset 2aa5b51f310f
Wed, 01 Feb 2012 14:17:26 -0600 phases: don't complain if cset is already public on pushkey (issue3230) stable 2.1
Matt Mackall <mpm@selenic.com> [Wed, 01 Feb 2012 14:17:26 -0600] rev 16051
phases: don't complain if cset is already public on pushkey (issue3230)
(0) -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 +3000 +10000 +30000 tip