mercurial@44952: 2 new changesets

2020-06-12 Thread Mercurial Commits
2 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/83e41b73d115
changeset:   44951:83e41b73d115
user:Augie Fackler 
date:Tue Jun 09 17:13:26 2020 -0400
summary: git: add debug logging when there's a mismatch in the cached heads 
list

https://www.mercurial-scm.org/repo/hg/rev/a4438263b228
changeset:   44952:a4438263b228
bookmark:@
tag: tip
user:Anton Shestakov 
date:Sat Jun 06 19:19:27 2020 +0800
summary: tests: skip pyflakes for mercurial/thirdparty/

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


Re: [PATCH] hg: copy buffer state to remote ui

2020-06-12 Thread Yuya Nishihara
On Fri, 12 Jun 2020 20:53:20 +0200, Elmar Bartel wrote:
> > [...]
> >   ui0.pushbuffer()
> >   ui1 = ui0.copy(share_buffer=True)
> >   ...
> >   ui0.popbuffer()
> >   # ui1 may outlive and its buffer would be popped implicitly, which might
> >   # not always be what we want, but that's unavoidable.
> What could be done about this: 
> We record in ui._bufferstates[] (as fourth element) the ui which did
> the push and allow/do the pop only when it is done by the same ui.
> But this also would not fix all possible calling-sequence-scenrios
> and then its debatable whether this effort is worth it.

Another option is to create a shallow-copy of the buffers stack, so the
underlying buffer is shared, but the buffers stack itself isn't.

  newui._buffers = oldui._buffers[:]
  ...

Both oldui and newui can/should popbuffer() and will get the data between
oldui.pushbuffer() and self.popbuffer(). newui will remain buffered even
after oldui do popbuffer().

This behavior might be expected if oldui/newui aren't parent/child and should
work as if the underlying fout were replaced with the buffer. But that
wouldn't be always true. So I don't thinks there's the single best way to
implement buffer sharing.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] tests: remove unused creation of file and outdated text

2020-06-12 Thread Yuya Nishihara
On Fri, 12 Jun 2020 23:44:40 +0200, Manuel Jacob wrote:
> # HG changeset patch
> # User Manuel Jacob 
> # Date 1591998236 -7200
> #  Fri Jun 12 23:43:56 2020 +0200
> # Node ID ed470eeaab16b2667092fe87a43be37a4d4c253a
> # Parent  61719b9658b156548634c216ffb2b9188266293b
> # EXP-Topic tests-unused
> tests: remove unused creation of file and outdated text

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


Proposal for cleaning up error reporting

2020-06-12 Thread Rodrigo Damazio via Mercurial-devel
Hi everyone.

Any comments on this early proposal are most welcome:
https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan

Our motivation is to measure the user experience our users are actually
getting, and have realtime pager alerts if e.g. a new client or server
release causes a big change, but not count or alert on errors that are "not
our fault", such as bad user input.
For instance, we have up to 70% error rates on weekends because some people
leave something like "hg status" or "hg log" running in a loop on a
terminal, and their credentials expire - those should not be counted at
all. Even in the middle of workdays, our running error rate is way more
than it "should" be, because we currently measure all non-zero status codes.

Thanks
Rodrigo


smime.p7s
Description: S/MIME Cryptographic Signature
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH] tests: remove unused creation of file and outdated text

2020-06-12 Thread Manuel Jacob
# HG changeset patch
# User Manuel Jacob 
# Date 1591998236 -7200
#  Fri Jun 12 23:43:56 2020 +0200
# Node ID ed470eeaab16b2667092fe87a43be37a4d4c253a
# Parent  61719b9658b156548634c216ffb2b9188266293b
# EXP-Topic tests-unused
tests: remove unused creation of file and outdated text

It was forgotten to remove this in fb0de0bcd297.

diff --git a/tests/test-extension.t b/tests/test-extension.t
--- a/tests/test-extension.t
+++ b/tests/test-extension.t
@@ -1852,17 +1852,6 @@
   GREPME make sure that this is in the help!
   $ cd ..
 
-Show deprecation warning for the use of cmdutil.command
-
-  $ cat > nonregistrar.py < from mercurial import cmdutil
-  > cmdtable = {}
-  > command = cmdutil.command(cmdtable)
-  > @command(b'foo', [], norepo=True)
-  > def foo(ui):
-  > pass
-  > EOF
-
 Prohibit the use of unicode strings as the default value of options
 
   $ hg init $TESTTMP/opt-unicode-default

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


Re: [PATCH] hg: copy buffer state to remote ui

2020-06-12 Thread Elmar Bartel
Hallo Yuya,

> ui._bufferapplylabels of the ui which buffer has been popped by the other.
Ah, thanks! It is pretty clear now:

The use of ui._bufferapplylabels as "cache" for ui._bufferstates[-1][2]
shows a fundamental problem (with shared bufferrs). The condition

ui._bufferstates[-1][2] == ui._bufferapplylabels

is not neccessarily True for all ui created with
ui.copy(share_buffer==True). As soon as pushbuffer() or popbuffer() is
called on any of these ui, the ui._bufferapplylabels value get updated
only on the ui where the *buffer() method was called on.
All other ui will see the change in the (shared)
ui._bufferstates[-1][2], but not on their ui._bufferapplylabels.

> Perhaps, the simplest workaround is to insert a sentinel entry to
> ui._bufferstates by default, and remove ui._bufferapplylabels.
Yep. Removing ui._bufferapplylabels and checking ui._bufferstates[-1][2]
directly will resolve the consistency problem.
The performance penalty is minimal: an addtional check if there is
a buffer and if so an index operation.
This effort is not prohibitive.

> I think remote-ui instance can be obtained from peer.ui.
True!

> > Is see two things here, which could be tested:
> >   - the original ui is not changed, beside the desired effect of
> > having additional content in the buffer.
> >   - the buffer does contain the content from the actions on the
> > remoute-ui
> > Is this the test you suggest?
> 
> Something like that. Maybe you can add the scenario which you're
> trying to fix.
Ok, I'll try to setup something.

> [...]
>   ui0.pushbuffer()
>   ui1 = ui0.copy(share_buffer=True)
>   ...
>   ui0.popbuffer()
>   # ui1 may outlive and its buffer would be popped implicitly, which might
>   # not always be what we want, but that's unavoidable.
What could be done about this: 
We record in ui._bufferstates[] (as fourth element) the ui which did
the push and allow/do the pop only when it is done by the same ui.
But this also would not fix all possible calling-sequence-scenrios
and then its debatable whether this effort is worth it.

> So let's implement (1) and document the caveats.
I'll do that and come back then.

Thank's for your feedback!
Yours,
Elmar.
-- 
LEO GmbH  | Elmar Bartel | 
Mühlweg 2b| Phone: +49 (0)8104-90950141  | No signature here.
D-82054 Sauerlach | Fax:   +49 (0)8104-90950290  |
Germany   | Email: el...@leo.org |

Register Gericht: Amtsgericht München, HRB161107
Geschäftsführer:  Hans Riethmayer, Elmar Bartel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


mercurial@44950: 26 new changesets

2020-06-12 Thread Mercurial Commits
26 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/ce8fe77102f4
changeset:   44925:ce8fe77102f4
parent:  44916:61719b9658b1
user:Yuya Nishihara 
date:Mon May 25 23:02:07 2020 +0900
summary: rust: fix false comment about mpsc::Sender

https://www.mercurial-scm.org/repo/hg/rev/14125dec0e39
changeset:   44926:14125dec0e39
user:Yuya Nishihara 
date:Mon May 25 23:06:50 2020 +0900
summary: rust: leverage .expect() in place of .unwrap() + inline comment

https://www.mercurial-scm.org/repo/hg/rev/472b14da52c2
changeset:   44927:472b14da52c2
user:Josef 'Jeff' Sipek 
date:Mon Jun 01 08:59:48 2020 -0400
summary: git: implement stub prefetch_parents dirstate method

https://www.mercurial-scm.org/repo/hg/rev/935c9f347bdb
changeset:   44928:935c9f347bdb
user:Josef 'Jeff' Sipek 
date:Mon Jun 01 09:22:53 2020 -0400
summary: git: correctly check for type of object when walking

https://www.mercurial-scm.org/repo/hg/rev/3679c88b7f4e
changeset:   44929:3679c88b7f4e
user:Josef 'Jeff' Sipek 
date:Mon Jun 01 09:40:18 2020 -0400
summary: git: don't yield paths for directories when walking

https://www.mercurial-scm.org/repo/hg/rev/47ce28a78f4a
changeset:   44930:47ce28a78f4a
user:Josef 'Jeff' Sipek 
date:Mon Jun 01 09:49:47 2020 -0400
summary: git: properly visit child tree objects when resolving a path

https://www.mercurial-scm.org/repo/hg/rev/f294b4e14fd0
changeset:   44931:f294b4e14fd0
user:Josef 'Jeff' Sipek 
date:Mon Jun 01 11:12:25 2020 -0400
summary: git: implement diff manifest method

https://www.mercurial-scm.org/repo/hg/rev/03ba7de6a8b9
changeset:   44932:03ba7de6a8b9
user:Augie Fackler 
date:Wed Jun 03 11:28:57 2020 -0400
summary: git: add coverage for manifest.diff() so we don't regress

https://www.mercurial-scm.org/repo/hg/rev/33ef8841da62
changeset:   44933:33ef8841da62
user:Martin von Zweigbergk 
date:Wed Jun 03 22:07:26 2020 -0700
summary: help: explain in `hg help flags` that unambiguous prefixes are 
allowed

https://www.mercurial-scm.org/repo/hg/rev/b2e5ec0c596b
changeset:   44934:b2e5ec0c596b
user:Martin von Zweigbergk 
date:Wed Jun 03 12:04:38 2020 -0700
summary: context: fix creation of ProgrammingError to not use non-existent 
field

https://www.mercurial-scm.org/repo/hg/rev/2093b2fc70d4
changeset:   44935:2093b2fc70d4
user:Raphaël Gomès 
date:Tue Jun 02 17:24:37 2020 +0200
summary: rust-dependencies: upgrade `micro-timer` dependency

https://www.mercurial-scm.org/repo/hg/rev/aa568b6c6a10
changeset:   44936:aa568b6c6a10
user:Pierre-Yves David 
date:Wed Feb 26 00:31:23 2020 +0100
summary: heptapod-ci: also run tests for chg on python 2

https://www.mercurial-scm.org/repo/hg/rev/f4361aed565d
changeset:   44937:f4361aed565d
user:Anton Shestakov 
date:Sat Jun 06 19:12:49 2020 +0800
summary: tests: consistently use pyflakes as a Python module

https://www.mercurial-scm.org/repo/hg/rev/3d409f4ff46b
changeset:   44938:3d409f4ff46b
user:Anton Shestakov 
date:Sat Jun 06 19:15:11 2020 +0800
summary: tests: adjust to the new format in pyflakes output

https://www.mercurial-scm.org/repo/hg/rev/818b4f19ef23
changeset:   44939:818b4f19ef23
user:Martin von Zweigbergk 
date:Fri Jun 05 11:10:33 2020 -0700
summary: merge: move an inspection of the dirstate from record to calculate 
phase

https://www.mercurial-scm.org/repo/hg/rev/4c1d39215034
changeset:   44940:4c1d39215034
user:Pierre-Yves David 
date:Wed May 27 12:26:08 2020 +0200
summary: metadata: move computation related to files touched in a dedicated 
module

https://www.mercurial-scm.org/repo/hg/rev/edd08aa193fb
changeset:   44941:edd08aa193fb
user:Pierre-Yves David 
date:Wed May 27 12:45:39 2020 +0200
summary: files: extract code for extra filtering of the `removed` entry 
into copies

https://www.mercurial-scm.org/repo/hg/rev/25512a65cefd
changeset:   44942:25512a65cefd
user:Pierre-Yves David 
date:Wed May 27 12:56:13 2020 +0200
summary: metadata: filter the `removed` set to only contains relevant data

https://www.mercurial-scm.org/repo/hg/rev/9e5b4dbe8ff2
changeset:   44943:9e5b4dbe8ff2
user:Gregory Szorc 
date:Sat Jan 18 10:07:07 2020 -0800
summary: localrepo: handle ValueError during repository opening

https://www.mercurial-scm.org/repo/hg/rev/617cd3b1e9cd
changeset:   44944:617cd3b1e9cd
user:Sushil khanchi 
date:Mon Jun 08 11:43:07 2020 +0530
summary: tests: make it clear what happen when no response entered

https://www.mercurial-scm.org/repo/hg/rev/7a0a1be721a3
changeset:   44945:7a0a1be721a3
user:Sushil khanchi 
date:Tue Jun 09 22:02:09 2020 +0530
summary: phabricator: make it clear what happen when no response


Re: [PATCH] hg: copy buffer state to remote ui

2020-06-12 Thread Yuya Nishihara
On Thu, 11 Jun 2020 18:40:01 +0200, Elmar Bartel wrote:
> > > +# copy buffer state to the remote ui
> > > +if src._buffers:
> > > +dst._buffers = src._buffers
> > > +dst._bufferstates = src._bufferstates
> > > +dst._bufferapplylabels = src._bufferstates[-1][2]
> > 
> > The state would become inconsistent if you do popbuffer() later on.
> Which state: the state of the original ui or the state of
> the remote-ui?

ui._bufferapplylabels of the ui which buffer has been popped by the other.

Perhaps, the simplest workaround is to insert a sentinel entry to
ui._bufferstates by default, and remove ui._bufferapplylabels.

> Anyway, as long as the ui-buffer interface is correctly used
> (properly matching pushpuffer() and popbuffer()) I cannot
> see any state becoming inconsistent.
> Furthermore the remote-ui is not accessible from the user
> calling pushbuffer() on the original ui. This fact brought
> me to the solution which my patch implements.

I think remote-ui instance can be obtained from peer.ui.

> > And this touches the internal of the ui, we'll need some tests so
> > the change wouldn't regress.
> Is see two things here, which could be tested:
>   - the original ui is not changed, beside the desired effect of
> having additional content in the buffer.
>   - the buffer does contain the content from the actions on the
> remoute-ui
> Is this the test you suggest?

Something like that. Maybe you can add the scenario which you're
trying to fix.

> > It might be even better to add a function to copy ui with
> > buffer e.g. ui.copy_sharing_buffer() or ui.copy(share_buffer=True).
> I completly agree here.
> This is the place where copying things should happen.
> And then, remoteui() would just call ui.copy(share_buffer=True).
> 
> Nevertheless: the problems you anticipate (and I do not yet see)
> are then moved to the ui.copy() function. Since what can really
> be done by ui.copy(share_buffer==True)?
> I see two posibilities:
> 
>  1) ui.copy(share_buffer==True) merely does the same, as my patch.
>  2) or, deep-copy the buffer structure to the destination ui.
> 
> With 1) we'd run into the problems you anticipate.
> With 2) the problem arises when/where to copy back the buffered
> content to the buffers of the original ui.

Yep, (2) wouldn't be useful. (1) isn't always correct since there's no
parent-child relation between two ui instances, but I think it makes
more sense.

  ui0.pushbuffer()
  ui1 = ui0.copy(share_buffer=True)
  ...
  ui0.popbuffer()
  # ui1 may outlive and its buffer would be popped implicitly, which might
  # not always be what we want, but that's unavoidable.

So let's implement (1) and document the caveats.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel