Wed, 25 Apr 2012 23:28:54 +0200 docs: don't use :hg: at the beginning of lines in notes (issue3397) stable
Mads Kiilerich <mads@kiilerich.com> [Wed, 25 Apr 2012 23:28:54 +0200] rev 16510
docs: don't use :hg: at the beginning of lines in notes (issue3397) It seem like docutils 0.8 interpret ':hg:`command`' roles at the beginning of indented lines in '.. note::' directives as a field that is an invalid argument to the directive. It fails with 'Error in "note" directive: invalid option block.' Docutils 0.7 accepted this arguably incorrect markup. Reflowing the text makes the problem go away. A leading '\ ' could perhaps also be used to mask the problem.
Sun, 22 Apr 2012 20:06:36 +0200 rebase: skip resolved but emptied revisions stable
Patrick Mezard <patrick@mezard.eu> [Sun, 22 Apr 2012 20:06:36 +0200] rev 16509
rebase: skip resolved but emptied revisions When rebasing, if a conflict occurs and is resolved in a way the rebased revision becomes empty, it is not skipped, unlike revisions being emptied without conflicts. The reason is: - File 'x' is merged and resolved, merge.update() marks it as 'm' in the dirstate. - rebase.concludenode() calls localrepo.commit(), which calls localrepo.status() which calls dirstate.status(). 'x' shows up as 'm' and is unconditionnally added to the modified files list, instead of being checked again. - localrepo.commit() detects 'x' as changed an create a new revision where only the manifest parents and linkrev differ. Marking 'x' as modified without checking it makes sense for regular merges. But in rebase case, the merge looks normal but the second parent is usually discarded. When this happens, 'm' files in dirstate are a bit irrelevant and should be considered 'n' possibly dirty instead. That is what the current patch does. Another approach, maybe more efficient, would be to pass another flag to merge.update() saying the 'branchmerge' is a bit of a lie and recordupdate() should call dirstate.normallookup() instead of merge(). It is also tempting to add this logic to dirstate.setparents(), moving from two to one parent is what invalidates the 'm' markers. But this is a far bigger change to make. v2: succumb to the temptation and move the logic in dirstate.setparents(). mpm suggested trying _filecommit() first but it is called by commitctx() which knows nothing about the dirstate and comes too late into the game. A second approach was to rewrite the 'm' state into 'n' on the fly in dirstate.status() which failed for graft in the following case: $ hg init repo $ cd repo $ echo a > a $ hg ci -qAm0 $ echo a >> a $ hg ci -m1 $ hg up 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg mv a b $ echo c > b $ hg ci -m2 created new head $ hg graft 1 --tool internal:local grafting revision 1 $ hg --config extensions.graphlog= glog --template '{rev} {desc|firstline}\n' @ 3 1 | o 2 2 | | o 1 1 |/ o 0 0 $ hg log -r 3 --debug --patch --git --copies changeset: 3:19cd7d1417952af13161b94c32e901769104560c tag: tip phase: draft parent: 2:b5c505595c9e9a12d5dd457919c143e05fc16fb8 parent: -1:0000000000000000000000000000000000000000 manifest: 3:3d27ce8d02241aa59b60804805edf103c5c0cda4 user: test date: Thu Jan 01 00:00:00 1970 +0000 extra: branch=default extra: source=a03df74c41413a75c0a42997fc36c2de97b26658 description: 1 Here, revision 3 is created because there is a copy record for 'b' in the dirstate and thus 'b' is considered modified. But this information is discarded at commit time since 'b' content is unchanged. I do not know if discarding this information is correct or not, but at this time we cannot represent it anyway. This patch therefore implements the last solution of moving the logic into dirstate.setparents(). It does not sound crazy as 'm' files makes no sense with only one parent. It also makes dirstate.merge() calls .lookupnormal() if there is one parent, to preserve the invariant. I am a bit concerned about introducing this kind of stateful behaviour to existing code which historically treated setparents() as a basic setter without side-effects. And doing that during the code freeze.
Sun, 22 Apr 2012 18:27:50 +0200 test-rebase: exhibit revisions which should have been skipped stable
Patrick Mezard <patrick@mezard.eu> [Sun, 22 Apr 2012 18:27:50 +0200] rev 16508
test-rebase: exhibit revisions which should have been skipped This will be fixed in the next commit. v2: - Display emptied grafted revisions - Use --git flag
Sun, 22 Apr 2012 16:40:38 +0200 transplant: do not rollback on patching error (issue3379) stable
Patrick Mezard <patrick@mezard.eu> [Sun, 22 Apr 2012 16:40:38 +0200] rev 16507
transplant: do not rollback on patching error (issue3379) Otherwise, all transplanted revisions are gone and the failing one cannot be fixed (unless it is the first one). I do not know what is the expected behaviour with rollback, probably something pull-like. Non-conflicting cases should work as previously. But something like: $ hg transplant r1 r2 commiting r1 as c1 failing r2 $ hg transplant --continue committing r2 as c2 $ hg rollback would reset the repository to its state before the "transplant --continue" instead of the whole transplant session. To fix this we might need a way to open an existing journal file, not sure this is worth the pain.
Sat, 21 Apr 2012 21:40:25 +0200 patch: fix patch hunk/metdata synchronization (issue3384) stable
Patrick Mezard <patrick@mezard.eu> [Sat, 21 Apr 2012 21:40:25 +0200] rev 16506
patch: fix patch hunk/metdata synchronization (issue3384) Git patches are parsed in two phases: 1) extract metadata, 2) parse actual deltas and merge them with the previous metadata. We do this to avoid dependency issues like "modify a; copy a to b", where "b" must be copied from the unmodified "a". Issue3384 is caused by flaky code I wrote to synchronize the patch metadata with the emitted hunk: if (gitpatches and (gitpatches[-1][0] == afile or gitpatches[-1][1] == bfile)): gp = gitpatches.pop()[2] With a patch like: diff --git a/a b/c copy from a copy to c --- a/a +++ b/c @@ -1,1 +1,2 @@ a +a @@ -2,1 +2,2 @@ a +a diff --git a/a b/a --- a/a +++ b/a @@ -1,1 +1,2 @@ a +b the first hunk of the first block is matched with the metadata for the block "diff --git a/a b/c", then the second hunk of the first block is matched with the metadata of the second block "diff --git a/a b/a", because of the "or" in the code paste above. Turning the "or" into an "and" is not enough as we have to deal with /dev/null cases for each file. We I remove this broken piece of code: # copy/rename + modify should modify target, not source if gp.op in ('COPY', 'DELETE', 'RENAME', 'ADD') or gp.mode: afile = bfile because "afile = bfile" set "afile" to stuff like "b/file" instead of "a/file", and because this only happens for git patches, which afile/bfile are ignored anyway by applydiff(). v2: - Avoid a traceback on git metadata desynchronization
Sat, 21 Apr 2012 10:23:47 +0200 commit: use ui.configbool when checking 'commitsubrepos' setting on --amend stable
Adrian Buehlmann <adrian@cadifra.com> [Sat, 21 Apr 2012 10:23:47 +0200] rev 16505
commit: use ui.configbool when checking 'commitsubrepos' setting on --amend Before this fix, having [ui] commitsubrepos = False in the config file lead to $ hg ci --amend -mx abort: cannot amend recursively
Mon, 23 Apr 2012 00:38:22 +0900 doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns" stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:38:22 +0900] rev 16504
doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns" each help topics describe that patterns are "not rooted" and "rooted" in themselves, but not describe about each other. so, this may causes misunderstanding about "rooted"-ness of patterns.
Mon, 23 Apr 2012 00:33:09 +0900 doc: add description about location of management files for subrepo stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:33:09 +0900] rev 16503
doc: add description about location of management files for subrepo
Mon, 23 Apr 2012 00:33:09 +0900 doc: add description about re-opening closed heads to 'Head, closed branch' in glossary stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:33:09 +0900] rev 16502
doc: add description about re-opening closed heads to 'Head, closed branch' in glossary
Mon, 23 Apr 2012 00:33:09 +0900 doc: fix careless document miss for term 'Close changeset' in glossary stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:33:09 +0900] rev 16501
doc: fix careless document miss for term 'Close changeset' in glossary there is no term 'Changeset, close' in glossary. 'Close changeset' seems to have to be linked not to 'Branch, closed', but to 'Head, closed branch', because only the latter explains about "the changeset that marks a head as no longer interesting".
Mon, 23 Apr 2012 00:30:45 +0900 doc: fix careless document miss in help of hgext/notify stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:30:45 +0900] rev 16500
doc: fix careless document miss in help of hgext/notify according to configuration example below, and direction of changeset transference, this paragraph should describe about "changegroup" hook. [hooks] # one email for each incoming changeset incoming.notify = python:hgext.notify.hook # one email for all incoming changesets changegroup.notify = python:hgext.notify.hook # one email for all outgoing changesets outgoing.notify = python:hgext.notify.hook
Mon, 23 Apr 2012 00:29:04 +0900 doc: fix explanation comment in acl extension stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 23 Apr 2012 00:29:04 +0900] rev 16499
doc: fix explanation comment in acl extension according to configuration in "acl.deny" below, group "@hg-denied" also be denied for all files, so add such description to comment for configuration. [acl.deny] # user6 will not have write access to any file: ** = user6 # Group "hg-denied" will not have write access to any file: ** = @hg-denied
Mon, 23 Apr 2012 01:57:17 +0200 tests: test test-filelog is python - rename to test-filelog.py stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:57:17 +0200] rev 16498
tests: test test-filelog is python - rename to test-filelog.py
Mon, 23 Apr 2012 01:56:48 +0200 tests: avoid tab indent on all kinds of lines of sh commands stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:56:48 +0200] rev 16497
tests: avoid tab indent on all kinds of lines of sh commands
Mon, 23 Apr 2012 01:56:48 +0200 tests: use 'do sleep 0' instead of 'do true', also on first line of command stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:56:48 +0200] rev 16496
tests: use 'do sleep 0' instead of 'do true', also on first line of command f64b25f147d7 established that '... do true ...' shouldn't be used, but that was only enforced on continued lines.
Mon, 23 Apr 2012 01:56:48 +0200 check-code: put grouping around regexps generated from testpats stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:56:48 +0200] rev 16495
check-code: put grouping around regexps generated from testpats This removes the pitfall that would make the testpath r'a|b' match 'b' on all lines in .t tests.
Mon, 23 Apr 2012 01:56:48 +0200 tests: don't use /dev/urandom for largefiles testing stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:56:48 +0200] rev 16494
tests: don't use /dev/urandom for largefiles testing There is no need to use entropy here just to create some content that only will be used for hashing and ignored. This avoids a problem where dd from /dev/urandom on solaris generates too short output.
Sun, 22 Apr 2012 21:27:52 -0400 encoding: protect against non-ascii default encoding stable
Cesar Mena <cesarmena@gmail.com> [Sun, 22 Apr 2012 21:27:52 -0400] rev 16493
encoding: protect against non-ascii default encoding If the default python encoding was changed from ascii, the attempt to encode as ascii before lower() could throw a UnicodeEncodeError. Catch UnicodeError instead to prevent an unhandled exception.
Mon, 23 Apr 2012 14:32:59 +0200 update: fix case-collision with a clean wd and no --clean stable
Patrick Mezard <patrick@mezard.eu> [Mon, 23 Apr 2012 14:32:59 +0200] rev 16492
update: fix case-collision with a clean wd and no --clean cbf2ea2f5ca1 introduced some logic to avoid case-collision detection between source and destination revisions when it does not make sense: clean or to be cleaned working directories. Unfortunately, part of it was flawed and the related test was broken by another bug. This patch disables cross revision case collision detection for updates without option or with --check, if the working directory is clean.
Mon, 23 Apr 2012 12:12:04 +0200 update: make --check abort with dirty subrepos stable
Patrick Mezard <patrick@mezard.eu> [Mon, 23 Apr 2012 12:12:04 +0200] rev 16491
update: make --check abort with dirty subrepos Aka "we could use dirty() but... yeah let's use it"
Mon, 23 Apr 2012 12:09:54 +0200 update: fix "not rev" vs "rev is None" stable
Patrick Mezard <patrick@mezard.eu> [Mon, 23 Apr 2012 12:09:54 +0200] rev 16490
update: fix "not rev" vs "rev is None"
Sat, 21 Apr 2012 08:24:10 -0700 plan9: add missing source entries to proto stable
Steven Stallion <sstallion@gmail.com> [Sat, 21 Apr 2012 08:24:10 -0700] rev 16489
plan9: add missing source entries to proto
Sun, 22 Apr 2012 20:30:36 -0700 Merge stable stable
Brendan Cully <brendan@kublai.com> [Sun, 22 Apr 2012 20:30:36 -0700] rev 16488
Merge stable
Mon, 23 Apr 2012 01:39:26 +0200 tests: fix incorrect markup of continued lines of sh commands stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16487
tests: fix incorrect markup of continued lines of sh commands
Mon, 23 Apr 2012 01:39:26 +0200 check-code: 'printf \0' is apparently fine - accept it in check-code stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16486
check-code: 'printf \0' is apparently fine - accept it in check-code Nobody complained over '\0' in test-eol.t. The too strict check becomes a problem when this check is applied to more lines.
Mon, 23 Apr 2012 01:39:26 +0200 tests: solaris sh can not negate exit status with '!' stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16485
tests: solaris sh can not negate exit status with '!'
Mon, 23 Apr 2012 01:39:26 +0200 tests: hide diff -u saying 'No differences encountered' on solaris stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16484
tests: hide diff -u saying 'No differences encountered' on solaris
Mon, 23 Apr 2012 01:39:26 +0200 tests: ^ must be quoted when used on solaris sh stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16483
tests: ^ must be quoted when used on solaris sh The check was broken when it was introduced in 6e4cf8319f54.
Mon, 23 Apr 2012 01:39:26 +0200 tests: remove test-pull-pull-corruption2.t stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16482
tests: remove test-pull-pull-corruption2.t This test gave random failures on slow machines (solaris). The test was added in 6f6e210b38cf as a test case from issue148. It did however require manual setup: The attached script creates such a corruption (you have to add a "import time; time.spleep(3)" in localrepo.addchangegroup before the changegroup manifest are written for example. The test as it is has thus no value as automatic test case. The necessary sleep could be added by a hook, but test-pending.t already tests that.
Mon, 23 Apr 2012 01:39:26 +0200 tests: remove race in test-pull-pull-corruption.t stable
Mads Kiilerich <mads@kiilerich.com> [Mon, 23 Apr 2012 01:39:26 +0200] rev 16481
tests: remove race in test-pull-pull-corruption.t The output from the background process was not always interleaved "correctly" with output from the foreground process.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip