Re: [PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 5, 2017, at 9:29 PM, Bryan O'Sullivan  wrote:
> 
> 
> On Sun, Feb 5, 2017 at 1:44 AM, Yuya Nishihara  wrote:
> I like the direction of this patch, but this still involves a behavior
> change. If PAGER variable is set but pager extension disabled, pager will
> be started wrongly.
> 
> I'm inclined to *not* add special code to see if the old pager extension has 
> been disabled. That's achievable by disabling the pager instead. This would 
> require a release note, of course (just in case anyone reads them).

I’m conflicted here: I’ve been chasing my tail on a problem with emacs 
tramp-mode for months, and finally root-caused it to a missing flag in my pager 
settings for less, only triggered by emacs running hg over ssh. It was pretty 
baffling.

On the other hand, it’s clearly the most-right choice to have the pager on as 
part of the recommended configuration. I’ve been using it (as an experiment) at 
work for over a year, and I’ve finally gotten used to it and (for the most 
part) like it.

What do other people think?

> ___
> 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 v2] pager: migrate heavily-used extension into core

[Bryan O'Sullivan]

On Sun, Feb 5, 2017 at 1:44 AM, Yuya Nishihara  wrote:

> I like the direction of this patch, but this still involves a behavior
> change. If PAGER variable is set but pager extension disabled, pager will
> be started wrongly.
>

I'm inclined to *not* add special code to see if the old pager extension
has been disabled. That's achievable by disabling the pager instead. This
would require a release note, of course (just in case anyone reads them).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5479] New: `hg diff --stat` gets confused by lines that start with "-- " or "++ "

[mercurial-bugs]

https://bz.mercurial-scm.org/show_bug.cgi?id=5479

Bug ID: 5479
   Summary: `hg diff --stat` gets confused by lines that start
with "-- " or "++ "
   Product: Mercurial
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: h...@pewpew.net
CC: mercurial-de...@selenic.com

Created attachment 1947
  --> https://bz.mercurial-scm.org/attachment.cgi?id=1947=edit
test that shows the issue (as patch from test-diffstat.t)

Note: possible duplicate of 1123?  That claims that diffstat was an external
tool, though, so while the issue might be similar, I don't think it's a strict
duplicate.

If a line in a file starts with "-- " and is changed, `hg diff --stat` doesn't
count it as a deletion.  Similarly, if the new version of the line starts with
"++ ", it is not counted as an addition.  This can lead to diffstat claiming 0
diffs even if there are some:

  $ hg diff --root .
  diff -r 32e517bb8958 file
  --- a/fileThu Jan 01 00:00:00 1970 +
  +++ b/file* (glob)
  @@ -1,3 +1,3 @@
   line 1
  --- line 2, with dashes
  +++ line 2, switched dashes to plusses
   line 3
This is wrong: does not count either, because both lines look like file
headers.
  $ hg diff --root . --stat
   file |  0
   1 files changed, 0 insertions(+), 0 deletions(-)

-- 
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

Re: Google Summer of Code 2017.

[Pulkit Goyal]

The wiki page for Python GSoC 2017 states that interested organisations
need to apply as a sub-org before 8th Feb[1]. Taking part under the Python
Software Foundation umbrella will be good, we participated last time the
same way. So the deadline is very close.

To speed up things, we need an `admin` who can manage GSoC stuff.  I can be
an admin(yes, I am not participating as a student again :)
​ ​
) in case nobody else is ready.

[1] http://python-gsoc.org/#schedule

On Sat, Feb 4, 2017 at 2:26 PM, Pulkit Goyal <7895pul...@gmail.com> wrote:

> Hello everyone,
>
> Google Summer of Code 2016 was a good experience for both me and
> Piotr. We learned a lot. With GSoC 2017 near, students have started
> asking me about Mercurial taking part in GSoC 2017.
>
> Taking part in GSoC is good as we get new contributors (I am one of
> them). Are we going to take part in GSoC 2017?
>
> Regards
> Pulkit Goyal
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH RFC] contrib: script to generate release notes from commit messages

[Gregory Szorc]

On Fri, Feb 3, 2017 at 12:40 AM, Denis Laxalde 
wrote:

> Gregory Szorc a écrit :
>
>> # HG changeset patch
>> # User Gregory Szorc 
>> # Date 1486108530 28800
>> #  Thu Feb 02 23:55:30 2017 -0800
>> # Node ID 5fe78521b9cb553b9a7c6bd4d96576a35b8d3517
>> # Parent  abf029200e198878a4576a87e095bd8d77d9cea9
>> contrib: script to generate release notes from commit messages
>>
>
> [snip]
>
>
> diff --git a/tests/test-generate-release-notes.t
>> b/tests/test-generate-release-notes.t
>> new file mode 100644
>> --- /dev/null
>> +++ b/tests/test-generate-release-notes.t
>> @@ -0,0 +1,145 @@
>> +Create a fake repo with a relnotes directory and commits
>> +
>> +  $ hg init repo0
>> +  $ export FAKESRCDIR=$TESTTMP/repo0
>> +  $ cd repo0
>> +  $ mkdir relnotes
>> +  $ touch relnotes/4.1.rst
>> +  $ hg commit -A -m 'add relnotes 4.1'
>> +  adding relnotes/4.1.rst
>> +
>> +4.1.rst should be used for relnotes if only available file
>> +
>> +  $ $TESTDIR/../contrib/generate-release-notes
>> +  updating $TESTTMP/repo0/relnotes/4.1.rst with content from 1
>> changesets
>> +
>> +4.1.1.rst is used over 4.1.rst
>> +
>> +  $ touch relnotes/4.1.1.rst
>> +  $ hg commit -A -m 'add relnotes 4.1.1'
>> +  adding relnotes/4.1.1.rst
>> +  $ $TESTDIR/../contrib/generate-release-notes
>> +  updating $TESTTMP/repo0/relnotes/4.1.1.rst with content from 2
>> changesets
>> +
>> +4.2 is used over 4.1.1
>> +
>> +  $ touch relnotes/4.2.rst
>> +  $ hg commit -A -m 'add relnotes 4.2'
>> +  adding relnotes/4.2.rst
>> +  $ $TESTDIR/../contrib/generate-release-notes
>> +  updating $TESTTMP/repo0/relnotes/4.2.rst with content from 3
>> changesets
>> +
>> +A fix with a single line is documented with .. fix::
>> +
>> +  $ touch fix1
>> +  $ hg commit -A -l - << EOF
>> +  > summary line
>> +  >
>> +  > .. fix::
>> +  >
>> +  > this is a simple fix with a single line
>> +  > EOF
>>
>
> I looks strange to have an rst block body that is not indented. Typically
> this is not valid rst as the "fix" directive has no content block here. So
> maybe we should consider indentation? That would also make it possible to
> have more text after a directive like:
>
> .. fix::
>
> this is a simple fix with a single line
>
> more content not to be part of the release notes.
>

Yes, that is a good suggestion. It also makes the parser simpler since you
can just look for indented lines.

I'd still like positive feedback from others before I finish this patch: I
don't want to sink more time in it before there is buy-in to this approach.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] perf: split obtaining chunks from decompression

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1486226866 28800
#  Sat Feb 04 08:47:46 2017 -0800
# Node ID bc36af48a787dc1cd09a993163549054f3c78777
# Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
perf: split obtaining chunks from decompression

Previously, the code was similar to what revlog._chunks() was doing,
which took a raw data segment and delta chain, obtained buffers for
the raw revlog chunks within, and decompressed them.

This commit splits the "get raw chunks" action from "decompress." The
goal of this change is to more accurately measurely decompression
performance.

On a ~50k deltachain for a manifest in mozilla-central:

! full
! wall 0.430548 comb 0.44 user 0.41 sys 0.03 (best of 24)
! deltachain
! wall 0.016053 comb 0.01 user 0.01 sys 0.00 (best of 181)
! read
! wall 0.008078 comb 0.01 user 0.00 sys 0.01 (best of 362)
! rawchunks
! wall 0.033785 comb 0.04 user 0.04 sys 0.00 (best of 100)
! decompress
! wall 0.327126 comb 0.32 user 0.32 sys 0.00 (best of 31)
! patch
! wall 0.032391 comb 0.03 user 0.03 sys 0.00 (best of 100)
! hash
! wall 0.012587 comb 0.01 user 0.01 sys 0.00 (best of 233)

diff --git a/contrib/perf.py b/contrib/perf.py
--- a/contrib/perf.py
+++ b/contrib/perf.py
@@ -993,6 +993,26 @@ def perfrevlogrevision(ui, repo, file_, 
 node = r.lookup(rev)
 rev = r.rev(node)
 
+def getrawchunks(data, chain):
+start = r.start
+length = r.length
+inline = r._inline
+iosize = r._io.size
+buffer = util.buffer
+offset = start(chain[0])
+
+chunks = []
+ladd = chunks.append
+
+for rev in chain:
+chunkstart = start(rev)
+if inline:
+chunkstart += (rev + 1) * iosize
+chunklength = length(rev)
+ladd(buffer(data, chunkstart - offset, chunklength))
+
+return chunks
+
 def dodeltachain(rev):
 if not cache:
 r.clearcaches()
@@ -1003,24 +1023,15 @@ def perfrevlogrevision(ui, repo, file_, 
 r.clearcaches()
 r._chunkraw(chain[0], chain[-1])
 
-def dodecompress(data, chain):
+def dorawchunks(data, chain):
 if not cache:
 r.clearcaches()
-
-start = r.start
-length = r.length
-inline = r._inline
-iosize = r._io.size
-buffer = util.buffer
-offset = start(chain[0])
+getrawchunks(data, chain)
 
-for rev in chain:
-chunkstart = start(rev)
-if inline:
-chunkstart += (rev + 1) * iosize
-chunklength = length(rev)
-b = buffer(data, chunkstart - offset, chunklength)
-r.decompress(b)
+def dodecompress(chunks):
+decomp = r.decompress
+for chunk in chunks:
+decomp(chunk)
 
 def dopatch(text, bins):
 if not cache:
@@ -1039,6 +1050,7 @@ def perfrevlogrevision(ui, repo, file_, 
 
 chain = r._deltachain(rev)[0]
 data = r._chunkraw(chain[0], chain[-1])[1]
+rawchunks = getrawchunks(data, chain)
 bins = r._chunks(chain)
 text = str(bins[0])
 bins = bins[1:]
@@ -1048,7 +1060,8 @@ def perfrevlogrevision(ui, repo, file_, 
 (lambda: dorevision(), 'full'),
 (lambda: dodeltachain(rev), 'deltachain'),
 (lambda: doread(chain), 'read'),
-(lambda: dodecompress(data, chain), 'decompress'),
+(lambda: dorawchunks(data, chain), 'rawchunks'),
+(lambda: dodecompress(rawchunks), 'decompress'),
 (lambda: dopatch(text, bins), 'patch'),
 (lambda: dohash(text), 'hash'),
 ]
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] match: adding non-recursive directory matching

[FUJIWARA Katsunori]

At Fri, 3 Feb 2017 20:26:04 -0800,
Rodrigo Damazio wrote:
> 
> [1  ]
> [1.1  ]
> Finally working on this again.
> On point which I discussed with Martin offline - which feels more intuitive
> as a prefix, "root" or "abs"? (so, "rootfilesin" or "absfilesin"?) We think
> it's "abs", but wanted to make sure that's OK with others.

In FileNamePatternsPlan page, I choose "root" as a name of point, to
which patterns are relative ("root", "cwd", and "any").

I'm OK with "abs", if other thinks that it is more intuitive for
"relative to the root".

BTW, are "cwd" and "any" prefixes are OK with "abs" ?

> Thanks
> 
> 
> On Sun, Jan 29, 2017 at 3:15 AM, FUJIWARA Katsunori 
> wrote:
> 
> >
> > At Fri, 27 Jan 2017 15:14:38 -0800,
> > Rodrigo Damazio wrote:
> > >
> > > [1  ]
> > > [1.1  ]
> > > On Fri, Jan 27, 2017 at 1:03 AM, FUJIWARA Katsunori <
> > fo...@lares.dti.ne.jp>
> > > wrote:
> > >
> > > >
> > > > At Thu, 26 Jan 2017 17:27:17 -0800,
> > > > Rodrigo Damazio wrote:
> > > > >
> > > > > [1  ]
> > > > > [1.1  ]
> > > > > All sounds very reasonable, and "filesin:" or "rootfilesin:" LGTM.
> > > >
> > > > Is it OK for your solution that "rootfilesin:FOO" doesn't match
> > > > against "file FOO", even though your patch posted in this thread made
> > > > "files:FOO" do so ? or, is combining "rootfile:" and "rootfilesin"
> > > > acceptable for your solution ?
> > > >
> > >
> > > Yes, not matching files is fine, and actually the easiest to implement
> > (the
> > > regex is simpler and our custom server doesn't support files anyway).
> > > For that, rootfilesin:foo/bar can produce regex ^foo/bar/[^/]+$ or
> > similar
> > > which would not match a file called bar. visitdir would have to be
> > updated
> > > accordingly, of course, but that shouldn't be too hard (and i can take
> > the
> > > opportunity to add some comments to the code).
> > >
> > > If that looks good to you, let me know and I'll send an updated patch.
> >
> > Sure, LGTM
> >
> > --
> > --
> > [FUJIWARA Katsunori] fo...@lares.dti.ne.jp
> >
> [1.2  ]
> 
> [2 S/MIME Cryptographic Signature ]
> 

-- 
--
[FUJIWARA Katsunori] fo...@lares.dti.ne.jp
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] help: test if "hg help TOPIC" reference is valid

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1485351557 -32400
#  Wed Jan 25 22:39:17 2017 +0900
# Node ID 68e58570e474a8137cebae3139875a44b1e05577
# Parent  184a7119f45bc0e9c3850ca01be27e5265f57346
help: test if "hg help TOPIC" reference is valid

It's quite easy to make a reference invalid by mistake.

diff --git a/tests/test-check-help.t b/tests/test-check-help.t
new file mode 100644
--- /dev/null
+++ b/tests/test-check-help.t
@@ -0,0 +1,25 @@
+#require test-repo
+
+  $ . "$TESTDIR/helpers-testrepo.sh"
+
+  $ cat <<'EOF' > scanhelptopics.py
+  > from __future__ import absolute_import, print_function
+  > import re
+  > import sys
+  > topics = set()
+  > topicre = re.compile(r':hg:`help ([a-z0-9\-.]+)`')
+  > for fname in sys.argv:
+  > with open(fname) as f:
+  > topics.update(m.group(1) for m in topicre.finditer(f.read()))
+  > for s in sorted(topics):
+  > print(s)
+  > EOF
+
+  $ cd "$TESTDIR"/..
+
+Check if ":hg:`help TOPIC`" is valid:
+(use "xargs -n1 -t" to see which help commands are executed)
+
+  $ hg files 'glob:{hgext,mercurial}/**/*.py' \
+  > | xargs python "$TESTTMP/scanhelptopics.py" \
+  > | xargs -n1 hg help > /dev/null
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3] help: uppercase command placeholder

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1485351340 -32400
#  Wed Jan 25 22:35:40 2017 +0900
# Node ID 184a7119f45bc0e9c3850ca01be27e5265f57346
# Parent  84d52bc1463f12a818494181b9f67b25b6fa645f
help: uppercase command placeholder

'command' isn't a valid help topic but a placeholder text. Make it upper
case to avoid confusion.

diff --git a/hgext/mq.py b/hgext/mq.py
--- a/hgext/mq.py
+++ b/hgext/mq.py
@@ -14,7 +14,7 @@ applied patches (subset of known patches
 Known patches are represented as patch files in the .hg/patches
 directory. Applied patches are both patch files and changesets.
 
-Common tasks (use :hg:`help command` for more details)::
+Common tasks (use :hg:`help COMMAND` for more details)::
 
   create new patch  qnew
   import existing patch qimport
diff --git a/tests/test-mq.t b/tests/test-mq.t
--- a/tests/test-mq.t
+++ b/tests/test-mq.t
@@ -25,7 +25,7 @@ help
   Known patches are represented as patch files in the .hg/patches directory.
   Applied patches are both patch files and changesets.
   
-  Common tasks (use 'hg help command' for more details):
+  Common tasks (use 'hg help COMMAND' for more details):
   
 create new patch  qnew
 import existing patch qimport
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Making chg stateful

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-02-05 13:31:29 +0900:
> > > Since we shouldn't pass repo to revlog (it's layering violation), I think
> > > we'll need a thin wrapper for chgcache anyway.
> > 
> > I mentioned this in the second mail, "4) Where to get preloaded results (in
> > worker)", we could just expose some kind of global state, like a
> > "globalcache" module.
> 
> Does it mean any low-level objects will directly access to the global cache?
> That seems ugly (but maybe I'm biased as I'm really allergic to global data.)

Yes. But I don't think the alternative will be better. To avoid using global
state, existing functions need to take extra arguments. That's also
contagious - to preload some low-level objects, all functions through the
call stack need change.

I think the root cause of the fact that global state is considered bad is
because it's mutable by random code, and could make things hard to predict
or debug. We can enforce it to be only mutable by the chg preloading API, so
people cannot modify its state outside the preloading framework. That sounds
good enough to me.

> > > > Things to consider:
> > > > 
> > > >   a) Objects being preloaded have dependency - ex. the obsstore depends 
> > > > on
> > > >  changelog and other things. The preload functions run in a defined
> > > >  order.
> > > 
> > > Maybe dependencies could be passed as arguments?
> > 
> > Ideally, these expensive calculating (ex. obsstore) could be moved to the
> > index object. In the reality, that requires too much work, and obsstore
> > preloading requires a subset of "repo", including "repo.revs".
> > 
> > It's possible to decouple obsstore preloading from the repo object, but that
> > could be a lot of work too.
> 
> My opinion for obsstore is that the most costly part would be populating 100k+
> objects from file, and the other costly parts could be mitigated by some 
> higher-
> level cache in repoview.py.
> 
> But I think this topic was discussed thoroughly between you and pyd before.
> I'm not intended to bring it up again.

Not discussed. I did mention a plan to move it to the index, but that'll
surely take a very long time.

There are multiple levels of logic related to obsstore, namely,
obsstore.getrevs, where the current logic uses revsets (thus needs a heavy
repo object). And repoview.compute*, which calls obsstore.getrevs and does
some extra simple caching and calculation.

Even without obsstore, other things (phases, bookmarks) depend on the
changelog. Therefore I think dependency problem must be solved, if we want
to have more things preloaded to achieve the best perf.

> > > >   b) The index file is not always a single file, depending on "vfs".
> > > 
> > > Yes. vfs could be owned by storage/chgcache class.
> > > 
> > > >   c) The user may want to control what to preload. For example, if they 
> > > > have
> > > >  an incompatible manifest, they could make changelog preloaded, but 
> > > > not
> > > >  manifest.
> > > 
> > > No idea about (c).
> > > 
> > > >   d) Users can add other preloading items easily, not only just the
> > > >  predefined ones.
> > > 
> > > So probably we'll need an extensible table of preloadable items.
> > 
> > If you check my prototype code, it's using a registrar to collect all
> > @preload functions.
> 
> Yes. I wanted to say we would need this kind of abstraction anyway.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel