[PATCH 3 of 4 STABLE] manifest: make manifestctx store the repo

[Durham Goode]

# HG changeset patch
# User Durham Goode 
# Date 1476837866 25200
#  Tue Oct 18 17:44:26 2016 -0700
# Branch stable
# Node ID 3efece5c59853908d65de53635488361dbf20c49
# Parent  ed607426a3ff4deda8c7f2de8b86d5b6ca976d67
manifest: make manifestctx store the repo

The old manifestctx stored a reference to the revlog. If the inmemory revlog
became invalid, the ctx now held an old copy and would be incorrect. To fix
this, we need the ctx to go through the manifestlog for each access.

This is the same pattern that changectx already uses (it stores the repo, and
accesses commit data through self._repo.changelog).

diff --git a/mercurial/manifest.py b/mercurial/manifest.py
--- a/mercurial/manifest.py
+++ b/mercurial/manifest.py
@@ -1276,7 +1276,7 @@ class manifestlog(object):
 if self._treeinmem:
 m = treemanifestctx(self._revlog, '', node)
 else:
-m = manifestctx(self._revlog, node)
+m = manifestctx(self._repo, node)
 if node != revlog.nullid:
 self._mancache[node] = m
 return m
@@ -1288,8 +1288,8 @@ class manifestctx(object):
 """A class representing a single revision of a manifest, including its
 contents, its parent revs, and its linkrev.
 """
-def __init__(self, revlog, node):
-self._revlog = revlog
+def __init__(self, repo, node):
+self._repo = repo
 self._data = None
 
 self._node = node
@@ -1309,14 +1309,15 @@ class manifestctx(object):
 if self._node == revlog.nullid:
 self._data = manifestdict()
 else:
-text = self._revlog.revision(self._node)
+rl = self._repo.manifestlog._revlog
+text = rl.revision(self._node)
 arraytext = array.array('c', text)
-self._revlog._fulltextcache[self._node] = arraytext
+rl._fulltextcache[self._node] = arraytext
 self._data = manifestdict(text)
 return self._data
 
 def readfast(self):
-rl = self._revlog
+rl = self._repo.manifestlog._revlog
 r = rl.rev(self._node)
 deltaparent = rl.deltaparent(r)
 if deltaparent != revlog.nullrev and deltaparent in rl.parentrevs(r):
@@ -1324,11 +1325,11 @@ class manifestctx(object):
 return self.read()
 
 def readdelta(self):
-revlog = self._revlog
+revlog = self._repo.manifestlog._revlog
 if revlog._usemanifestv2:
 # Need to perform a slow delta
 r0 = revlog.deltaparent(revlog.rev(self._node))
-m0 = manifestctx(revlog, revlog.node(r0)).read()
+m0 = manifestctx(self._repo, revlog.node(r0)).read()
 m1 = self.read()
 md = manifestdict()
 for f, ((n0, fl0), (n1, fl1)) in m0.diff(m1).iteritems():
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 4 of 4 STABLE] manifest: make treemanifestctx store the repo

[Durham Goode]

# HG changeset patch
# User Durham Goode 
# Date 1476837882 25200
#  Tue Oct 18 17:44:42 2016 -0700
# Branch stable
# Node ID d5bc7048144e6c9675134b85aadb9d7b69d406aa
# Parent  3efece5c59853908d65de53635488361dbf20c49
manifest: make treemanifestctx store the repo

Same as in the last commit, the old treemanifestctx stored a reference to the
revlog.  If the inmemory revlog became invalid, the ctx now held an old copy and
would be incorrect. To fix this, we need the ctx to go through the manifestlog
for each access.

This is the same pattern that changectx already uses (it stores the repo, and
accesses commit data through self._repo.changelog).

diff --git a/mercurial/manifest.py b/mercurial/manifest.py
--- a/mercurial/manifest.py
+++ b/mercurial/manifest.py
@@ -1274,7 +1274,7 @@ class manifestlog(object):
 return cachemf
 
 if self._treeinmem:
-m = treemanifestctx(self._revlog, '', node)
+m = treemanifestctx(self._repo, '', node)
 else:
 m = manifestctx(self._repo, node)
 if node != revlog.nullid:
@@ -1344,9 +1344,8 @@ class manifestctx(object):
 return manifestdict(d)
 
 class treemanifestctx(object):
-def __init__(self, revlog, dir, node):
-revlog = revlog.dirlog(dir)
-self._revlog = revlog
+def __init__(self, repo, dir, node):
+self._repo = repo
 self._dir = dir
 self._data = None
 
@@ -1359,23 +1358,27 @@ class treemanifestctx(object):
 #rev = revlog.rev(node)
 #self.linkrev = revlog.linkrev(rev)
 
+def _revlog(self):
+return self._repo.manifestlog._revlog.dirlog(self._dir)
+
 def read(self):
 if not self._data:
+rl = self._revlog()
 if self._node == revlog.nullid:
 self._data = treemanifest()
-elif self._revlog._treeondisk:
+elif rl._treeondisk:
 m = treemanifest(dir=self._dir)
 def gettext():
-return self._revlog.revision(self._node)
+return rl.revision(self._node)
 def readsubtree(dir, subm):
-return treemanifestctx(self._revlog, dir, subm).read()
+return treemanifestctx(self._repo, dir, subm).read()
 m.read(gettext, readsubtree)
 m.setnode(self._node)
 self._data = m
 else:
-text = self._revlog.revision(self._node)
+text = revlog.revision(self._node)
 arraytext = array.array('c', text)
-self._revlog.fulltextcache[self._node] = arraytext
+rl.fulltextcache[self._node] = arraytext
 self._data = treemanifest(dir=self._dir, text=text)
 
 return self._data
@@ -1385,9 +1388,9 @@ class treemanifestctx(object):
 
 def readdelta(self):
 # Need to perform a slow delta
-revlog = self._revlog
+revlog = self._revlog()
 r0 = revlog.deltaparent(revlog.rev(self._node))
-m0 = treemanifestctx(revlog, self._dir, revlog.node(r0)).read()
+m0 = treemanifestctx(self._repo, self._dir, revlog.node(r0)).read()
 m1 = self.read()
 md = treemanifest(dir=self._dir)
 for f, ((n0, fl0), (n1, fl1)) in m0.diff(m1).iteritems():
@@ -1398,7 +1401,7 @@ class treemanifestctx(object):
 return md
 
 def readfast(self):
-rl = self._revlog
+rl = self._revlog()
 r = rl.rev(self._node)
 deltaparent = rl.deltaparent(r)
 if deltaparent != revlog.nullrev and deltaparent in rl.parentrevs(r):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 4 STABLE] manifest: move manifest creation to a helper function

[Durham Goode]

# HG changeset patch
# User Durham Goode 
# Date 1476837171 25200
#  Tue Oct 18 17:32:51 2016 -0700
# Branch stable
# Node ID f4e70498d617737c47371a86c2177146c7b789fe
# Parent  e478f11e418288b8308457303d3ddf6a23f874f8
manifest: move manifest creation to a helper function

A future patch will be moving manifest creation to be inside manifestlog as part
of improving our cache guarantees. bundlerepo and unionrepo currently rely on
being able to hook into manifest creation, so let's temporarily move the actual
manifest creation to a helper function for them to intercept.

In the future manifest.manifest() will disappear entirely and this can
disappear.

diff --git a/mercurial/bundlerepo.py b/mercurial/bundlerepo.py
--- a/mercurial/bundlerepo.py
+++ b/mercurial/bundlerepo.py
@@ -343,8 +343,7 @@ class bundlerepository(localrepo.localre
 self.manstart = self.bundle.tell()
 return c
 
-@localrepo.unfilteredpropertycache
-def manifest(self):
+def _constructmanifest(self):
 self.bundle.seek(self.manstart)
 # consume the header if it exists
 self.bundle.manifestheader()
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -506,6 +506,12 @@ class localrepository(object):
 
 @storecache('00manifest.i')
 def manifest(self):
+return self._constructmanifest()
+
+def _constructmanifest(self):
+# This is a temporary function while we migrate from manifest to
+# manifestlog. It allows bundlerepo and unionrepo to intercept the
+# manifest creation.
 return manifest.manifest(self.svfs)
 
 @property
diff --git a/mercurial/unionrepo.py b/mercurial/unionrepo.py
--- a/mercurial/unionrepo.py
+++ b/mercurial/unionrepo.py
@@ -208,8 +208,7 @@ class unionrepository(localrepo.localrep
 node = self.repo2.changelog.node(rev2)
 return self.changelog.rev(node)
 
-@localrepo.unfilteredpropertycache
-def manifest(self):
+def _constructmanifest(self):
 return unionmanifest(self.svfs, self.repo2.svfs,
  self.unfiltered()._clrev)
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH python-hglib] Add feature to allow hglib user to get call backs for prompts and output

[Jordi Gutiérrez Hermoso]

On Tue, 2016-10-18 at 19:14 -0400, Jordi Gutiérrez Hermoso wrote:
> On Thu, 2016-10-06 at 17:52 +0100, Barry A. Scott wrote:
> > # HG changeset patch
> > # User Barry A. Scott 
> > # Date 1475772736 -3600
> > #  Thu Oct 06 17:52:16 2016 +0100
> > # Branch hglib-gui-features
> > # Node ID 1ac3819a61527836d47f7cd6a113b194c307ffeb
> > # Parent  efc527cc43d7394a5bd0deb1d29c4307592f7528
> > Add feature to allow hglib user to get call backs for prompts and output.
> > 
> > Both pull() and push() have had three new, optiomal, aguments added them.
> 
> Is this really going to be cluttering the output of `hg help
> pull/push`? The longer that gets, the less likely users are to read
> it.

My bad, this is for hglib only. I understand any and all UI options
are welcome there.


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

Re: [PATCH python-hglib] Add feature to allow hglib user to get call backs for prompts and output

[Jordi Gutiérrez Hermoso]

On Thu, 2016-10-06 at 17:52 +0100, Barry A. Scott wrote:
> # HG changeset patch
> # User Barry A. Scott 
> # Date 1475772736 -3600
> #  Thu Oct 06 17:52:16 2016 +0100
> # Branch hglib-gui-features
> # Node ID 1ac3819a61527836d47f7cd6a113b194c307ffeb
> # Parent  efc527cc43d7394a5bd0deb1d29c4307592f7528
> Add feature to allow hglib user to get call backs for prompts and output.
> 
> Both pull() and push() have had three new, optiomal, aguments added them.

Is this really going to be cluttering the output of `hg help
pull/push`? The longer that gets, the less likely users are to read
it.

Indiscriminately growing new options on Mercurial commands, especially
for very niche uses, is very undesirable.


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

Re: [PATCH] manifest: don't store None in fulltextcache

[Martin von Zweigbergk via Mercurial-devel]

On Tue, Oct 18, 2016 at 1:09 PM Durham Goode  wrote:

>
>
> On 10/17/16, 10:58 PM, "Martin von Zweigbergk" 
> wrote:
>
> ># HG changeset patch
> ># User Martin von Zweigbergk 
> ># Date 1476769882 25200
> >#  Mon Oct 17 22:51:22 2016 -0700
> ># Node ID d2c313417026d76cb19534277df3f3a8b6b22425
> ># Parent  87a7c0d403ff29dcae2a41e0516c75bbd9f6a5a8
> >manifest: don't store None in fulltextcache
> >
> >When we read a value from fulltextcache, we expect it to be an array,
> >so we should not store None in it. Found while working on narrowhg.
> >
> >diff -r 87a7c0d403ff -r d2c313417026 mercurial/manifest.py
> >--- a/mercurial/manifest.pyTue Oct 18 02:09:08 2016 +0200
> >+++ b/mercurial/manifest.pyMon Oct 17 22:51:22 2016 -0700
> >@@ -1210,7 +1210,8 @@
> > n = self.addrevision(text, transaction, link, p1, p2)
> > arraytext = array.array('c', text)
> >
> >-self.fulltextcache[n] = arraytext
> >+if arraytext is not None:
> >+self.fulltextcache[n] = arraytext
> >
> > return n
> >
> >@@ -1506,7 +1507,8 @@
> > m = self._newmanifest(text)
> > arraytext = array.array('c', text)
> > self._mancache[node] = m
> >-self.fulltextcache[node] = arraytext
> >+if arraytext is not None:
> >+self.fulltextcache[node] = arraytext
> > return m
> >
> > def readshallow(self, node):
>
> LGTM.  Is there a tree code path that hits this that is not covered by
> tests?
>
>
Yes, what our tests in narrowhg triggered was a line in bundlemanifest:
self.fulltextcache[node].tostring(). The test case was trying to pull from
a bundle. We do have a test case for that in test-treemanifest.t. I don't
know what the difference is. Perhaps something means it gets cached in our
narrowhg test case, but not in the test-treemanifest.t one.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

MercurialEclipse 2.2 problems

[ALESSANDRO PROCOPIO]

Dear Developers,
I'm trying to install MercurialEclipse 2.2 from the MarketPlace some errors
are occurring: "unable to read repository at
https://bitbucket.org/mercurialeclipse/update-site/raw/default/content.xml;
Since this file is not present in this path, in my opinion, the problem
lies here.
Could someone help me?
I look forward to hearing from you soon.

Kind regards,
Alessandro Procopio
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: 4.0 feature freeze has started

[Kevin Bullock]

> On Oct 18, 2016, at 15:17, Kevin Bullock  
> wrote:
> 
> I've merged default into stable and cut a 4.0-rc release. Please remember to 
> update to stable and send only bug fixes, doc fixes, improved messaging,  
> per [1].
> 
> [1]: 
> https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan#Rules_for_code_freeze_and_stable_branch_commits

BTW here's a commit hook I'm experimenting with to prevent myself from 
accidentally breaking the rules:

[hooks]
precommit.code-freeze = test "$(hg branch)" != default -o -z "$(hg log -r 
default::stable -T'{node}\n')"

This is a little too permissive in that it allows queuing on default if someone 
has already been naughty and created a new head there ahead of stable, but I 
don't have a pithy fix for that yet. Suggestions welcome.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

4.0 feature freeze has started

[Kevin Bullock]

I've merged default into stable and cut a 4.0-rc release. Please remember to 
update to stable and send only bug fixes, doc fixes, improved messaging,  
per [1].

[1]: 
https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan#Rules_for_code_freeze_and_stable_branch_commits

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

mercurial@30215: 3 new changesets (3 on stable)

[Mercurial Commits]

3 new changesets (3 on stable) in mercurial:

http://selenic.com/repo/hg//rev/a76e04b674c4
changeset:   30213:a76e04b674c4
branch:  stable
parent:  30030:8d74027bd4e7
user:Wagner Bruna 
date:Tue Oct 11 20:39:47 2016 -0300
summary: i18n-pt_BR: synchronized with 149433e68974

http://selenic.com/repo/hg//rev/fc11bb10425f
changeset:   30214:fc11bb10425f
branch:  stable
parent:  30191:328545c7d8a1
parent:  30213:a76e04b674c4
user:Kevin Bullock 
date:Tue Oct 18 14:13:06 2016 -0500
summary: merge with i18n

http://selenic.com/repo/hg//rev/438173c41587
changeset:   30215:438173c41587
branch:  stable
bookmark:@
tag: tip
parent:  30214:fc11bb10425f
parent:  30212:260af19891f2
user:Kevin Bullock 
date:Tue Oct 18 14:15:15 2016 -0500
summary: merge default into stable for 4.0 code freeze

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

Re: [PATCH] manifest: don't store None in fulltextcache

[Durham Goode]

On 10/17/16, 10:58 PM, "Martin von Zweigbergk"  wrote:

># HG changeset patch
># User Martin von Zweigbergk 
># Date 1476769882 25200
>#  Mon Oct 17 22:51:22 2016 -0700
># Node ID d2c313417026d76cb19534277df3f3a8b6b22425
># Parent  87a7c0d403ff29dcae2a41e0516c75bbd9f6a5a8
>manifest: don't store None in fulltextcache
>
>When we read a value from fulltextcache, we expect it to be an array,
>so we should not store None in it. Found while working on narrowhg.
>
>diff -r 87a7c0d403ff -r d2c313417026 mercurial/manifest.py
>--- a/mercurial/manifest.pyTue Oct 18 02:09:08 2016 +0200
>+++ b/mercurial/manifest.pyMon Oct 17 22:51:22 2016 -0700
>@@ -1210,7 +1210,8 @@
> n = self.addrevision(text, transaction, link, p1, p2)
> arraytext = array.array('c', text)
> 
>-self.fulltextcache[n] = arraytext
>+if arraytext is not None:
>+self.fulltextcache[n] = arraytext
> 
> return n
> 
>@@ -1506,7 +1507,8 @@
> m = self._newmanifest(text)
> arraytext = array.array('c', text)
> self._mancache[node] = m
>-self.fulltextcache[node] = arraytext
>+if arraytext is not None:
>+self.fulltextcache[node] = arraytext
> return m
> 
> def readshallow(self, node):

LGTM.  Is there a tree code path that hits this that is not covered by tests?

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

mercurial@30212: 9 new changesets

[Mercurial Commits]

9 new changesets in mercurial:

http://selenic.com/repo/hg//rev/1894c830ee74
changeset:   30204:1894c830ee74
user:Gábor Stefanik 
date:Tue Oct 11 04:39:47 2016 +0200
summary: copies: make _checkcopies handle copy sequences spanning the TCA 
(issue4028)

http://selenic.com/repo/hg//rev/b4074417b661
changeset:   30205:b4074417b661
user:Mads Kiilerich 
date:Mon Oct 17 19:48:36 2016 +0200
summary: revset: optimize for destination() being "inefficient"

http://selenic.com/repo/hg//rev/d105195436c0
changeset:   30206:d105195436c0
user:Gregory Szorc 
date:Sun Oct 16 11:10:21 2016 -0700
summary: wireproto: compress data from a generator

http://selenic.com/repo/hg//rev/abe723002509
changeset:   30207:abe723002509
user:Martin von Zweigbergk 
date:Mon Oct 17 16:12:12 2016 -0700
summary: treemanifest: fix bad argument order to treemanifestctx

http://selenic.com/repo/hg//rev/87a7c0d403ff
changeset:   30208:87a7c0d403ff
user:Gábor Stefanik 
date:Tue Oct 18 02:09:08 2016 +0200
summary: copies: improve assertions during copy recombination

http://selenic.com/repo/hg//rev/9d06b65c5df2
changeset:   30209:9d06b65c5df2
user:Martin von Zweigbergk 
date:Mon Oct 17 22:51:22 2016 -0700
summary: manifest: don't store None in fulltextcache

http://selenic.com/repo/hg//rev/5e4f16874a9f
changeset:   30210:5e4f16874a9f
user:Pierre-Yves David 
date:Fri Oct 14 02:25:08 2016 +0200
summary: revlog: make 'storedeltachains' a "public" attribute

http://selenic.com/repo/hg//rev/6b0741d6d234
changeset:   30211:6b0741d6d234
user:Pierre-Yves David 
date:Fri Oct 14 01:31:11 2016 +0200
summary: changegroup: skip delta when the underlying revlog do not use them

http://selenic.com/repo/hg//rev/260af19891f2
changeset:   30212:260af19891f2
bookmark:@
tag: tip
user:Gregory Szorc 
date:Sun Oct 16 13:35:23 2016 -0700
summary: changegroup: increase write buffer size to 128k

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

[PATCH python-hglib] Add the abilty to trace the protocol between the client and server

[Barry A. Scott]

# HG changeset patch
# User Barry A. Scott 
# Date 1476809117 -3600
#  Tue Oct 18 17:45:17 2016 +0100
# Node ID 9855e0c3aac7600f82cf1596082a0e7f955360f9
# Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
Add the abilty to trace the protocol between the client and server.

This is useful when debugging issues with driving hg via hglib
where output and error messages can be lost.

Call setprotocoltrace with the name of a trace function or None.
If the trace function is None no tracing is done.

The trace function is called with the direction, the channel-identified
and its data.

diff -r 6f15cb7cc9cb -r 9855e0c3aac7 hglib/client.py
--- a/hglib/client.py   Mon Jul 18 23:40:45 2016 -0500
+++ b/hglib/client.py   Tue Oct 18 17:45:17 2016 +0100
@@ -62,6 +62,18 @@
 if connect:
 self.open()
 
+self._protocoltracefn = None
+
+def setprotocoltrace(self, tracefn=None):
+"""
+if tracefn is None no trace calls will be made.
+Otherwise tracefn is call as tracefn( direction, channel, data )
+direction is 'r' for read from server and 'w' for write to server
+channel is always None when direction is 'w'
+and the channel-identified when the direction is 'r'
+"""
+self._protocoltracefn = tracefn
+
 def __enter__(self):
 if self.server is None:
 self.open()
@@ -119,6 +131,8 @@
 
 def runcommand(self, args, inchannels, outchannels):
 def writeblock(data):
+if self._protocoltracefn is not None:
+self._protocoltracefn('w', None, data)
 self.server.stdin.write(struct.pack(self.inputfmt, len(data)))
 self.server.stdin.write(data)
 self.server.stdin.flush()
@@ -131,6 +145,8 @@
 
 while True:
 channel, data = self._readchannel()
+if self._protocoltracefn is not None:
+self._protocoltracefn('r', channel, data)
 
 # input channels
 if channel in inchannels:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] dirstate: add debug message for debug.dirstate.delaywrite

[Kevin Bullock]

> On Oct 18, 2016, at 10:19, Mads Kiilerich  wrote:
> 
> # HG changeset patch
> # User Mads Kiilerich 
> # Date 1476803223 -7200
> #  Tue Oct 18 17:07:03 2016 +0200
> # Node ID 9329389e9dc752652f7c820255ca5afa346c4e08
> # Parent  cde3cae17cba67f80b9f1b41e5cc5fe3b87cd06f
> dirstate: add debug message for debug.dirstate.delaywrite

Is this series related to the intermittent test failure you described in 
?

Seems like the 2nd patch may be appropriate for stable, the other 2 probably 
need to wait 'til November.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

[PATCH 1 of 3] largefiles: clarify variable name holding file mode

[Mads Kiilerich]

# HG changeset patch
# User Mads Kiilerich 
# Date 1476801939 -7200
#  Tue Oct 18 16:45:39 2016 +0200
# Node ID 6d4322a34c2a543665d702fd10f38f1af6001715
# Parent  26089f5e3b51d0416b985ec78e7facdb3113aa48
largefiles: clarify variable name holding file mode

A follow-up to c01acee367ec.

'st' sounds like the whole stat result while 'mode' is a better name for the
actual file mode.

diff --git a/hgext/largefiles/lfcommands.py b/hgext/largefiles/lfcommands.py
--- a/hgext/largefiles/lfcommands.py
+++ b/hgext/largefiles/lfcommands.py
@@ -510,18 +510,21 @@ def updatelfiles(ui, repo, filelist=None
 lfdirstate.normal(lfile)
 update1 = 1
 
-# copy the state of largefile standin from the repository's
+# copy the exec mode of largefile standin from the repository's
 # dirstate to its state in the lfdirstate.
 rellfile = lfile
 relstandin = lfutil.standin(lfile)
 if wvfs.exists(relstandin):
+# exec is decided by the users permissions using mask 0o100
 standinexec = wvfs.stat(relstandin).st_mode & 0o100
-st = wvfs.stat(rellfile).st_mode
-if standinexec != st & 0o100:
-st &= ~0o111
+st = wvfs.stat(rellfile)
+mode = st.st_mode
+if standinexec != mode & 0o100:
+# first remove all X bits, then shift all R bits to X
+mode &= ~0o111
 if standinexec:
-st |= (st >> 2) & 0o111 & ~util.umask
-wvfs.chmod(rellfile, st)
+mode |= (mode >> 2) & 0o111 & ~util.umask
+wvfs.chmod(rellfile, mode)
 update1 = 1
 
 updated += update1
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] dirstate: add debug message for debug.dirstate.delaywrite

[Mads Kiilerich]

# HG changeset patch
# User Mads Kiilerich 
# Date 1476803223 -7200
#  Tue Oct 18 17:07:03 2016 +0200
# Node ID 9329389e9dc752652f7c820255ca5afa346c4e08
# Parent  cde3cae17cba67f80b9f1b41e5cc5fe3b87cd06f
dirstate: add debug message for debug.dirstate.delaywrite

Show a message like:
  delaying dirstate write 0.305s to record that it was clean
which is kind of obscure but gives a hint that something is going on and helps
debugging. The functionality *is* obscure and I don't know a better way to
describe it briefly.

diff --git a/mercurial/dirstate.py b/mercurial/dirstate.py
--- a/mercurial/dirstate.py
+++ b/mercurial/dirstate.py
@@ -756,6 +756,8 @@ class dirstate(object):
 clock = time.time()
 start = int(clock) - (int(clock) % delaywrite)
 end = start + delaywrite
+self._ui.debug('delaying dirstate write %0.3fs to record'
+   ' that it was clean\n' % (end - clock))
 time.sleep(end - clock)
 now = end # trust our estimate that the end is near now
 break
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2 python-hglib] client: wrap long lines at 80 chars

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1476803024 -32400
#  Wed Oct 19 00:03:44 2016 +0900
# Node ID 1ec4c46d309dcaef7a9bab6415cacbc5caf72dfe
# Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
client: wrap long lines at 80 chars

diff --git a/hglib/client.py b/hglib/client.py
--- a/hglib/client.py
+++ b/hglib/client.py
@@ -571,7 +571,8 @@ class hgclient(object):
 m = re.search(b(r'^committed changeset (\d+):([0-9a-f]+)'), out,
   re.MULTILINE)
 if not m:
-raise ValueError('revision and node not found in hg output: %r' % 
out)
+raise ValueError('revision and node not found in hg output: %r'
+ % out)
 rev, node = m.groups()
 return int(rev), node
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: history at diff blocks level

[Yuya Nishihara]

On Tue, 18 Oct 2016 08:59:58 +0200, Denis Laxalde wrote:
> Jun Wu a écrit :
> > Excerpts from Denis Laxalde's message of 2016-10-03 16:38:17 +0200:
> >>  From UI point of view, the basic idea is to specify a (file name, line
> >> range) pair and the simplest solution I could find is something like:
> >>
> >>hg log/annotate --line-range fromline,toline FILE
> >>
> >> but this does not work well with several files. (Perhaps something like
> >> hg log FILE:fromline:toline would be better.) I also thought about a
> >
> > +1 for "FILE:fromline:toline". It is intuitive and makes sense. A new
> > boolean flag (like "--line-ranges") that enables the syntax explicitly
> > may be necessary. The flag can avoid conflicts with existing matcher syntax,
> > and make it clear that some commands like "add" do not support line ranges.
> 
> "FILE:fromline:toline" is also my favorite option. But I'm not sure I'd
> like to be forced to specify an extra option to be able to use this
> syntax. I'd much prefer if this could be avoided, though we'll indeed
> have to handle conflicts with existing matcher syntax. Or use another
> separator? Any other idea welcome!

How about extending the fileset syntax?

  $ hg log/annotate 'set:FILE:linerange(FROMLINE-TOLINE)'
 # ':' attr-name '(' args ')'

We could have a shorthand operator ('%' just for example):

  $ hg log/annotate set:FILE%FROMLINE-TOLINE

This might look crazy, and I think it's actually crazy, but it could be
extended for log --follow (issue4959):

  $ hg log --follow 'set:FILE:rev(REV)'
___
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

[Yuya Nishihara]

On Tue, 18 Oct 2016 10:12:07 -0400, Augie Fackler wrote:
> On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara  wrote:
> > On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote:
> >> > On Oct 18, 2016, at 09:38, Yuya Nishihara  wrote:
> >> >> After coordinating on irc to figure out what this proposal actually
> >> >> is, I've noticed that the semantics of this "exact" proposal are
> >> >> exactly what "glob" does today, which means (I think) that
> >> >> "files:foo/bar" should be representable as "glob:foo/bar/*" - what am
> >> >> I missing?
> >> >
> >> > Maybe we want a "glob" relative to the repo root?
> >>
> >> As far as I can tell, it already is. "relglob:" is relative to your
> >> location in the repo according to the docs.
> >
> > Unfortunately that isn't.
> >
> > 'glob:' - a glob relative to cwd
> > 'relglob:' - an unrooted glob (*.c matches C files in all 
> > dirs)
> >
> > Don't ask me why. ;-)
> 
> Oh wat. It looks like narrowhg might change this behavior in narrowed
> repositories, thus my additional confusion.
> 
> Maybe we should add "absglob" that is always repo-root-absolute. How
> do we feel about that overall?

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

Re: [PATCH python-hglib] Add the abilty to trace the protocol between the client and server

[Yuya Nishihara]

On Tue, 18 Oct 2016 11:35:20 +0100, Barry Scott wrote:
> > On 16 Oct 2016, at 15:50, Yuya Nishihara  wrote:
> > On Thu, 06 Oct 2016 18:04:47 +0100, Barry A. Scott wrote:
> >> # HG changeset patch
> >> # User Barry A. Scott 
> >> # Date 1475770955 -3600
> >> #  Thu Oct 06 17:22:35 2016 +0100
> >> # Branch hglib-protocol-trace
> >> # Node ID efc527cc43d7394a5bd0deb1d29c4307592f7528
> >> # Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
> >> Add the abilty to trace the protocol between the client and server.
> >> This is useful when debugging issues with driving hg via hglib
> >> where output and error messages can be lost.
> >> 
> >> call setprotocoltrace with the name of a trace function or None.
> >> If the trace function is None no tracing is done.
> >> The trace function is called with the channel and its data.
> > 
> > This generally looks good to me. Can you update the commit message and
> > coding style?
> > 
> > https://www.mercurial-scm.org/wiki/ContributingChanges 
> > 
> > 
> 
> No problem. I have read that link and the coding style and thought that I 
> coded in the
> required style. Can you point to the drop off please?

I think the 80-col rule apply to hglib. You can run check-code.py to find
style issues.

https://selenic.com/repo/hg/file/3.9.2/contrib/check-code.py

% ../mercurial/contrib/check-code.py hglib/*.py
hglib/client.py:574:
 > raise ValueError('revision and node not found in hg output: %r' 
 > % out)
 line too long
hglib/client.py:879:
 > if hasattr(patches, 'read') and hasattr(patches, 'readline'):
 hasattr(foo, bar) is broken, use util.safehasattr(foo, bar) instead
 hasattr(foo, bar) is broken, use util.safehasattr(foo, bar) instead
hglib/context.py:82:
 > def __bool__(self):
 __bool__ should be __nonzero__ in Python 2
hglib/util.py:170:
 > def __bool__(self):
 __bool__ should be __nonzero__ in Python 2
hglib/util.py:209:
 > def popen(args, env={}):
 don't use mutable default arguments

Some of them are false positives.

> >> def runcommand(self, args, inchannels, outchannels):
> >> def writeblock(data):
> >> +if self._protocoltracefn is not None: self._protocoltracefn( 
> >> b'i', data )
> > 
> > Using a fake channel name seems a bit unfortunate. I slightly prefer b'' or
> > None.s
> 
> I reasoned that given:
> 
> stdout is ‘o’
> stderr is ‘e’
> 
> Clearly if there was an actual channel id for stdin the code would use ‘i’.

The stdin here is an output from client to server (c2s). If c2s and s2c pipes
had symmetric protocols, it would be 'I' channel per the rule "required channels
identifiers are uppercase."

https://www.mercurial-scm.org/wiki/CommandServer#Channels

> I could use b’’ or None, but that would just mean I need more code in the 
> callers code mapping
> None or b’’ into ‘i’ for printing.
> 
> It seemed better to have an obvious identifier.

Then, you can add a direction (s2c/c2s) parameter as the protocols are
different.
___
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

[Augie Fackler]

On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara  wrote:
> On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote:
>> > On Oct 18, 2016, at 09:38, Yuya Nishihara  wrote:
>> >> After coordinating on irc to figure out what this proposal actually
>> >> is, I've noticed that the semantics of this "exact" proposal are
>> >> exactly what "glob" does today, which means (I think) that
>> >> "files:foo/bar" should be representable as "glob:foo/bar/*" - what am
>> >> I missing?
>> >
>> > Maybe we want a "glob" relative to the repo root?
>>
>> As far as I can tell, it already is. "relglob:" is relative to your
>> location in the repo according to the docs.
>
> Unfortunately that isn't.
>
> 'glob:' - a glob relative to cwd
> 'relglob:' - an unrooted glob (*.c matches C files in all dirs)
>
> Don't ask me why. ;-)

Oh wat. It looks like narrowhg might change this behavior in narrowed
repositories, thus my additional confusion.

Maybe we should add "absglob" that is always repo-root-absolute. How
do we feel about that overall?
___
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

[Augie Fackler]

> On Oct 18, 2016, at 09:38, Yuya Nishihara  wrote:
> 
>> After coordinating on irc to figure out what this proposal actually
>> is, I've noticed that the semantics of this "exact" proposal are
>> exactly what "glob" does today, which means (I think) that
>> "files:foo/bar" should be representable as "glob:foo/bar/*" - what am
>> I missing?
> 
> Maybe we want a "glob" relative to the repo root?

As far as I can tell, it already is. "relglob:" is relative to your location in 
the repo according to the docs.
___
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

[Yuya Nishihara]

On Tue, 18 Oct 2016 09:07:36 -0400, Augie Fackler wrote:
> On Tue, Oct 18, 2016 at 02:46:52PM +0200, Pierre-Yves David wrote:
> > On 10/18/2016 02:25 AM, Augie Fackler wrote:
> > >On Sun, Oct 16, 2016 at 03:50:10PM +0200, Pierre-Yves David wrote:
> > >>
> > >>
> > >>On 10/08/2016 06:58 PM, Rodrigo Damazio Bovendorp via Mercurial-devel 
> > >>wrote:
> > >>># HG changeset patch
> > >>># User Rodrigo Damazio Bovendorp 
> > >>># Date 1475944120 25200
> > >>>#  Sat Oct 08 09:28:40 2016 -0700
> > >>># Node ID 545efe5a72efdce925a6a3fd3774b350c90b5c55
> > >>># Parent  dbcef8918bbdd8a64d9f79a37bcfa284a26f3a39
> > >>>match: adding non-recursive directory matching
> > >>>
> > >>>This allows one to match all files in a directory, without matching 
> > >>>anything in subdirectories.
> > >>>It's implemented almost identically to path:, except for the regex 
> > >>>termination, which doesn't
> > >>>allow more than one / after the directory name.
> > >>>
> > >>>diff --git a/mercurial/match.py b/mercurial/match.py
> > >>>--- a/mercurial/match.py
> > >>>+++ b/mercurial/match.py
> > >>>@@ -105,6 +105,9 @@
> > >>> 'glob:' - a glob relative to cwd
> > >>> 're:' - a regular expression
> > >>> 'path:' - a path relative to repository root
> > >>>+'files:' - a path relative to repository root, which is 
> > >>>matched
> > >>>+ non-recursively (files inside the directory 
> > >>>will match,
> > >>>+ but subdirectories and files in them won't
> > >>
> > >>The feature seems useful and we should have it.
> > >>
> > >>The current behavior is a bit strange to me. because we have directory 
> > >>being
> > >>implicitly recursed of just 1 level (directory content). Could we have a
> > >>xxx: where path is never recursed for anything. Listing a directory
> > >>content would be an explicite 'xxx:my/directory/path/*'
> > >>
> > >>We could use 'exact' or 'norecursion' for xxx.
> > >
> > >exact: works for me. I think norecusion: is too long, since users will
> > >need to type this.
> >
> > What about my proposal of changing the semantic to be plain exact matching
> > (no implicit matching of files in a matched directory) ?
> >
> > That would move use to:
> >
> >
> > 'files:' - a path relative to repository root, which is
> >  matched non-recursively
> >
> >   exact:foo → match a file 'foo',
> >   exact:foo/* → match content of 'foo' directory,
> >   exact:foo/** → match anything under 'foo',
> 
> After coordinating on irc to figure out what this proposal actually
> is, I've noticed that the semantics of this "exact" proposal are
> exactly what "glob" does today, which means (I think) that
> "files:foo/bar" should be representable as "glob:foo/bar/*" - what am
> I missing?

Maybe we want a "glob" relative to the repo root?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH stable] tests: work around instability that caused test from 4999c12c526b to fail

[Pierre-Yves David]

On 10/18/2016 03:18 PM, Mads Kiilerich wrote:

On 10/18/2016 02:30 PM, Pierre-Yves David wrote:



On 10/18/2016 01:33 AM, Mads Kiilerich wrote:

# HG changeset patch
# User Mads Kiilerich 
# Date 1476746894 -7200
#  Tue Oct 18 01:28:14 2016 +0200
# Branch stable
# Node ID 548f82b480d086c7a551b025fb980cd70187c880
# Parent  328545c7d8a1044330b8a5bfbdd9c2ff08625d6a
tests: work around instability that caused test from 4999c12c526b to
fail


I'm not too sure of what is going on here, Can you elaborate?


I'm also not sure what is going on. I suddenly saw the new test I added
started to fail. Not in the actual test but in the setup code.
Apparently unrelated to other recent changes - the new test just
happened to expose it. Thus, I suggest this workaround for now.


I would be more comfortable if we had a better idea of what is going one 
here. Can you have a deeper look?


Cheers,

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

Re: [PATCH stable] tests: work around instability that caused test from 4999c12c526b to fail

[Mads Kiilerich]

On 10/18/2016 02:30 PM, Pierre-Yves David wrote:



On 10/18/2016 01:33 AM, Mads Kiilerich wrote:

# HG changeset patch
# User Mads Kiilerich 
# Date 1476746894 -7200
#  Tue Oct 18 01:28:14 2016 +0200
# Branch stable
# Node ID 548f82b480d086c7a551b025fb980cd70187c880
# Parent  328545c7d8a1044330b8a5bfbdd9c2ff08625d6a
tests: work around instability that caused test from 4999c12c526b to 
fail


I'm not too sure of what is going on here, Can you elaborate?


I'm also not sure what is going on. I suddenly saw the new test I added 
started to fail. Not in the actual test but in the setup code. 
Apparently unrelated to other recent changes - the new test just 
happened to expose it. Thus, I suggest this workaround for now.


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

Re: [PATCH 1 of 3] vfs: add the possibility to have a "ward" to check vfs usage

[Pierre-Yves David]

On 10/18/2016 03:15 PM, Augie Fackler wrote:

On Fri, Oct 14, 2016 at 03:56:13AM +0200, Pierre-Yves David wrote:

# HG changeset patch
# User Pierre-Yves David 
# Date 1470323266 -7200
#  Thu Aug 04 17:07:46 2016 +0200
# Node ID 678c3cf029eceec20325928cff063ab71ea99761
# Parent  c0410814002f467c24ef07ce73850ba15b306f8e
# EXP-Topic vfs.ward
vfs: add the possibility to have a "ward" to check vfs usage


The word "ward" here is baffling to me. Could it be something like
lockcheckfn or similar that'll be more self-documenting?


I can use whatever other word that would be more appropriate. lets 
switch to IRC to converge on something.


Cheers,

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

Re: [PATCH 1 of 3] vfs: add the possibility to have a "ward" to check vfs usage

[Augie Fackler]

On Fri, Oct 14, 2016 at 03:56:13AM +0200, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1470323266 -7200
> #  Thu Aug 04 17:07:46 2016 +0200
> # Node ID 678c3cf029eceec20325928cff063ab71ea99761
> # Parent  c0410814002f467c24ef07ce73850ba15b306f8e
> # EXP-Topic vfs.ward
> vfs: add the possibility to have a "ward" to check vfs usage

The word "ward" here is baffling to me. Could it be something like
lockcheckfn or similar that'll be more self-documenting?

>
> The function will be called anytime we open a file. The first usage of this
> 'ward' will be to check that lock are properly taken before accessing file.
> Later we might use it to ensure we use the right vfs to access files, allowing
> more vfs to be introduced.
>
> We currently only apply the ward on 'open' operation. We will extend this to
> other operations like copy, creation and removal later. The current 
> readonlyvfs
> seems to have the same shortcoming.
>
> diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
> --- a/mercurial/scmutil.py
> +++ b/mercurial/scmutil.py
> @@ -482,7 +482,8 @@ class vfs(abstractvfs):
>  This class is used to hide the details of COW semantics and
>  remote file access from higher level code.
>  '''
> -def __init__(self, base, audit=True, expandpath=False, realpath=False):
> +def __init__(self, base, audit=True, expandpath=False, realpath=False,
> + ward=None):
>  if expandpath:
>  base = util.expandpath(base)
>  if realpath:
> @@ -491,6 +492,11 @@ class vfs(abstractvfs):
>  self.mustaudit = audit
>  self.createmode = None
>  self._trustnlink = None
> +# optional function to validate operation on file
> +# intended to be user for developer checks.
> +#
> +# XXX should be call for other things than 'open'
> +self._ward = ward
>
>  @property
>  def mustaudit(self):
> @@ -552,6 +558,9 @@ class vfs(abstractvfs):
>  if not text and "b" not in mode:
>  mode += "b" # for that other OS
>
> +if self._ward is not None:
> +self._ward(f, mode, atomictemp)
> +
>  nlink = -1
>  if mode not in ('r', 'rb'):
>  dirname, basename = util.split(f)
> ___
> 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 python-hglib] Add feature to allow hglib user to get call backs for prompts and output

[Yuya Nishihara]

On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
> > On 16 Oct 2016, at 15:36, Yuya Nishihara  wrote:
> > On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
> >> # HG changeset patch
> >> # User Barry A. Scott 
> >> # Date 1475772736 -3600
> >> #  Thu Oct 06 17:52:16 2016 +0100
> >> # Branch hglib-gui-features
> >> # Node ID 1ac3819a61527836d47f7cd6a113b194c307ffeb
> >> # Parent  efc527cc43d7394a5bd0deb1d29c4307592f7528
> >> Add feature to allow hglib user to get call backs for prompts and output.
> > 
> >> The cb prefix was choosen to avoid matching a hg long option name.
> > 
> > That seems fine. merge() already has "cb" argument.
> > 
> >> -def rawcommand(self, args, eh=None, prompt=None, input=None):
> >> +def rawcommand(self, args, eh=None, prompt=None, input=None, 
> >> cbout=None,
> >> +   cberr=None):
> >> """
> >> args is the cmdline (usually built using util.cmdbuilder)
> >> 
> >> @@ -173,9 +174,29 @@
> >> 
> >> input is used to reply to bulk data requests by the server
> >> It receives the max number of bytes to return
> >> +
> >> +cbout is a function that will be called with the stdout data of 
> >> the command
> >> +as it runs.
> >> +
> >> +cberr is a function that will be called with the stderr data of 
> >> the command
> >> +as it runs.
> >> """
> > 
> > Do they need to be separate callbacks? I think prompt() can be extended to
> > take "err" value as an optional third argument.
> 
> There are 2 reasons to have the cbout and cberr call backs. For a push/pull 
> that
> does not prompt it provides the GUI with progress information clearly marked 
> as
> normal, cdout, and error, cberr. The output is also timely, no need to wait 
> for the
> command to complete.

In that case, it'd be nice if we have a generic callback interface like your
another patch. Progress messages aren't limited to push/pull commands.

> When a prompt event happens I found that I cannot rely on figuring out what
> the last prompt was without a timeline of calls to cdout and cderr.

or inspect the last lines of both out/err channels? Anyway it's unreliable to
read the prompt line, so we'll need a better channel protocol in future.

> For example cdout gets the “user:” prompt but cderr gets the “password:”.
> (Why is “password:” sent to stderr? Bug? Feature?)

That is considered a feature of hg, but isn't nice in command-server session.
I made an extension to send more information over the pipe. It's just a hack.
My current plan is to add an option to send prompt, progress, and status
messages to a separate (e.g. 'C'-ontrol) channel.

https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/util/pipeui.py
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] changegroup: skip delta when the underlying revlog do not use them

[Augie Fackler]

On Sun, Oct 16, 2016 at 02:02:23PM +0200, Pierre-Yves David wrote:
>
>
> On 10/14/2016 09:01 AM, Gregory Szorc wrote:
> >Cool. I was going to author this patch when I got back home!
> >
> >This patch will result in CPU regression for old clients having to 
> >re-deltify. It would be nice to have numbers for that. I'm optimistic it is 
> >roughly the same as the server gains and it won't be significant enough to 
> >not take the patch. We also don't have a perf* command to measure 
> >changegroup application for a single component IIRC. So getting data isn't 
> >trivial :/
>
> As you just said, the redeltifying are probably around the same cost than
> the one we save with this patch (6 seconds for a full Mozilla clone). The
> extra cost seems reasonable to me in that case.

Queued these, thanks.

>
> Cheers,
>
> --
> 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] match: adding non-recursive directory matching

[Augie Fackler]

On Tue, Oct 18, 2016 at 02:46:52PM +0200, Pierre-Yves David wrote:
>
>
> On 10/18/2016 02:25 AM, Augie Fackler wrote:
> >On Sun, Oct 16, 2016 at 03:50:10PM +0200, Pierre-Yves David wrote:
> >>
> >>
> >>On 10/08/2016 06:58 PM, Rodrigo Damazio Bovendorp via Mercurial-devel wrote:
> >>># HG changeset patch
> >>># User Rodrigo Damazio Bovendorp 
> >>># Date 1475944120 25200
> >>>#  Sat Oct 08 09:28:40 2016 -0700
> >>># Node ID 545efe5a72efdce925a6a3fd3774b350c90b5c55
> >>># Parent  dbcef8918bbdd8a64d9f79a37bcfa284a26f3a39
> >>>match: adding non-recursive directory matching
> >>>
> >>>This allows one to match all files in a directory, without matching 
> >>>anything in subdirectories.
> >>>It's implemented almost identically to path:, except for the regex 
> >>>termination, which doesn't
> >>>allow more than one / after the directory name.
> >>>
> >>>diff --git a/mercurial/match.py b/mercurial/match.py
> >>>--- a/mercurial/match.py
> >>>+++ b/mercurial/match.py
> >>>@@ -105,6 +105,9 @@
> >>> 'glob:' - a glob relative to cwd
> >>> 're:' - a regular expression
> >>> 'path:' - a path relative to repository root
> >>>+'files:' - a path relative to repository root, which is 
> >>>matched
> >>>+ non-recursively (files inside the directory will 
> >>>match,
> >>>+ but subdirectories and files in them won't
> >>
> >>The feature seems useful and we should have it.
> >>
> >>The current behavior is a bit strange to me. because we have directory being
> >>implicitly recursed of just 1 level (directory content). Could we have a
> >>xxx: where path is never recursed for anything. Listing a directory
> >>content would be an explicite 'xxx:my/directory/path/*'
> >>
> >>We could use 'exact' or 'norecursion' for xxx.
> >
> >exact: works for me. I think norecusion: is too long, since users will
> >need to type this.
>
> What about my proposal of changing the semantic to be plain exact matching
> (no implicit matching of files in a matched directory) ?
>
> That would move use to:
>
>
> 'files:' - a path relative to repository root, which is
>  matched non-recursively
>
>   exact:foo → match a file 'foo',
>   exact:foo/* → match content of 'foo' directory,
>   exact:foo/** → match anything under 'foo',

After coordinating on irc to figure out what this proposal actually
is, I've noticed that the semantics of this "exact" proposal are
exactly what "glob" does today, which means (I think) that
"files:foo/bar" should be representable as "glob:foo/bar/*" - what am
I missing?

(Sorry for not catching this far earlier in this discussion :( )

>
> Cheers,
>
> --
> Pierre-Yves David
___
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

[Pierre-Yves David]

On 10/18/2016 02:25 AM, Augie Fackler wrote:

On Sun, Oct 16, 2016 at 03:50:10PM +0200, Pierre-Yves David wrote:



On 10/08/2016 06:58 PM, Rodrigo Damazio Bovendorp via Mercurial-devel wrote:

# HG changeset patch
# User Rodrigo Damazio Bovendorp 
# Date 1475944120 25200
#  Sat Oct 08 09:28:40 2016 -0700
# Node ID 545efe5a72efdce925a6a3fd3774b350c90b5c55
# Parent  dbcef8918bbdd8a64d9f79a37bcfa284a26f3a39
match: adding non-recursive directory matching

This allows one to match all files in a directory, without matching anything in 
subdirectories.
It's implemented almost identically to path:, except for the regex termination, 
which doesn't
allow more than one / after the directory name.

diff --git a/mercurial/match.py b/mercurial/match.py
--- a/mercurial/match.py
+++ b/mercurial/match.py
@@ -105,6 +105,9 @@
 'glob:' - a glob relative to cwd
 're:' - a regular expression
 'path:' - a path relative to repository root
+'files:' - a path relative to repository root, which is matched
+ non-recursively (files inside the directory will 
match,
+ but subdirectories and files in them won't


The feature seems useful and we should have it.

The current behavior is a bit strange to me. because we have directory being
implicitly recursed of just 1 level (directory content). Could we have a
xxx: where path is never recursed for anything. Listing a directory
content would be an explicite 'xxx:my/directory/path/*'

We could use 'exact' or 'norecursion' for xxx.


exact: works for me. I think norecusion: is too long, since users will
need to type this.


What about my proposal of changing the semantic to be plain exact 
matching (no implicit matching of files in a matched directory) ?


That would move use to:


'files:' - a path relative to repository root, which is
 matched non-recursively

  exact:foo → match a file 'foo',
  exact:foo/* → match content of 'foo' directory,
  exact:foo/** → match anything under 'foo',

Cheers,

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

Re: [PATCH] manifest: don't store None in fulltextcache

[Pierre-Yves David]

On 10/18/2016 07:58 AM, Martin von Zweigbergk via Mercurial-devel wrote:

# HG changeset patch
# User Martin von Zweigbergk 
# Date 1476769882 25200
#  Mon Oct 17 22:51:22 2016 -0700
# Node ID d2c313417026d76cb19534277df3f3a8b6b22425
# Parent  87a7c0d403ff29dcae2a41e0516c75bbd9f6a5a8
manifest: don't store None in fulltextcache


Apparently it was still the october 17th when you mailed that ;-)

I've pushed it.

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

Re: [PATCH python-hglib] Add the abilty to trace the protocol between the client and server

[Barry Scott]

> On 16 Oct 2016, at 15:50, Yuya Nishihara  wrote:
> 
> On Thu, 06 Oct 2016 18:04:47 +0100, Barry A. Scott wrote:
>> # HG changeset patch
>> # User Barry A. Scott 
>> # Date 1475770955 -3600
>> #  Thu Oct 06 17:22:35 2016 +0100
>> # Branch hglib-protocol-trace
>> # Node ID efc527cc43d7394a5bd0deb1d29c4307592f7528
>> # Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
>> Add the abilty to trace the protocol between the client and server.
>> This is useful when debugging issues with driving hg via hglib
>> where output and error messages can be lost.
>> 
>> call setprotocoltrace with the name of a trace function or None.
>> If the trace function is None no tracing is done.
>> The trace function is called with the channel and its data.
> 
> This generally looks good to me. Can you update the commit message and
> coding style?
> 
> https://www.mercurial-scm.org/wiki/ContributingChanges 
> 
> 

No problem. I have read that link and the coding style and thought that I coded 
in the
required style. Can you point to the drop off please?

>> diff -r 6f15cb7cc9cb -r efc527cc43d7 hglib/client.py
>> --- a/hglib/client.pyMon Jul 18 23:40:45 2016 -0500
>> +++ b/hglib/client.pyThu Oct 06 17:22:35 2016 +0100
>> @@ -62,6 +62,15 @@
>> if connect:
>> self.open()
>> 
>> +self._protocoltracefn = None
>> +
>> +def setprotocoltrace( self, tracefn=None ):
>> +"""
>> +if tracefn is None no trace calls will be made.
>> +Otherwise tracefn is call as tracefn( channel, data )
>> +"""
>> +self._protocoltracefn = tracefn
>> +
>> def __enter__(self):
>> if self.server is None:
>> self.open()
>> @@ -119,6 +128,7 @@
>> 
>> def runcommand(self, args, inchannels, outchannels):
>> def writeblock(data):
>> +if self._protocoltracefn is not None: self._protocoltracefn( 
>> b'i', data )
> 
> Using a fake channel name seems a bit unfortunate. I slightly prefer b'' or
> None.s

I reasoned that given:

stdout is ‘o’
stderr is ‘e’

Clearly if there was an actual channel id for stdin the code would use ‘i’.

I could use b’’ or None, but that would just mean I need more code in the 
callers code mapping
None or b’’ into ‘i’ for printing.

It seemed better to have an obvious identifier.

Barry



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

Re: [PATCH python-hglib] Add feature to allow hglib user to get call backs for prompts and output

[Barry Scott]

> On 16 Oct 2016, at 15:36, Yuya Nishihara  wrote:
> 
> On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
>> # HG changeset patch
>> # User Barry A. Scott 
>> # Date 1475772736 -3600
>> #  Thu Oct 06 17:52:16 2016 +0100
>> # Branch hglib-gui-features
>> # Node ID 1ac3819a61527836d47f7cd6a113b194c307ffeb
>> # Parent  efc527cc43d7394a5bd0deb1d29c4307592f7528
>> Add feature to allow hglib user to get call backs for prompts and output.
> 
>> The cb prefix was choosen to avoid matching a hg long option name.
> 
> That seems fine. merge() already has "cb" argument.
> 
>> -def rawcommand(self, args, eh=None, prompt=None, input=None):
>> +def rawcommand(self, args, eh=None, prompt=None, input=None, cbout=None,
>> +   cberr=None):
>> """
>> args is the cmdline (usually built using util.cmdbuilder)
>> 
>> @@ -173,9 +174,29 @@
>> 
>> input is used to reply to bulk data requests by the server
>> It receives the max number of bytes to return
>> +
>> +cbout is a function that will be called with the stdout data of the 
>> command
>> +as it runs.
>> +
>> +cberr is a function that will be called with the stderr data of the 
>> command
>> +as it runs.
>> """
> 
> Do they need to be separate callbacks? I think prompt() can be extended to
> take "err" value as an optional third argument.
> 


There are 2 reasons to have the cbout and cberr call backs. For a push/pull that
does not prompt it provides the GUI with progress information clearly marked as
normal, cdout, and error, cberr. The output is also timely, no need to wait for 
the
command to complete.

When a prompt event happens I found that I cannot rely on figuring out what
the last prompt was without a timeline of calls to cdout and cderr.

For example cdout gets the “user:” prompt but cderr gets the “password:”.
(Why is “password:” sent to stderr? Bug? Feature?)

My code can see that the last message was “password:” on cberr and know
that a password response is required.

I did not change the interface to prompt as it is already used elsewhere and
with the addition of cdout and cderr I can ignore its parameters.

Adding err to the prompt call may, or may not, be useful in other use cases.

Barry

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

Re: history at diff blocks level

[Denis Laxalde]

Jun Wu a écrit :

Excerpts from Denis Laxalde's message of 2016-10-03 16:38:17 +0200:

Hi all,

I've been recently thinking about adding some support in Mercurial to
query repository history based on changes within a given line range in a
file. I think that would be useful in at least two commands:

* log, to restrict history to revisions that modify specified part(s) of
file(s) and only display the diff around specified line range and,

* annotate, to window the annotate result and maybe consider walking
file revision from tip to base to reduce computation costs.

(The "log" part is more interesting, I think.)


I've been thinking about this as well for "fastannotate --deleted". Although
"annotate" is generally easier than "log" in this case: slicing the
annotated lines seems to be enough.


Yes, slicing is trivial and probably acceptable for fastannotate. But
for the "slow" annotate, I was more thinking about walking file
revisions from tip to base in case of a line range query because I tend
to believe this would be more efficient in this case since there's no
reason all revisions of the file to involved in a restricted line range.
The algorithm would just stop when all lines in the range are annotated.
But I think this requires a more significant refactoring (being able to
either walk revision top-down as opposed to down-up currently).


 From UI point of view, the basic idea is to specify a (file name, line
range) pair and the simplest solution I could find is something like:

   hg log/annotate --line-range fromline,toline FILE

but this does not work well with several files. (Perhaps something like
hg log FILE:fromline:toline would be better.) I also thought about a


+1 for "FILE:fromline:toline". It is intuitive and makes sense. A new
boolean flag (like "--line-ranges") that enables the syntax explicitly
may be necessary. The flag can avoid conflicts with existing matcher syntax,
and make it clear that some commands like "add" do not support line ranges.


"FILE:fromline:toline" is also my favorite option. But I'm not sure I'd
like to be forced to specify an extra option to be able to use this
syntax. I'd much prefer if this could be avoided, though we'll indeed
have to handle conflicts with existing matcher syntax. Or use another
separator? Any other idea welcome!


"changes(filename, fromline, toline)" revset (or an extension of the
existing "modifies()" revset), but it seems to me that this would not
fit well for both log and annotate. Suggestions welcome.


I've implemented this part. If you want to give it a try:

  hg pull https://hg.logilab.org/users/dlaxalde/hg -r f19e3327c438

There's only the revset part so far, the diff output is not filtered.



 From the technical point of view, my idea is to rely on
mdiff.allblocks(, ) (used
in both annotate and log, when --patch option is given) to:

1. filter blocks depending on whether they are relevant to specified
line range (e.g., for the log command there's some "!" block), and,

2. track the evolution of the line range across revisions (namely, given
the line range at rev2, find the line range at rev1 in the example above).

I have something working concerning this "low level" aspect, but I'm
somehow getting stuck when it comes to plug things into the log command
call. Namely, I need to pass the "line range" information from one
revision to another during iterations of the loop on revisions in
commands.log() [1] and pass this information down to the mdiff.unidiff()
call [2] which would then give me back another line range to push up to
the outer loop on revisions. Given the complexity of the call chain, I
actually think this is not a very good idea... So the best idea I could
come up with is to filter revisions beforehand (as would a revset do)
but this would imply keeping track of files' line ranges per revision
(to avoid processing diff blocks twice when --patch option is specified
in particular). All in all, it's not clear to me which "tool" I may use
to achieve this (I thought about using the "filematcher" built along
with "revs" in commands.log(), but not really sure it's a good idea).
Maybe I just need a data structure that does not exist yet?
I'd appreciate any pointer to move forward.


I think "changeset_printer" and "diffordiffstat" are worth considering.
"diffordiffstat" is currently stateless. A possible direction is to add a
new stateful "diffordiffstat" that tracks the line ranges.

If revisions are filtered before-hand, the state could be passed to the new
"diffordiffstat" function to avoid unnecessary calculation.

It seems to me that high level diff function like "mdiff.unidiff" could take
an extra parameter "difffunc" which defaults to "allblocks". Then we can
have a "filteredallblocks" passed to "unidiff".



Thanks for these hints, I'll try to dig this way as soon as I get back
to this topic.

--
Denis Laxalde
Logilab http://www.logilab.fr
___
Mercurial-devel mailing