Re: [PATCH] py3: make ui.write() call fout.flush() per line if fout is a tty or pager

2020-06-09 Thread Augie Fackler
On Sun, Jun 07, 2020 at 08:55:03PM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1591518045 -32400
> #  Sun Jun 07 17:20:45 2020 +0900
> # Node ID ee3cd52b4b338e05b0a22cb87580d78f1ad7763d
> # Parent  03ba7de6a8b9ab339a6dafab969e890228b4c2f1
> py3: make ui.write() call fout.flush() per line if fout is a tty or pager

I'm also fine with this, but I think I prefer mjacob's solution.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable] resourceutil: fix location of line comments

2020-06-09 Thread Augie Fackler
On Tue, Jun 09, 2020 at 01:13:26PM +0200, Pierre-Yves David wrote:
> Good catch, LGTM
>
> On 6/9/20 5:25 AM, Manuel Jacob wrote:
> > # HG changeset patch
> > # User Manuel Jacob 
> > # Date 1591673085 -7200
> > #  Tue Jun 09 05:24:45 2020 +0200
> > # Branch stable
> > # Node ID 6c8384afbf770be2167478fff3cb9b92e1182a06
> > # Parent  1f114c797961733ea03d0de88390f9555a7edef4
> > resourceutil: fix location of line comments

queued, thanks
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 3 of 3] simplemerge: rewrite flag merging loop as expression

2020-06-09 Thread Augie Fackler
On Thu, Jun 04, 2020 at 11:15:43PM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1591101897 -32400
> #  Tue Jun 02 21:44:57 2020 +0900
> # Node ID 970abb8ea2a2d6a086ebfdd9a1130b2fb777640e
> # Parent  dba0ac9b68381e9610f25d9991bd623f85cbdefd
> simplemerge: rewrite flag merging loop as expression

queued, thanks
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable v2] py3: stop using block-buffered stdout to TTY on Python 3

2020-06-09 Thread Augie Fackler
Agreed, this LGTM. Yuya? I know you've been good at spotting issues in this 
area that I miss.

> On Jun 9, 2020, at 07:21, Pierre-Yves David  
> wrote:
> 
> Sigh, this seems like a good enough fix for now. We can rewrite the UI layer 
> in rust later ;-)
> 
> On 6/7/20 12:55 AM, Manuel Jacob wrote:
>> # HG changeset patch
>> # User Manuel Jacob 
>> # Date 1591333053 -7200
>> #  Fri Jun 05 06:57:33 2020 +0200
>> # Branch stable
>> # Node ID d1754bf05591d2aee0f5f9dec185faf912a21190
>> # Parent  1f114c797961733ea03d0de88390f9555a7edef4
>> # EXP-Topic fix_block-buffered_stdout
>> py3: stop using block-buffered stdout to TTY on Python 3
>> The previous code (added in 227ba1afcb65) incorrectly assumed that
>> sys.stdout.buffer is line-buffered. However the interpreter initializes it
>> with a block-buffered stream or an unbuffered stream (when the -u option or
>> the PYTHONUNBUFFERED environment variable is set), never with a line-buffered
>> stream.
>> To see the difference with the hg command, you need to do something slow, 
>> e.g.
>> `hg pull https://www.mercurial-scm.org/repo/hg`. On Python 3 on Linux, 
>> without
>> this patch, all output is printed right before the command ends. With this
>> patch, output is printed almost immediately.
>> I did some quick and dirty benchmarking, printing on my terminal.
>> Unfavorable case:
>> * for 100 times:
>>   * for 1000 times:
>> * call `ui.write(b'x')`
>>   * call `ui.write(b'\n')`
>> * ui.flush()
>> Results:
>> CPython 2.7 is unaffected (line-buffered): wall 0.231795 comb 0.23 user 
>> 0.23 sys 0.00
>> CPython 3.8 before patch (block-buffered): wall 0.190882 comb 0.19 user 
>> 0.19 sys 0.00
>> CPython 3.8 after patch (unbuffered):  wall 0.654466 comb 0.65 user 
>> 0.48 sys 0.17
>> CPython 3.8 hand-rolled line-buffered [*]: wall 0.218919 comb 0.22 user 
>> 0.22 sys 0.00
>> Favorable case:
>> * for 10 times:
>>   * call `ui.write(b'Testing write performance\n')`
>> Results:
>> CPython 2.7 is unaffected (line-buffered): wall 0.717060 comb 0.71 user 
>> 0.51 sys 0.20
>> CPython 3.8 before patch (block-buffered): wall 0.255527 comb 0.26 user 
>> 0.18 sys 0.08
>> CPython 3.8 after patch (unbuffered):  wall 0.616500 comb 0.62 user 
>> 0.45 sys 0.17
>> CPython 3.8 hand-rolled line-buffered [*]: wall 0.811805 comb 0.81 user 
>> 0.57 sys 0.24
>> [*] For this, I implemented a simplified version of what is suggested in the
>> TODO: stdout was set to block-buffered and ui.write() flushed the stream if
>> the output contains a newline character.
>> diff -r 1f114c797961 -r d1754bf05591 mercurial/utils/procutil.py
>> --- a/mercurial/utils/procutil.pyThu Apr 30 00:33:00 2020 -0400
>> +++ b/mercurial/utils/procutil.pyFri Jun 05 06:57:33 2020 +0200
>> @@ -55,12 +55,20 @@
>>  # on Windows).
>>  # Python 3 rolls its own standard I/O streams.
>>  if isatty(stdout):
>> +# TODO: Consider mitigating the performance impact of using unbuffered
>> +# writes on Python 3 and Windows, e.g. by using fully buffered streams 
>> and
>> +# ensuring on a higher level that lines are flushed.
>>  if pycompat.iswindows:
>>  # Windows doesn't support line buffering
>>  stdout = os.fdopen(stdout.fileno(), 'wb', 0)
>> -elif not pycompat.ispy3:
>> -# on Python 3, stdout (sys.stdout.buffer) is already line buffered 
>> and
>> -# buffering=1 is not handled in binary mode
>> +elif pycompat.ispy3:
>> +# Python 3 doesn't support line buffering on binary streams. Use the
>> +# underlying unbuffered raw stream. If the ``raw`` attribute doesn't
>> +# exist, stdout is already unbuffered or replaced by a custom 
>> stream.
>> +# TODO: After Mercurial 5.4, use this code path on Python 3 on 
>> Windows.
>> +# We shouldn't risk changing working behavior in the stable branch.
>> +stdout = getattr(stdout, 'raw', stdout)
>> +else:
>>  stdout = os.fdopen(stdout.fileno(), 'wb', 1)
>>if pycompat.iswindows:
>> ___
>> Mercurial-devel mailing list
>> Mercurial-devel@mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> 
> -- 
> Pierre-Yves David
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] hgext.git: decode node IDs back into Python strings (issue6349)

2020-06-09 Thread Hollis Blanchard
Huh. 'hg email --test' worked fine, but without --test yielded an empty 
body.


I've resubmitted as D8622 .

Hollis Blanchard
Mentor Graphics Emulation Division

On 6/9/20 1:20 PM, Hollis Blanchard wrote:

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8625: git: add debug logging when there's a mismatch in the cached heads list

2020-06-09 Thread durin42 (Augie Fackler)
durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The dag rebuild can be expensive, so let's try and avoid bugs where it
  transparently rebuilds all the time for no reason. This would have
  prevented the issue fixed in D8622 .

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8625

AFFECTED FILES
  hgext/git/__init__.py
  hgext/git/gitlog.py
  hgext/git/index.py
  tests/test-git-interop.t

CHANGE DETAILS

diff --git a/tests/test-git-interop.t b/tests/test-git-interop.t
--- a/tests/test-git-interop.t
+++ b/tests/test-git-interop.t
@@ -36,8 +36,12 @@
   $ cd ..
 
 Now globally enable extension for the rest of the test:
-  $ echo "[extensions]" >> $HGRCPATH
-  > echo "git=" >> $HGRCPATH
+  $ cat <> $HGRCPATH
+  > [extensions]
+  > git=
+  > [git]
+  > log-index-cache-miss = yes
+  > EOF
 
 Make a new repo with git:
   $ mkdir foo
@@ -68,11 +72,14 @@
 But if you run hg init --git, it works:
   $ hg init --git
   $ hg id --traceback
+  heads mismatch, rebuilding dagcache
   3d9be8deba43 tip master
   $ hg status
+  heads mismatch, rebuilding dagcache
   ? gamma
 Log works too:
   $ hg log
+  heads mismatch, rebuilding dagcache
   changeset:   1:3d9be8deba43
   bookmark:master
   tag: tip
@@ -89,7 +96,8 @@
 
 and bookmarks:
   $ hg bookmarks
-   * master1:3d9be8deba43
+   * masterheads mismatch, rebuilding dagcache
+  1:3d9be8deba43
 
 diff even works transparently in both systems:
   $ echo blah >> alpha
@@ -102,6 +110,7 @@
alpha
   +blah
   $ hg diff --git
+  heads mismatch, rebuilding dagcache
   diff --git a/alpha b/alpha
   --- a/alpha
   +++ b/alpha
@@ -112,12 +121,15 @@
 Remove a file, it shows as such:
   $ rm alpha
   $ hg status
+  heads mismatch, rebuilding dagcache
   ! alpha
   ? gamma
 
 Revert works:
   $ hg revert alpha --traceback
+  heads mismatch, rebuilding dagcache
   $ hg status
+  heads mismatch, rebuilding dagcache
   ? gamma
   $ git status
   On branch master
@@ -130,6 +142,7 @@
 Add shows sanely in both:
   $ hg add gamma
   $ hg status
+  heads mismatch, rebuilding dagcache
   A gamma
   $ hg files
   alpha
@@ -148,7 +161,9 @@
 
 forget does what it should as well:
   $ hg forget gamma
+  heads mismatch, rebuilding dagcache
   $ hg status
+  heads mismatch, rebuilding dagcache
   ? gamma
   $ git status
   On branch master
@@ -165,11 +180,15 @@
 
   $ echo a >> alpha
   $ hg ci -m 'more alpha' --traceback --date '1583522787 18000'
+  heads mismatch, rebuilding dagcache
   $ echo b >> beta
   $ hg ci -m 'more beta'
+  heads mismatch, rebuilding dagcache
   $ echo a >> alpha
   $ hg ci -m 'even more alpha'
+  heads mismatch, rebuilding dagcache
   $ hg log -G alpha
+  heads mismatch, rebuilding dagcache
   @  changeset:   4:6626247b7dc8
   :  bookmark:master
   :  tag: tip
@@ -188,6 +207,7 @@
  summary: Add alpha
   
   $ hg log -G beta
+  heads mismatch, rebuilding dagcache
   o  changeset:   3:d8ee22687733
   :  user:test 
   :  date:Thu Jan 01 00:00:00 1970 +
@@ -200,15 +220,18 @@
   
 
   $ hg log -r "children(3d9be8deba43)" -T"{node|short} {children}\n"
+  heads mismatch, rebuilding dagcache
   a1983dd7fb19 3:d8ee22687733
 
 hg annotate
 
   $ hg annotate alpha
+  heads mismatch, rebuilding dagcache
   0: alpha
   2: a
   4: a
   $ hg annotate beta
+  heads mismatch, rebuilding dagcache
   1: beta
   3: b
 
@@ -219,6 +242,7 @@
   $ mkdir a
   $ echo "This is file mu." > a/mu
   $ hg ci -A -m 'Introduce file a/mu'
+  heads mismatch, rebuilding dagcache
   adding a/mu
 
 Both hg and git agree a/mu is part of the repo
@@ -238,10 +262,12 @@
   On branch master
   nothing to commit, working tree clean
   $ hg status
+  heads mismatch, rebuilding dagcache
 
 
 node|shortest works correctly
   $ hg log -T '{node}\n' | sort
+  heads mismatch, rebuilding dagcache
   3d9be8deba43482be2c81a4cb4be1f10d85fa8bc
   6626247b7dc8f231b183b8a4761c89139baca2ad
   a1983dd7fb19cbd83ad5a1c2fc8bf3d775dea12f
@@ -249,13 +275,16 @@
   c5864c9d16fb3431fe2c175ff84dc6accdbb2c18
   d8ee22687733a1991813560b15128cd9734f4b48
   $ hg log -r ae1ab744f95bfd5b07cf573baef98a778058537b --template 
"{shortest(node,1)}\n"
+  heads mismatch, rebuilding dagcache
   ae
 
 This coveres changelog.findmissing()
   $ hg merge --preview 3d9be8deba43
+  heads mismatch, rebuilding dagcache
 
 This covers manifest.diff()
   $ hg diff -c 3d9be8deba43
+  heads mismatch, rebuilding dagcache
   diff -r c5864c9d16fb -r 3d9be8deba43 beta
   --- /dev/nullThu Jan 01 00:00:00 1970 +
   +++ b/beta   Mon Jan 01 00:00:11 2007 +
diff --git a/hgext/git/index.py b/hgext/git/index.py
--- a/hgext/git/index.py
+++ b/hgext/git/index.py
@@ -216,7 +216,12 @@
 db.commit()
 
 
-def _index_repo(gitrepo, db, progress_factory=lambda *args, **kwargs: None):
+def _index_repo(

Re: [PATCH] hgext.git: decode node IDs back into Python strings (issue6349)

2020-06-09 Thread Augie Fackler
Thanks! I'll review there.

> On Jun 9, 2020, at 16:51, Hollis Blanchard  
> wrote:
> 
> Huh. 'hg email --test' worked fine, but without --test yielded an empty body.
> 
> I've resubmitted as D8622 .
> Hollis Blanchard
> Mentor Graphics Emulation Division
> On 6/9/20 1:20 PM, Hollis Blanchard wrote:
>> ___
>> Mercurial-devel mailing list
>> Mercurial-devel@mercurial-scm.org 
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel 
>> 
> 

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8623: rebase: add environment variable to allow forcing in-memory rebase

2020-06-09 Thread durin42 (Augie Fackler)
durin42 created this revision.
Herald added a reviewer: martinvonz.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Use it in a test case where we know the rebase should proceed without
  incident in-memory, so we can see tracebacks rather than fallbacks.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8623

AFFECTED FILES
  hgext/rebase.py
  tests/test-copies-in-changeset.t

CHANGE DETAILS

diff --git a/tests/test-copies-in-changeset.t b/tests/test-copies-in-changeset.t
--- a/tests/test-copies-in-changeset.t
+++ b/tests/test-copies-in-changeset.t
@@ -356,7 +356,7 @@
   $ hg co -q 0
   $ hg mv a b
   $ hg ci -qm 'rename a to b'
-  $ hg rebase -d 1 --config rebase.experimental.inmemory=yes
+  $ HGNOREALLYONLYINMEMORYREBASE= hg rebase -d 1 --config 
rebase.experimental.inmemory=yes
   rebasing 2:* "rename a to b" (tip) (glob)
   merging a and b to b
   saved backup bundle to $TESTTMP/rebase-rename/.hg/strip-backup/*-*-rebase.hg 
(glob)
diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1067,6 +1067,8 @@
 with ui.configoverride(overrides, b'rebase'):
 return _dorebase(ui, repo, action, opts, inmemory=inmemory)
 except error.InMemoryMergeConflictsError:
+if 'HGNOREALLYONLYINMEMORYREBASE' in os.environ:
+raise
 ui.warn(
 _(
 b'hit merge conflicts; re-running rebase without in-memory'



To: durin42, martinvonz, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8624: wip: this does not help but seems less wrong

2020-06-09 Thread durin42 (Augie Fackler)
durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8624

AFFECTED FILES
  mercurial/mergestate.py

CHANGE DETAILS

diff --git a/mercurial/mergestate.py b/mercurial/mergestate.py
--- a/mercurial/mergestate.py
+++ b/mercurial/mergestate.py
@@ -875,6 +875,7 @@
 self._basectx = ctx
 self.reset()
 self._ancestor_filectxs = {}
+self._state = {}
 
 def add(self, fcl, fco, fca, fd):
 """add a new (potentially?) conflicting file to the merge state"""
@@ -882,7 +883,9 @@
 # TODO(augie): the rebase codepath depends on non-implicit
 # ancestor. I think we should fix things so that ancestor can
 # be passed in to reset().
-self._ancestor_filectxs[fcl.path()] = fca
+print('paths', fcl.path(), fco.path(), fca.path(), fd)
+self._ancestor_filectxs[fd] = fca
+self._state[fd] = fcl, fco, fca
 
 # Since memmergestate isn't mutable yet, these are all trivial
 # implementations used by the "happy path" in merge code.
@@ -956,12 +959,13 @@
 fca = _filectxorabsent(
 nullhex if dfile not in actx else None, actx, dfile
 )
+fcl, fco, fca = self._state[dfile]
 fn = filemerge.premerge if preresolve else filemerge.filemerge
 complete, mergeret, deleted = fn(
 self._repo,
 wctx,
 self._local,
-dfile,  # orig
+fcl.path(),
 fcd,
 fco,
 fca,



To: durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8622: hgext.git: decode node IDs back into Python strings (issue6349)

2020-06-09 Thread hollisb (Hollis Blanchard)
hollisb created this revision.
Herald added a reviewer: durin42.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  db.text_factory = bytes, so the database contains only strings. The object IDs
  we get from pygit2 are Python strings. b'foo' != 'foo'
  
  This change allows the "don't reindex" optimization to work by allowing the
  "cur_cache_heads == cache_heads" comparison a few lines down to succeed.

REPOSITORY
  rHG Mercurial

BRANCH
  stable

REVISION DETAIL
  https://phab.mercurial-scm.org/D8622

AFFECTED FILES
  hgext/git/index.py

CHANGE DETAILS

diff --git a/hgext/git/index.py b/hgext/git/index.py
--- a/hgext/git/index.py
+++ b/hgext/git/index.py
@@ -245,7 +245,10 @@
 # TODO: we should figure out how to incrementally index history
 # (preferably by detecting rewinds!) so that we don't have to do a
 # full changelog walk every time a new commit is created.
-cache_heads = {x[0] for x in db.execute('SELECT node FROM possible_heads')}
+cache_heads = {
+x[0].decode("utf-8")
+for x in db.execute('SELECT node FROM possible_heads')
+}
 walker = None
 cur_cache_heads = {h.hex for h in possible_heads}
 if cur_cache_heads == cache_heads:



To: hollisb, durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8353: debugcommands: create new debugantivirusrunning command

2020-06-09 Thread durin42 (Augie Fackler)
durin42 added a comment.


  Best guess (given I've never hit an AV problem) is that the AV engine would 
lose its lunch on the EICAR file and alert the user. I figure if the AV engine 
isn't picking up on it after 2 seconds then it's probably also not a 
performance issue for us.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8353/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D8353

To: durin42, #hg-reviewers, marmoute
Cc: mercurial-patches, marmoute, mharbison72, indygreg, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] hgext.git: decode node IDs back into Python strings (issue6349)

2020-06-09 Thread Augie Fackler
Empty message? try again?

> On Jun 9, 2020, at 16:20, Hollis Blanchard  
> wrote:
> 
> 

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH] hgext.git: decode node IDs back into Python strings (issue6349)

2020-06-09 Thread Hollis Blanchard

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8621: phabricator: make it clear what happen when no response

2020-06-09 Thread khanchi97 (Sushil khanchi)
khanchi97 created this revision.
Herald added subscribers: mercurial-patches, Kwan.
Herald added a reviewer: hg-reviewers.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8621

AFFECTED FILES
  hgext/phabricator.py
  tests/test-phabricator.t

CHANGE DETAILS

diff --git a/tests/test-phabricator.t b/tests/test-phabricator.t
--- a/tests/test-phabricator.t
+++ b/tests/test-phabricator.t
@@ -670,7 +670,7 @@
   NEW - a959a3f69d8d: one: first commit to review
   NEW - 24a4438154ba: two: second commit to review
   NEW - d235829e802c: 3: a commit with no detailed message
-  Send the above changes to https://phab.mercurial-scm.org/ (yn)? y
+  Send the above changes to https://phab.mercurial-scm.org/ (Y/n)? y
   D8387 - created - a959a3f69d8d: one: first commit to review
   D8387 - created - 24a4438154ba: two: second commit to review
   D8387 - created - d235829e802c: 3: a commit with no detailed message
@@ -734,7 +734,7 @@
   D8387 - 602c4e738243: one: first commit to review
   D8387 - 0124e5474c88: two: second commit to review
   D8387 - e4edb1fe3565: 3: a commit with no detailed message
-  Send the above changes to https://phab.mercurial-scm.org/ (yn)? y
+  Send the above changes to https://phab.mercurial-scm.org/ (Y/n)? y
   D8387 - updated - 602c4e738243: one: first commit to review
   D8387 - updated - 0124e5474c88: two: second commit to review
   D8387 - updated - e4edb1fe3565: 3: a commit with no detailed message
diff --git a/hgext/phabricator.py b/hgext/phabricator.py
--- a/hgext/phabricator.py
+++ b/hgext/phabricator.py
@@ -1650,7 +1650,7 @@
 )
 
 if ui.promptchoice(
-_(b'Send the above changes to %s (yn)?$$  $$ ') % url
+_(b'Send the above changes to %s (Y/n)?$$  $$ ') % url
 ):
 return False
 



To: khanchi97, #hg-reviewers
Cc: Kwan, mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D7177: rebase: introduce optional parent mapping

2020-06-09 Thread martinvonz (Martin von Zweigbergk)
martinvonz added a comment.


  In D7177#128757 , @marmoute 
wrote:
  
  > In D7177#128756 , @martinvonz 
wrote:
  >
  >> In D7177#128740 , @marmoute 
wrote:
  >>
  >>> In D7177#128389 , 
@martinvonz wrote:
  >>>
   Maybe another option is to allow multiple `-d` arguments for this case? 
Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I 
think that's what I'd prefer if we were writing rebase from scratch. I know we 
can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons 
(because we already support that -- it rebases to the highest revnum in the 
set).
  >>>
  >>> That's interresting. How would that works with a practical case ?
  >>
  >> The example I have was meant to be a practical example for how to do it in 
the case given in the patch description :) But let me know if you meant some 
other aspect of "how it works". As I said, I'm not sure ant the BC bit of it at 
least.
  >
  > I meant how that would work in general, esepcially case more complicated 
than the basic base shown by @joerg.sonnenberger.
  
  I think the parents chosen by `-d` should only apply to the roots of the 
rebase set. If your rebase set has multiple roots and only some of them are 
merge commits, then we should probably error out.
  
  Anyway, I'm not sure it's realistic to make it work that way now, especially 
because of how inconsistent it would be with other arguments that accept 
revsets and only care about the highest revnum in the set (I think that was a 
mistake to do, but I understand why it was done that way and it's obviously too 
late to change it).
  
  > Not that in @joerg base, B being ancestors of both C and C', we could 
probably behave better by default directly. Could we not ?
  
  As @joerg said in the patch description, there's no reasonable way to choose 
which of A and B to preserve (the current version of rebase wouldn't preserve 
either and would instead rebase all of A, B, and C).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7177/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7177

To: joerg.sonnenberger, martinvonz, #hg-reviewers, baymax
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D7177: rebase: introduce optional parent mapping

2020-06-09 Thread marmoute (Pierre-Yves David)
marmoute added a comment.


  In D7177#128756 , @martinvonz 
wrote:
  
  > In D7177#128740 , @marmoute 
wrote:
  >
  >> In D7177#128389 , @martinvonz 
wrote:
  >>
  >>> Maybe another option is to allow multiple `-d` arguments for this case? 
Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I 
think that's what I'd prefer if we were writing rebase from scratch. I know we 
can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons 
(because we already support that -- it rebases to the highest revnum in the 
set).
  >>
  >> That's interresting. How would that works with a practical case ?
  >
  > The example I have was meant to be a practical example for how to do it in 
the case given in the patch description :) But let me know if you meant some 
other aspect of "how it works". As I said, I'm not sure ant the BC bit of it at 
least.
  
  I meant how that would work in general, esepcially case more complicated than 
the basic base shown by @joerg.sonnenberger.
  
  Not that in @joerg base, B being ancestors of both C and C', we could 
probably behave better by default directly. Could we not ?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7177/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7177

To: joerg.sonnenberger, martinvonz, #hg-reviewers, baymax
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D7177: rebase: introduce optional parent mapping

2020-06-09 Thread martinvonz (Martin von Zweigbergk)
martinvonz added a comment.


  In D7177#128740 , @marmoute 
wrote:
  
  > In D7177#128389 , @martinvonz 
wrote:
  >
  >> Maybe another option is to allow multiple `-d` arguments for this case? 
Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I 
think that's what I'd prefer if we were writing rebase from scratch. I know we 
can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons 
(because we already support that -- it rebases to the highest revnum in the 
set).
  >
  > That's interresting. How would that works with a practical case ?
  
  The example I have was meant to be a practical example for how to do it in 
the case given in the patch description :) But let me know if you meant some 
other aspect of "how it works". As I said, I'm not sure ant the BC bit of it at 
least.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7177/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7177

To: joerg.sonnenberger, martinvonz, #hg-reviewers, baymax
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Failing tests for mercurial 5.4rc0 and python3

2020-06-09 Thread Pierre-Yves David
This looks like the merge tool is not properly found. Can you report a 
formal bug on https://bz.mercurial-scm.org/ to start a discussion to 
debug this ?


On 4/23/20 3:56 PM, Vladimir Lomov wrote:

Hello,

I want to report about failing tests while building and running mercurial with
python3 (seems only one test connected with python3).

First test: test-merge-tools.t

==
--- /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-merge-tools.t
+++ /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-merge-tools.t.err
@@ -125,7 +125,7 @@
$ hg up -qC 1
$ PATH="`pwd`:/usr/sbin" "$PYTHON" "$BINDIR"/hg merge -r 2
merging f
-  warning: conflicts while merging f! (edit, then use 'hg resolve --mark')
+  merging f failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to 
abandon
[1]
@@ -139,7 +139,7 @@
$ hg up -qC 1
$ PATH="`pwd`:/usr/sbin" "$PYTHON" "$BINDIR"/hg merge -r 2
merging f
-  warning: conflicts while merging f! (edit, then use 'hg resolve --mark')
+  merging f failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to 
abandon
[1]
  
ERROR: test-merge-tools.t output changed

==

If I understand code correctly, the "warning: conflicts while merging" message
is in 'mercurial/filemerge.py' in "annotation" (I not familiar enough with
python to name correctly shown part of the code):
==
@internaltool(
 b'merge',
 fullmerge,
 _(
 b"warning: conflicts while merging %s! "
 b"(edit, then use 'hg resolve --mark')\n"
 ),
 precheck=_mergecheck,
)
==

The "merging f failed" from the same file

==
if tool in internals:
 func = internals[tool]
 mergetype = func.mergetype
 onfailure = func.onfailure
 precheck = func.precheck
 isexternal = False
 else:
 if wctx.isinmemory():
 func = _xmergeimm
 else:
 func = _xmerge
 mergetype = fullmerge
 onfailure = _(b"merging %s failed!\n")
 precheck = None
 isexternal = True
==

function '_filemerge'. I don't known should '@internaltool' work with python3
or not but code suggests that test would fail even if there is no error due to
possible branching and _different_ message on failure.

Second test: test-doctest.py

==
--- /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py.out
+++ /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py.err
@@ -0,0 +1,9 @@
+abort: no repository found in 
'/home/vladimir/tmp/mercurial/src/mercurial-5.4rc0' (.hg not found)!
+Traceback (most recent call last):
+  File "/home/vladimir/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py", 
line 75, in 
+files = subprocess.check_output(
+  File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
+return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
+  File "/usr/lib/python3.8/subprocess.py", line 512, in run
+raise CalledProcessError(retcode, process.args,
+subprocess.CalledProcessError: Command 'hg files --print0 "set:(**.py)"' 
returned non-zero exit status 255.
  
ERROR: test-doctest.py output changed

==

This test was updated recently and it fails for both python3 and python2:

==
--- /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py.out
+++ /XXX/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py.err
@@ -0,0 +1,7 @@
+abort: no repository found in 
'/home/vladimir/tmp/mercurial/src/mercurial-5.4rc0' (.hg not found)!
+Traceback (most recent call last):
+  File "/home/vladimir/tmp/mercurial/src/mercurial-5.4rc0/tests/test-doctest.py", 
line 76, in 
+"hg files --print0 \"%s\"" % fileset, shell=True, cwd=cwd,
+  File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
+

D7944: localrepo: handle ValueError during repository opening

2020-06-09 Thread indygreg (Gregory Szorc)
Closed by commit rHG9e5b4dbe8ff2: localrepo: handle ValueError during 
repository opening (authored by indygreg).
This revision was automatically updated to reflect the committed changes.
This revision was not accepted when it landed; it landed in state "Needs 
Revision".

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D7944?vs=19448=21586

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7944/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7944

AFFECTED FILES
  mercurial/localrepo.py

CHANGE DETAILS

diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -509,6 +509,11 @@
 except OSError as e:
 if e.errno != errno.ENOENT:
 raise
+except ValueError as e:
+# Can be raised on Python 3.8 when path is invalid.
+raise error.Abort(
+_(b'invalid path %s: %s') % (path, pycompat.bytestr(e))
+)
 
 raise error.RepoError(_(b'repository %s not found') % path)
 



To: indygreg, #hg-reviewers, marmoute, baymax, pulkit
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D7177: rebase: introduce optional parent mapping

2020-06-09 Thread marmoute (Pierre-Yves David)
marmoute added a comment.


  In D7177#128389 , @martinvonz 
wrote:
  
  > Maybe another option is to allow multiple `-d` arguments for this case? 
Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I 
think that's what I'd prefer if we were writing rebase from scratch. I know we 
can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons 
(because we already support that -- it rebases to the highest revnum in the 
set).
  
  That's interresting. How would that works with a practical case ?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7177/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7177

To: joerg.sonnenberger, martinvonz, #hg-reviewers, baymax
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable v2] py3: stop using block-buffered stdout to TTY on Python 3

2020-06-09 Thread Pierre-Yves David
Sigh, this seems like a good enough fix for now. We can rewrite the UI 
layer in rust later ;-)


On 6/7/20 12:55 AM, Manuel Jacob wrote:

# HG changeset patch
# User Manuel Jacob 
# Date 1591333053 -7200
#  Fri Jun 05 06:57:33 2020 +0200
# Branch stable
# Node ID d1754bf05591d2aee0f5f9dec185faf912a21190
# Parent  1f114c797961733ea03d0de88390f9555a7edef4
# EXP-Topic fix_block-buffered_stdout
py3: stop using block-buffered stdout to TTY on Python 3

The previous code (added in 227ba1afcb65) incorrectly assumed that
sys.stdout.buffer is line-buffered. However the interpreter initializes it
with a block-buffered stream or an unbuffered stream (when the -u option or
the PYTHONUNBUFFERED environment variable is set), never with a line-buffered
stream.

To see the difference with the hg command, you need to do something slow, e.g.
`hg pull https://www.mercurial-scm.org/repo/hg`. On Python 3 on Linux, without
this patch, all output is printed right before the command ends. With this
patch, output is printed almost immediately.

I did some quick and dirty benchmarking, printing on my terminal.


Unfavorable case:
* for 100 times:
   * for 1000 times:
 * call `ui.write(b'x')`
   * call `ui.write(b'\n')`
* ui.flush()

Results:
CPython 2.7 is unaffected (line-buffered): wall 0.231795 comb 0.23 user 
0.23 sys 0.00
CPython 3.8 before patch (block-buffered): wall 0.190882 comb 0.19 user 
0.19 sys 0.00
CPython 3.8 after patch (unbuffered):  wall 0.654466 comb 0.65 user 
0.48 sys 0.17
CPython 3.8 hand-rolled line-buffered [*]: wall 0.218919 comb 0.22 user 
0.22 sys 0.00


Favorable case:
* for 10 times:
   * call `ui.write(b'Testing write performance\n')`

Results:
CPython 2.7 is unaffected (line-buffered): wall 0.717060 comb 0.71 user 
0.51 sys 0.20
CPython 3.8 before patch (block-buffered): wall 0.255527 comb 0.26 user 
0.18 sys 0.08
CPython 3.8 after patch (unbuffered):  wall 0.616500 comb 0.62 user 
0.45 sys 0.17
CPython 3.8 hand-rolled line-buffered [*]: wall 0.811805 comb 0.81 user 
0.57 sys 0.24


[*] For this, I implemented a simplified version of what is suggested in the
TODO: stdout was set to block-buffered and ui.write() flushed the stream if
the output contains a newline character.

diff -r 1f114c797961 -r d1754bf05591 mercurial/utils/procutil.py
--- a/mercurial/utils/procutil.py   Thu Apr 30 00:33:00 2020 -0400
+++ b/mercurial/utils/procutil.py   Fri Jun 05 06:57:33 2020 +0200
@@ -55,12 +55,20 @@
  # on Windows).
  # Python 3 rolls its own standard I/O streams.
  if isatty(stdout):
+# TODO: Consider mitigating the performance impact of using unbuffered
+# writes on Python 3 and Windows, e.g. by using fully buffered streams and
+# ensuring on a higher level that lines are flushed.
  if pycompat.iswindows:
  # Windows doesn't support line buffering
  stdout = os.fdopen(stdout.fileno(), 'wb', 0)
-elif not pycompat.ispy3:
-# on Python 3, stdout (sys.stdout.buffer) is already line buffered and
-# buffering=1 is not handled in binary mode
+elif pycompat.ispy3:
+# Python 3 doesn't support line buffering on binary streams. Use the
+# underlying unbuffered raw stream. If the ``raw`` attribute doesn't
+# exist, stdout is already unbuffered or replaced by a custom stream.
+# TODO: After Mercurial 5.4, use this code path on Python 3 on Windows.
+# We shouldn't risk changing working behavior in the stable branch.
+stdout = getattr(stdout, 'raw', stdout)
+else:
  stdout = os.fdopen(stdout.fileno(), 'wb', 1)
  
  if pycompat.iswindows:


___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 3 of 3] simplemerge: rewrite flag merging loop as expression

2020-06-09 Thread Pierre-Yves David

Sure, I'll wait for these series to get in first.

On 6/7/20 1:54 PM, Yuya Nishihara wrote:

On Sat, 6 Jun 2020 14:42:00 +0200, Pierre-Yves David wrote:

On 6/6/20 5:04 AM, Yuya Nishihara wrote:

On Fri, 5 Jun 2020 16:24:17 +0200, Pierre-Yves David wrote:

On 6/4/20 4:15 PM, Yuya Nishihara wrote:

# HG changeset patch
# User Yuya Nishihara 
# Date 1591101897 -32400
#  Tue Jun 02 21:44:57 2020 +0900
# Node ID 970abb8ea2a2d6a086ebfdd9a1130b2fb777640e
# Parent  dba0ac9b68381e9610f25d9991bd623f85cbdefd
simplemerge: rewrite flag merging loop as expression

I feel binary operations are more readable.


The fact also merge "flag removal" become implicit and might be less
clear to reader. I like the use of binary operation, but can we add a
comment about the removed flag ?


What do you mean with the "flag removal"?
The logic is unchanged, which is to take the common flags and
then add changes from the base.


If a flag is missing from one of the two merged side, but was presented
in the base, it is "removed".

The logic is unchanged, and the new code behave correctly in this case
(as was the older one)

   However it seems useful to highlight that this code is also dealing
with removal (with a comment mentioning it) so that future reader do not
miss that fact.


Okay, can you send a follow up? It's out of scope of this series. I just
wanted to update things that I felt uncomfortable while reviewing the
original patches.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D7944: localrepo: handle ValueError during repository opening

2020-06-09 Thread marmoute (Pierre-Yves David)
marmoute added a comment.


  This patch is still correct, not sure why it is not it yet.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7944/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7944

To: indygreg, #hg-reviewers, marmoute, baymax
Cc: mercurial-patches, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable] resourceutil: fix location of line comments

2020-06-09 Thread Pierre-Yves David

Good catch, LGTM

On 6/9/20 5:25 AM, Manuel Jacob wrote:

# HG changeset patch
# User Manuel Jacob 
# Date 1591673085 -7200
#  Tue Jun 09 05:24:45 2020 +0200
# Branch stable
# Node ID 6c8384afbf770be2167478fff3cb9b92e1182a06
# Parent  1f114c797961733ea03d0de88390f9555a7edef4
resourceutil: fix location of line comments

These comments slipped out of position when the sources where formatted with
black in 2372284d9457.

diff -r 1f114c797961 -r 6c8384afbf77 mercurial/utils/resourceutil.py
--- a/mercurial/utils/resourceutil.py   Thu Apr 30 00:33:00 2020 -0400
+++ b/mercurial/utils/resourceutil.py   Tue Jun 09 05:24:45 2020 +0200
@@ -23,10 +23,10 @@
  (portable, not much used).
  """
  return (
-pycompat.safehasattr(sys, "frozen")
-or pycompat.safehasattr(sys, "importers")  # new py2exe
-or imp.is_frozen("__main__")  # old py2exe
-)  # tools/freeze
+pycompat.safehasattr(sys, "frozen")  # new py2exe
+or pycompat.safehasattr(sys, "importers")  # old py2exe
+or imp.is_frozen("__main__")  # tools/freeze
+)
  
  
  # the location of data files matching the source code


___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[Bug 6351] New: run-tests.py blacklisting fails to work in some situation

2020-06-09 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=6351

Bug ID: 6351
   Summary: run-tests.py blacklisting fails to work in some
situation
   Product: Mercurial
   Version: unspecified
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: pierre-yves.da...@ens-lyon.org
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

In the heptapod pipeline, the "check" test are supposed to run on their own and
be blacklisted from the other jobs. In practique the "running on their own"
works fine, but the black listing don't. Here is an example of :

https://foss.heptapod.net/octobus/mercurial-devel/pipelines/6683

I suspect the blacklisting get confused by the fact we run from a parent
directory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8178: heptapod-ci: also run tests for chg on python 2

2020-06-09 Thread marmoute (Pierre-Yves David)
Closed by commit rHGaa568b6c6a10: heptapod-ci: also run tests for chg on python 
2 (authored by marmoute).
This revision was automatically updated to reflect the committed changes.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D8178?vs=20967=21577

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8178/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D8178

AFFECTED FILES
  contrib/heptapod-ci.yml

CHANGE DETAILS

diff --git a/contrib/heptapod-ci.yml b/contrib/heptapod-ci.yml
--- a/contrib/heptapod-ci.yml
+++ b/contrib/heptapod-ci.yml
@@ -79,3 +79,9 @@
 RUNTEST_ARGS: "--rust --blacklist /tmp/check-tests.txt"
 PYTHON: python3
 TEST_HGMODULEPOLICY: "rust+c"
+
+test-py2-chg:
+<<: *runtests
+variables:
+RUNTEST_ARGS: "--blacklist /tmp/check-tests.txt --chg"
+TEST_HGMODULEPOLICY: "c"



To: marmoute, #hg-reviewers, Alphare, pulkit
Cc: mercurial-patches, pulkit, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[Bug 6350] New: test-obsolete-distributed.t: test data contains runtime in output

2020-06-09 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=6350

Bug ID: 6350
   Summary: test-obsolete-distributed.t: test data contains
runtime in output
   Product: Mercurial
   Version: 5.4rc0
  Hardware: All
OS: NetBSD
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: t...@giga.or.at
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

The test test-obsolete-distributed.t fails in 5.4.1 (which is missing from
bugzilla):

---
/scratch/devel/py-mercurial/work/mercurial-5.4.1/tests/test-obsolete-distributed.t
+++
/scratch/devel/py-mercurial/work/mercurial-5.4.1/tests/test-obsolete-distributed.t.err
@@ -146,7 +146,7 @@
   searching for changes
   taking quick initial sample
   query 2; still undecided: 1, sample size is: 1
-  2 total queries in 0.0091s
+  2 total queries in 0.0069s
   1 changesets found
   list of changesets:
   391a2bf12b1b8b05a72400ae36b26d50a091dc22

ERROR: test-obsolete-distributed.t output changed

The runtime shouldn't be in the comparison output, you can't really expect that
to be the same everywhere :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel