[PATCH 1 of 4 RFC] bundle2: don't check for whether we can do stream clones

2017-05-08 Thread Siddharth Agarwal
# HG changeset patch
# User Siddharth Agarwal 
# Date 1494289851 25200
#  Mon May 08 17:30:51 2017 -0700
# Node ID b433f29233e32d1c1e665b0c04ae0ef356ce0396
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
bundle2: don't check for whether we can do stream clones

At the moment this isn't used and all stream clones use the legacy protocol.

In an upcoming diff, canperformstreamclone will print out a message if a stream
clone was requested but couldn't happen for some reason. Removing this call
ensures the message isn't printed twice.

diff --git a/mercurial/exchange.py b/mercurial/exchange.py
--- a/mercurial/exchange.py
+++ b/mercurial/exchange.py
@@ -1332,7 +1332,9 @@ def _pullbundle2(pullop):
 For now, the only supported data are changegroup."""
 kwargs = {'bundlecaps': caps20to10(pullop.repo)}
 
-streaming, streamreqs = streamclone.canperformstreamclone(pullop)
+# At the moment we don't do stream clones over bundle2. If that is
+# implemented then here's where the check for that will go.
+streaming = False
 
 # pulling changegroup
 pullop.stepsdone.add('changegroup')
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 4 of 4 RFC] clone: add a server-side option to disable full getbundles (pull-based clones)

2017-05-08 Thread Siddharth Agarwal
# HG changeset patch
# User Siddharth Agarwal 
# Date 1494301361 25200
#  Mon May 08 20:42:41 2017 -0700
# Node ID 68ab508896918ac1d56ae0d2681e39fbf623aa5c
# Parent  052bd5cfe3769b10c64a4a39d9734a2740d44e16
clone: add a server-side option to disable full getbundles (pull-based clones)

For large enough repositories, pull-based clones take too long, and an attempt
to use them indicates some sort of configuration or other issue or maybe an
outdated Mercurial. Add a config option to disable them.

diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
--- a/mercurial/help/config.txt
+++ b/mercurial/help/config.txt
@@ -1660,6 +1660,12 @@ Controls generic server settings.
 When set, clients will try to use the uncompressed streaming
 protocol. (default: False)
 
+``disablefullbundle``
+When set, servers will refuse attempts to do pull-based clones.
+If this option is set, ``preferuncompressed`` and/or clone bundles
+are highly recommended. Partial clones will still be allowed.
+(default: False)
+
 ``validate``
 Whether to validate the completeness of pushed changesets by
 checking that all new file revisions specified in manifests are
diff --git a/mercurial/wireproto.py b/mercurial/wireproto.py
--- a/mercurial/wireproto.py
+++ b/mercurial/wireproto.py
@@ -16,6 +16,7 @@ from .i18n import _
 from .node import (
 bin,
 hex,
+nullid,
 )
 
 from . import (
@@ -841,6 +842,17 @@ def getbundle(repo, proto, others):
   hint=bundle2requiredhint)
 
 try:
+if repo.ui.configbool('server', 'disablefullbundle', False):
+# Check to see if this is a full clone.
+clheads = set(repo.changelog.heads())
+heads = set(opts.get('heads', set()))
+common = set(opts.get('common', []))
+common.discard(nullid)
+if heads == clheads and len(common) == 0:
+raise error.Abort(
+_('server has pull-based clones disabled'),
+hint=_('remove --pull if specified or upgrade Mercurial'))
+
 chunks = exchange.getbundlechunks(repo, 'serve', **opts)
 except error.Abort as exc:
 # cleanly forward Abort error to the client
diff --git a/tests/test-http-bundle1.t b/tests/test-http-bundle1.t
--- a/tests/test-http-bundle1.t
+++ b/tests/test-http-bundle1.t
@@ -365,3 +365,41 @@ Check error reporting while pulling/clon
   this is an exercise
   [255]
   $ cat error.log
+
+disable pull-based clones
+
+  $ hg -R test serve -p $HGPORT1 -d --pid-file=hg4.pid -E error.log --config 
server.disablefullbundle=True
+  $ cat hg4.pid >> $DAEMON_PIDS
+  $ hg clone http://localhost:$HGPORT1/ disable-pull-clone
+  requesting all changes
+  abort: remote error:
+  server has pull-based clones disabled
+  [255]
+
+... but keep stream clones working
+
+  $ hg clone --uncompressed --noupdate http://localhost:$HGPORT1/ 
test-stream-clone
+  streaming all changes
+  * files to transfer, * of data (glob)
+  transferred * in * seconds (* KB/sec) (glob)
+  searching for changes
+  no changes found
+
+... and also keep partial clones and pulls working
+  $ hg clone http://localhost:$HGPORT1 --rev 0 test-partial-clone
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 4 changes to 4 files
+  updating to branch default
+  4 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg pull -R test-partial-clone
+  pulling from http://localhost:$HGPORT1/
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 3 changes to 3 files
+  (run 'hg update' to get a working copy)
+
+  $ cat error.log
diff --git a/tests/test-http.t b/tests/test-http.t
--- a/tests/test-http.t
+++ b/tests/test-http.t
@@ -354,6 +354,44 @@ check abort error reporting while pullin
   [255]
   $ cat error.log
 
+disable pull-based clones
+
+  $ hg -R test serve -p $HGPORT1 -d --pid-file=hg4.pid -E error.log --config 
server.disablefullbundle=True
+  $ cat hg4.pid >> $DAEMON_PIDS
+  $ hg clone http://localhost:$HGPORT1/ disable-pull-clone
+  requesting all changes
+  remote: abort: server has pull-based clones disabled
+  abort: pull failed on remote
+  (remove --pull if specified or upgrade Mercurial)
+  [255]
+
+... but keep stream clones working
+
+  $ hg clone --uncompressed --noupdate http://localhost:$HGPORT1/ 
test-stream-clone
+  streaming all changes
+  * files to transfer, * of data (glob)
+  transferred * in * seconds (*/sec) (glob)
+  searching for changes
+  no changes found
+  $ cat error.log
+
+... and also keep partial clones and pulls working
+  $ hg clone http://localhost:$HGPORT1 --rev 0 test-partial-clone
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 4 changes to 4 files
+  updating to branch default
+  4 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ hg pull -R 

[PATCH 2 of 4 RFC] clone: test streaming disabled because client is missing requirement

2017-05-08 Thread Siddharth Agarwal
# HG changeset patch
# User Siddharth Agarwal 
# Date 149429 25200
#  Mon May 08 18:47:24 2017 -0700
# Node ID 16696b166a70288f05d9306591d66fdd87c51702
# Parent  b433f29233e32d1c1e665b0c04ae0ef356ce0396
clone: test streaming disabled because client is missing requirement

Turns out we had no coverage for this important case.

diff --git a/tests/test-http-bundle1.t b/tests/test-http-bundle1.t
--- a/tests/test-http-bundle1.t
+++ b/tests/test-http-bundle1.t
@@ -66,6 +66,23 @@ try to clone via stream, should use pull
   updating to branch default
   4 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
+try to clone via stream but missing requirements, so should use pull instead
+
+  $ cat > $TESTTMP/removesupportedformat.py << EOF
+  > from mercurial import localrepo
+  > def extsetup(ui):
+  > localrepo.localrepository.supportedformats.remove('generaldelta')
+  > EOF
+
+  $ hg clone --config extensions.rsf=$TESTTMP/removesupportedformat.py 
--uncompressed http://localhost:$HGPORT/ copy3
+  requesting all changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 4 changes to 4 files
+  updating to branch default
+  4 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
 clone via pull
 
   $ hg clone http://localhost:$HGPORT1/ copy-pull
diff --git a/tests/test-http.t b/tests/test-http.t
--- a/tests/test-http.t
+++ b/tests/test-http.t
@@ -57,6 +57,23 @@ try to clone via stream, should use pull
   updating to branch default
   4 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
+try to clone via stream but missing requirements, so should use pull instead
+
+  $ cat > $TESTTMP/removesupportedformat.py << EOF
+  > from mercurial import localrepo
+  > def extsetup(ui):
+  > localrepo.localrepository.supportedformats.remove('generaldelta')
+  > EOF
+
+  $ hg clone --config extensions.rsf=$TESTTMP/removesupportedformat.py 
--uncompressed http://localhost:$HGPORT/ copy3
+  requesting all changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 4 changes to 4 files
+  updating to branch default
+  4 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
 clone via pull
 
   $ hg clone http://localhost:$HGPORT1/ copy-pull
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 3 of 4 RFC] clone: warn when streaming was requested but couldn't be performed

2017-05-08 Thread Siddharth Agarwal
# HG changeset patch
# User Siddharth Agarwal 
# Date 1494298866 25200
#  Mon May 08 20:01:06 2017 -0700
# Node ID 052bd5cfe3769b10c64a4a39d9734a2740d44e16
# Parent  16696b166a70288f05d9306591d66fdd87c51702
clone: warn when streaming was requested but couldn't be performed

This helps both users and the people who support them figure out why
a stream clone couldn't be performed.

In an upcoming patch we're going to add a way for servers to hard
abort on a full getbundle. In those cases servers might expect
clients to perform a stream clone, so it's important to communicate
why one couldn't be done.

diff --git a/mercurial/streamclone.py b/mercurial/streamclone.py
--- a/mercurial/streamclone.py
+++ b/mercurial/streamclone.py
@@ -80,11 +80,21 @@ def canperformstreamclone(pullop, bailif
 streamreqs = remote.capable('streamreqs')
 # This is weird and shouldn't happen with modern servers.
 if not streamreqs:
+pullop.repo.ui.warn(_(
+'warning: stream clone requested but server has them '
+'disabled\n'))
 return False, None
 
 streamreqs = set(streamreqs.split(','))
 # Server requires something we don't support. Bail.
-if streamreqs - repo.supportedformats:
+missingreqs = streamreqs - repo.supportedformats
+if missingreqs:
+pullop.repo.ui.warn(_(
+'warning: stream clone requested but client is missing '
+'requirements: %s\n') % ', '.join(sorted(missingreqs)))
+pullop.repo.ui.warn(
+_('(see https://www.mercurial-scm.org/wiki/MissingRequirement '
+  'for more information)\n'))
 return False, None
 requirements = streamreqs
 
diff --git a/tests/test-http-bundle1.t b/tests/test-http-bundle1.t
--- a/tests/test-http-bundle1.t
+++ b/tests/test-http-bundle1.t
@@ -58,6 +58,7 @@ clone via stream
 try to clone via stream, should use pull instead
 
   $ hg clone --uncompressed http://localhost:$HGPORT1/ copy2
+  warning: stream clone requested but server has them disabled
   requesting all changes
   adding changesets
   adding manifests
@@ -75,6 +76,8 @@ try to clone via stream but missing requ
   > EOF
 
   $ hg clone --config extensions.rsf=$TESTTMP/removesupportedformat.py 
--uncompressed http://localhost:$HGPORT/ copy3
+  warning: stream clone requested but client is missing requirements: 
generaldelta
+  (see https://www.mercurial-scm.org/wiki/MissingRequirement for more 
information)
   requesting all changes
   adding changesets
   adding manifests
diff --git a/tests/test-http.t b/tests/test-http.t
--- a/tests/test-http.t
+++ b/tests/test-http.t
@@ -49,6 +49,7 @@ clone via stream
 try to clone via stream, should use pull instead
 
   $ hg clone --uncompressed http://localhost:$HGPORT1/ copy2
+  warning: stream clone requested but server has them disabled
   requesting all changes
   adding changesets
   adding manifests
@@ -66,6 +67,8 @@ try to clone via stream but missing requ
   > EOF
 
   $ hg clone --config extensions.rsf=$TESTTMP/removesupportedformat.py 
--uncompressed http://localhost:$HGPORT/ copy3
+  warning: stream clone requested but client is missing requirements: 
generaldelta
+  (see https://www.mercurial-scm.org/wiki/MissingRequirement for more 
information)
   requesting all changes
   adding changesets
   adding manifests
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH STABLE] churn: use the non-deprecated template option in the examples

2017-05-08 Thread Matt Harbison
# HG changeset patch
# User Matt Harbison 
# Date 1494299101 14400
#  Mon May 08 23:05:01 2017 -0400
# Node ID 0921d3c7603004a2104fce0c9a5582c1b59291df
# Parent  707683d56e5cbd3fe3453ddab9a57222b998f2af
churn: use the non-deprecated template option in the examples

diff --git a/hgext/churn.py b/hgext/churn.py
--- a/hgext/churn.py
+++ b/hgext/churn.py
@@ -133,7 +133,7 @@
 Examples::
 
   # display count of changed lines for every committer
-  hg churn -t "{author|email}"
+  hg churn -T "{author|email}"
 
   # display daily activity graph
   hg churn -f "%H" -s -c
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 1 of 2] hghave: enable 'serve' on Windows

2017-05-08 Thread Matt Harbison
On Mon, 08 May 2017 01:09:28 -0400, Adrian Buehlmann   
wrote:



On 2017-05-08 06:39, Matt Harbison wrote:

# HG changeset patch
# User Matt Harbison 
# Date 1494183520 14400
#  Sun May 07 14:58:40 2017 -0400
# Node ID 36d9a659b9d76837faaf73fde3f5c5455231c2f9
# Parent  c6cbd0b66465bcaa41f03c9498555f04d3dfbe7c
hghave: enable 'serve' on Windows

I've been using a local hghaveaddon.py to enable this for a couple of  
months
with reasonable success, and 'killdaemons' is already enabled on  
Windows.
There's one failure[1] in test-http-proxy.t that this adds, which I  
can't figure

out.  On occasion, there is also a stacktrace at the end of a run:

Errored test-serve.t: Traceback (most recent call last):
  File "./run-tests.py", line 724, in run
self.tearDown()
  File "./run-tests.py", line 805, in tearDown
killdaemons(entry)
  File "./run-tests.py", line 540, in killdaemons
logfn=vlog)
  File "c:\Users\Matt\Projects\hg\tests\killdaemons.py", line 94, in  
killdaemons

os.unlink(pidfile)
WindowsError: [Error 32] The process cannot access the file because it  
is being
  used by another process:  
'...\\hgtests.gubapm\\child449\\daemon.pids'


https://www.mercurial-scm.org/wiki/UnlinkingFilesOnWindows

The affected test(s) vary from run to run (and most times the error  
doesn't
occur).  The common thread is that the affected tests are missing a  
killdaemons

call.

Still, it seems better to enable a whole class of tests by default, to  
catch

actual regressions when they occur.

[1]  
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html


Ah, I knew there was a trick, thanks.  Since the next thing that happens  
is to recursively delete the test directory, I'm not sure if _that_ step  
will blow up.  When I tried adding 'from mercurial import util' to  
killdaemons.py, it says 'No module named mercurial'.  Other test/*.py  
files do this, so I'm not sure what the issue is.

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


[PATCH] treemanifest: allow manifestrevlog to take an explicit treemanifest arg

2017-05-08 Thread Durham Goode
# HG changeset patch
# User Durham Goode 
# Date 1494292924 25200
#  Mon May 08 18:22:04 2017 -0700
# Node ID 6d02589fd6a76c354aff165503cc72333b14307a
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
treemanifest: allow manifestrevlog to take an explicit treemanifest arg

Previously we relied on the opener options to tell the revlog to be a tree
manifest. This makes it complicated for extensions to create treemanifests and
normal manifests at the same time. Let's add a construtor argument to create a
treemanifest revlog as well.

diff --git a/mercurial/manifest.py b/mercurial/manifest.py
--- a/mercurial/manifest.py
+++ b/mercurial/manifest.py
@@ -1175,25 +1175,29 @@ class manifestrevlog(revlog.revlog):
 '''A revlog that stores manifest texts. This is responsible for caching the
 full-text manifest contents.
 '''
-def __init__(self, opener, dir='', dirlogcache=None, indexfile=None):
+def __init__(self, opener, dir='', dirlogcache=None, indexfile=None,
+ treemanifest=False):
 """Constructs a new manifest revlog
 
 `indexfile` - used by extensions to have two manifests at once, like
 when transitioning between flatmanifeset and treemanifests.
+
+`treemanifest` - used to indicate this is a tree manifest revlog. If 
the
+treemanifest opener option is set to True, this argument is ignored.
 """
 # During normal operations, we expect to deal with not more than four
 # revs at a time (such as during commit --amend). When rebasing large
 # stacks of commits, the number can go up, hence the config knob below.
 cachesize = 4
-usetreemanifest = False
+optiontreemanifest = False
 usemanifestv2 = False
 opts = getattr(opener, 'options', None)
 if opts is not None:
 cachesize = opts.get('manifestcachesize', cachesize)
-usetreemanifest = opts.get('treemanifest', usetreemanifest)
+optiontreemanifest = opts.get('treemanifest', False)
 usemanifestv2 = opts.get('manifestv2', usemanifestv2)
 
-self._treeondisk = usetreemanifest
+self._treeondisk = optiontreemanifest or treemanifest
 self._usemanifestv2 = usemanifestv2
 
 self._fulltextcache = util.lrucachedict(cachesize)
@@ -1232,7 +1236,8 @@ class manifestrevlog(revlog.revlog):
 assert self._treeondisk
 if dir not in self._dirlogcache:
 self._dirlogcache[dir] = manifestrevlog(self.opener, dir,
-self._dirlogcache)
+self._dirlogcache,
+treemanifest=True)
 return self._dirlogcache[dir]
 
 def add(self, m, transaction, link, p1, p2, added, removed, readtree=None):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 6 of 7] osutil: use PYMODULEINIT

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494288978 25200
#  Mon May 08 17:16:18 2017 -0700
# Node ID ad8cf58a8ba5bf96e6020eb88560c283eb7463c6
# Parent  219c4e0d41d807078e3cc9663da11243e81625dd
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r ad8cf58a8ba5
osutil: use PYMODULEINIT

diff --git a/mercurial/osutil.c b/mercurial/osutil.c
--- a/mercurial/osutil.c
+++ b/mercurial/osutil.c
@@ -1302,27 +1302,7 @@ static PyMethodDef methods[] = {
 };
 
-#ifdef IS_PY3K
-static struct PyModuleDef osutil_module = {
-   PyModuleDef_HEAD_INIT,
-   "osutil",
-   osutil_doc,
-   -1,
-   methods
-};
+static int precheck(void) {
+   return PyType_Ready(_stat_type);
+}
 
-PyMODINIT_FUNC PyInit_osutil(void)
-{
-   if (PyType_Ready(_stat_type) < 0)
-   return NULL;
-
-   return PyModule_Create(_module);
-}
-#else
-PyMODINIT_FUNC initosutil(void)
-{
-   if (PyType_Ready(_stat_type) == -1)
-   return;
-
-   Py_InitModule3("osutil", methods, osutil_doc);
-}
-#endif
+PYMODULEINIT(osutil, methods, osutil_doc, 1, precheck, NULL);
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 7 of 7] parsers: use PYMODULEINIT

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494290762 25200
#  Mon May 08 17:46:02 2017 -0700
# Node ID b9a58a643dcc103d122e02c66a4545820fa60807
# Parent  ad8cf58a8ba5bf96e6020eb88560c283eb7463c6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r b9a58a643dcc
parsers: use PYMODULEINIT

diff --git a/mercurial/parsers.c b/mercurial/parsers.c
--- a/mercurial/parsers.c
+++ b/mercurial/parsers.c
@@ -2855,5 +2855,5 @@ void dirs_module_init(PyObject *mod);
 void manifest_module_init(PyObject *mod);
 
-static void module_init(PyObject *mod)
+static int module_init(PyObject *mod)
 {
/* This module constant has two purposes.  First, it lets us unit test
@@ -2873,5 +2873,5 @@ static void module_init(PyObject *mod)
if (PyType_Ready() < 0 ||
PyType_Ready() < 0)
-   return;
+   return -1;
Py_INCREF();
PyModule_AddObject(mod, "index", (PyObject *));
@@ -2884,4 +2884,5 @@ static void module_init(PyObject *mod)
if (nullentry)
PyObject_GC_UnTrack(nullentry);
+   return 0;
 }
 
@@ -2912,32 +2913,4 @@ static int check_python_version(void)
 }
 
-#ifdef IS_PY3K
-static struct PyModuleDef parsers_module = {
-   PyModuleDef_HEAD_INIT,
-   "parsers",
-   parsers_doc,
-   -1,
-   methods
-};
-
-PyMODINIT_FUNC PyInit_parsers(void)
-{
-   PyObject *mod;
-
-   if (check_python_version() == -1)
-   return NULL;
-   mod = PyModule_Create(_module);
-   module_init(mod);
-   return mod;
-}
-#else
-PyMODINIT_FUNC initparsers(void)
-{
-   PyObject *mod;
-
-   if (check_python_version() == -1)
-   return;
-   mod = Py_InitModule3("parsers", methods, parsers_doc);
-   module_init(mod);
-}
-#endif
+PYMODULEINIT(parsers, methods, parsers_doc, 1, check_python_version,
+module_init);
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 7] util: add a macro initializing CPython modules

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494288921 25200
#  Mon May 08 17:15:21 2017 -0700
# Node ID a2c5e183cafca6d58a0dd986870ac620be1fb107
# Parent  52ec3072fe46bc4b193b6273357e3cc40b4421ad
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r a2c5e183cafc
util: add a macro initializing CPython modules

This will greatly simplify C module initialization code. The signature
requires a "version" field to help detect incompatible ".so" modules usually
caused by forgetting to build.

diff --git a/mercurial/util.h b/mercurial/util.h
--- a/mercurial/util.h
+++ b/mercurial/util.h
@@ -43,3 +43,43 @@ typedef unsigned char bool;
 #endif
 
+#ifdef IS_PY3K
+#define PYMODULEINIT(name, methods, doc, version, precheck, postinit) \
+   static struct PyModuleDef  name ## _module = { \
+   PyModuleDef_HEAD_INIT, \
+   #name, \
+   doc, \
+   -1, \
+   methods \
+   }; \
+   PyMODINIT_FUNC PyInit_ ## name(void) \
+   { \
+   PyObject *m; \
+   if (precheck && ((int (*)(void))precheck)() == -1) \
+   return NULL; \
+   m = PyModule_Create(&(name ## _module)); \
+   if (m == NULL) \
+   return NULL; \
+   if (PyModule_AddIntConstant(m, "version", version) == -1) \
+   return NULL; \
+   if (postinit && ((int (*)(PyObject *))postinit)(m) == -1) \
+   return NULL; \
+   return m; \
+   }
+#else
+#define PYMODULEINIT(name, methods, doc, version, precheck, postinit) \
+   PyMODINIT_FUNC (init ## name)(void) \
+   { \
+   PyObject *m; \
+   if (precheck && ((int (*)(void))precheck)() == -1) \
+   return; \
+   m = Py_InitModule3(#name, methods, doc); \
+   if (m == NULL) \
+   return; \
+   if (PyModule_AddIntConstant(m, "version", version) == -1) \
+   return; \
+   if (postinit != NULL) \
+   ((int (*)(PyObject *))postinit)(m); \
+   }
+#endif
+
 #endif /* _HG_UTIL_H_ */
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 7] base85: use PYMODULEINIT

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494289632 25200
#  Mon May 08 17:27:12 2017 -0700
# Node ID 1d76f329321de2af7afb59dc06c61bae87078481
# Parent  a2c5e183cafca6d58a0dd986870ac620be1fb107
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 1d76f329321d
base85: use PYMODULEINIT

diff --git a/mercurial/base85.c b/mercurial/base85.c
--- a/mercurial/base85.c
+++ b/mercurial/base85.c
@@ -19,5 +19,5 @@ static const char b85chars[] = "01234567
 static char b85dec[256];
 
-static void b85prep(void)
+static int b85prep(void)
 {
unsigned i;
@@ -26,4 +26,6 @@ static void b85prep(void)
for (i = 0; i < sizeof(b85chars); i++)
b85dec[(int)(b85chars[i])] = i + 1;
+
+   return 0;
 }
 
@@ -158,25 +160,3 @@ static PyMethodDef methods[] = {
 };
 
-#ifdef IS_PY3K
-static struct PyModuleDef base85_module = {
-   PyModuleDef_HEAD_INIT,
-   "base85",
-   base85_doc,
-   -1,
-   methods
-};
-
-PyMODINIT_FUNC PyInit_base85(void)
-{
-   b85prep();
-
-   return PyModule_Create(_module);
-}
-#else
-PyMODINIT_FUNC initbase85(void)
-{
-   Py_InitModule3("base85", methods, base85_doc);
-
-   b85prep();
-}
-#endif
+PYMODULEINIT(base85, methods, base85_doc, 1, b85prep, NULL);
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 5 of 7] mpatch: use PYMODULEINIT

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494290506 25200
#  Mon May 08 17:41:46 2017 -0700
# Node ID 219c4e0d41d807078e3cc9663da11243e81625dd
# Parent  4bd6bf0ecf1ba186851ba6fa3776561b67fe6a7c
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 219c4e0d41d8
mpatch: use PYMODULEINIT

A side effect of the clean up is mercurial.mpatch.mpatchError gets exposed,
which seems to be a good thing.

diff --git a/mercurial/mpatch_module.c b/mercurial/mpatch_module.c
--- a/mercurial/mpatch_module.c
+++ b/mercurial/mpatch_module.c
@@ -161,35 +161,13 @@ static PyMethodDef methods[] = {
 };
 
-#ifdef IS_PY3K
-static struct PyModuleDef mpatch_module = {
-   PyModuleDef_HEAD_INIT,
-   "mpatch",
-   mpatch_doc,
-   -1,
-   methods
-};
-
-PyMODINIT_FUNC PyInit_mpatch(void)
+static int postinit(PyObject *mod)
 {
-   PyObject *m;
-
-   m = PyModule_Create(_module);
-   if (m == NULL)
-   return NULL;
-
mpatch_Error = PyErr_NewException("mercurial.mpatch.mpatchError",
  NULL, NULL);
+   if (!mpatch_Error)
+   return -1;
Py_INCREF(mpatch_Error);
-   PyModule_AddObject(m, "mpatchError", mpatch_Error);
-
-   return m;
+   return PyModule_AddObject(mod, "mpatchError", mpatch_Error);
 }
-#else
-PyMODINIT_FUNC
-initmpatch(void)
-{
-   Py_InitModule3("mpatch", methods, mpatch_doc);
-   mpatch_Error = PyErr_NewException("mercurial.mpatch.mpatchError",
- NULL, NULL);
-}
-#endif
+
+PYMODULEINIT(mpatch, methods, mpatch_doc, 1, NULL, postinit);
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 3 of 7] bdiff: use PYMODULEINIT

2017-05-08 Thread Jun Wu
# HG changeset patch
# User Jun Wu 
# Date 1494290228 25200
#  Mon May 08 17:37:08 2017 -0700
# Node ID 04056409e50d16af48c92d69d81733bd04fed01c
# Parent  1d76f329321de2af7afb59dc06c61bae87078481
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 04056409e50d
bdiff: use PYMODULEINIT

diff --git a/mercurial/bdiff_module.c b/mercurial/bdiff_module.c
--- a/mercurial/bdiff_module.c
+++ b/mercurial/bdiff_module.c
@@ -193,21 +193,3 @@ static PyMethodDef methods[] = {
 };
 
-#ifdef IS_PY3K
-static struct PyModuleDef bdiff_module = {
-   PyModuleDef_HEAD_INIT,
-   "bdiff",
-   mdiff_doc,
-   -1,
-   methods
-};
-
-PyMODINIT_FUNC PyInit_bdiff(void)
-{
-   return PyModule_Create(_module);
-}
-#else
-PyMODINIT_FUNC initbdiff(void)
-{
-   Py_InitModule3("bdiff", methods, mdiff_doc);
-}
-#endif
+PYMODULEINIT(bdiff, methods, mdiff_doc, 1, NULL, NULL);
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] setup: use setuptools on Windows (issue5400)

2017-05-08 Thread Sean Farley
Matt Harbison  writes:

> On Wed, 03 May 2017 20:12:39 -0400, Pierre-Yves David  
>  wrote:
>
>> On 04/09/2017 02:30 AM, Matt Harbison wrote:
>>> On Thu, 09 Mar 2017 23:06:34 -0500, Gregory Szorc
>>>  wrote:
>>>
 # HG changeset patch
 # User Gregory Szorc 
 # Date 1489118392 28800
 #  Thu Mar 09 19:59:52 2017 -0800
 # Node ID b51f9adb41e68d9f3d88582f044d2742ae29ce09
 # Parent  cd29673cebdbe2d998009322e4c3657389d6aed0
 setup: use setuptools on Windows (issue5400)

 We've had a long, complicated history with setuptools. We want to
 make it the universal default. But when we do, it breaks things.

 `python setup.py build` is broken on Windows today. Forcing
 the use of setuptools via FORCE_SETUPTOOLS=1 unbreaks things.

 Since the previous bustage with making setuptools the default
 was on !Windows, it seems safe to move ahead with the setuptools
 transition on Windows. So this patch does that.
>>>
>>> I'm not sure why, or what we should do about it, but test-hghave.t fails
>>> with this on Windows.  I can get a similar failure on Linux with
>>> FORCE_SETUPTOOLS=1.  Is this an expected diff with setuptools (and
>>> deserving a '(glob) (?)'?
>>
>> It seems like your setuptools version/config installs '.egg'. That is  
>> awful since '.egg' is one of the worse things that happened to python  
>> packaging (their implementation is awful, has performance issue and  
>> break multiple basic assumption about python install/import).
>>
>> I though the time were setuptools were intalling '.egg' were over. I  
>> wonder why your version installed '.eggs', is it some global  
>> configuration? Is it an older version? Am I wrong when I think '.egg'  
>> are no longer the default?
>>
>> In all cases, I don't know if Mercurial setup tools can make sure it is  
>> never installed as an 'egg'. Maybe redefining the egg related commands  
>> in setup.py to abort ?
>>
>> Cheers,
>>
>
> I've got python 2.7.13 installed.  `pip install --upgrade setuptools`  
> bumped it from 28.8.0 -> 35.0.2, but no joy.  I deleted the contents of  
> 'mercurial.egg-info'.  `make clean && make local` doesn't repopulate the  
> egg directory, but running the test does, and it fails again.
>
> I can't believe that there's a global config in play on my system because  
> I know nothing about setuptools, and Mercurial is the only python thing I  
> work with.

I usually get this directory when I run in a virtualenv and install the
package via 'pip install -e .'


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


Re: [PATCH 12 of 12 RFC] policy: add helper to import cext/pure module

2017-05-08 Thread Jun Wu
Excerpts from Augie Fackler's message of 2017-05-08 15:22:41 -0400:
> I've taken patches 1-10 since they seem to clean up a lot of things. I
> don't have strong feelings on patch 12, and patch 11 looks fine to me,
> but I didn't take either one.

Patch 11 looks good to me too. It's solving a similar problem with the auto
rebuild patch [1]. If we take patch 11, then the auto rebuild patch becomes
optional, although still nice to have for people wanting to test C code (for
reasons like perf, correctness, etc) explicitly.

Patch 12 is where I disagree. _dualmod still requires careful renaming and
could cause subtle problems that does not get warned by any code checking
tools. They also require extra effort in writing and reviewing related code.
I'd like to go through the explicit versioning way so even the renaming
churn could be avoided.

[1]: 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097329.html
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 6 of 6] bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543)

2017-05-08 Thread Gregory Szorc
On Sat, May 6, 2017 at 1:05 AM, Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1493998275 -7200
> #  Fri May 05 17:31:15 2017 +0200
> # Node ID 3a04e2424b2821fa92d41ac9e40430aa25d4560d
> # Parent  16b60a34def41f52e024d32d6e99e5d533cad02f
> # EXP-Topic bundle2.tagsfnodecache
> # Available At https://www.mercurial-scm.org/
> repo/users/marmoute/mercurial/
> #  hg pull https://www.mercurial-scm.org/
> repo/users/marmoute/mercurial/ -r 3a04e2424b28
> bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543)
>
> This should help performance when unbundling.
>
> diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
> --- a/mercurial/bundle2.py
> +++ b/mercurial/bundle2.py
> @@ -1378,6 +1378,8 @@ def _addpartsfromopts(ui, repo, bundler,
>  part.addparam('nbchanges', str(cg.extras['clcount']),
>mandatory=False)
>
> +addparttagsfnodescache(repo, bundler, outgoing)
> +
>  def addparttagsfnodescache(repo, bundler, outgoing):
>  # we include the tags fnode cache for the bundle changeset
>  # (as an optional parts)
> diff --git a/tests/test-tags.t b/tests/test-tags.t
> --- a/tests/test-tags.t
> +++ b/tests/test-tags.t
> @@ -716,3 +716,15 @@ Running hg tags should produce tags2* fi
>0040: ff ff ff ff ff ff ff ff 40 f0 35 8c 19 e0 a7 d3 |@.5.|
>0050: 8a 5c 6a 82 4d cf fb a5 87 d0 2f a3 1e 4f 2f 8a |.\j.M./..O/.|
>
> +Check that the bundle includes cache data
> +
> +  $ hg -R tagsclient bundle --all ./test-cache-in-bundle-all-rev.hg
> +  4 changesets found
> +  $ hg debugbundle ./test-cache-in-bundle-all-rev.hg
> +  Stream params: sortdict([('Compression', 'BZ')])
> +  changegroup -- "sortdict([('version', '02'), ('nbchanges', '4')])"
> +  96ee1d7354c4ad7372047672c36a1f561e3a6a4c
> +  c4dab0c2fd337eb9191f80c3024830a4889a8f34
> +  f63cc8fe54e4d326f8d692805d70e092f851ddb1
> +  40f0358cb314c824a5929ee527308d90e023bc10
> +  hgtagsfnodes -- 'sortdict()'
>

This test would be more useful if it didn't send empty tags cache data. In
fact, I think you found a bug! Shouldn't we omit the part if it is empty?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2 stable] graft: fix graft across merges of duplicates of grafted changes

2017-05-08 Thread Mads Kiilerich
# HG changeset patch
# User Mads Kiilerich 
# Date 1494283376 -7200
#  Tue May 09 00:42:56 2017 +0200
# Branch stable
# Node ID dd256de590dfd363fa5d497d566d456f471b8d52
# Parent  6710017995b4e8b361d6ad5b897ff7d0cc658285
graft: fix graft across merges of duplicates of grafted changes

Graft used findmissingrevs to find the candidates for graft duplicates in the
destination. That function operates with the constraint:

  2. N is not an ancestor of any node in 'common'

For our purpose, we do however need:

  2. There are nodes in 'common' that doesn't have N as ancestor

The right candiates for graft duplicates could be computed with a revset:

  only(destination,transitiveroots(graftset))

where transitiveroots would be a revset function for 'transitive root' and
return changesets in set with no ancestor changeset in set. There doesn't seem
to be any such function readily available, and we thus use the approximation of
just using the smallest revision in the graft set.

This change will graft more correctly, but it will also in some cases make
graft slower by making it search through a bigger and unnecessary large sets of
changes to find duplicates.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -2295,7 +2295,8 @@ def _dograft(ui, repo, *revs, **opts):
 # check ancestors for earlier grafts
 ui.debug('scanning for duplicate grafts\n')
 
-for rev in repo.changelog.findmissingrevs(revs, [crev]):
+expr = revsetlang.formatspec('only(%d,min(%ld))', crev, revs)
+for rev in scmutil.revrange(repo, [expr]):
 ctx = repo[rev]
 n = ctx.extra().get('source')
 if n in ids:
diff --git a/tests/test-graft.t b/tests/test-graft.t
--- a/tests/test-graft.t
+++ b/tests/test-graft.t
@@ -1341,16 +1341,15 @@ Grafting of plain changes correctly dete
   skipping already grafted revision 5:43e9eb70dab0 (was grafted from 
4:6c9a1289e5f1)
   grafting 2:42127f193bcd "b"
 
-Extending the graft range to include a merge will unfortunately make us miss
-that 3 and 5 should be skipped:
+Extending the graft range to include a (skipped) merge of 3 will not prevent 
us from
+also detecting that both 3 and 5 should be skipped:
 
   $ hg up -qCr 4
   $ hg graft --tool :local -r 2::7
   skipping ungraftable merge revision 6
+  skipping already grafted revision 3:ca093ca2f1d9 (was grafted from 
1:13ec5badbf2a)
   skipping already grafted revision 5:43e9eb70dab0 (was grafted from 
4:6c9a1289e5f1)
   grafting 2:42127f193bcd "b"
-  grafting 3:ca093ca2f1d9 "x"
-  note: graft of 3:ca093ca2f1d9 created no changes to commit
   grafting 7:d3c3f2b38ecc "xx"
   note: graft of 7:d3c3f2b38ecc created no changes to commit
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2 stable] graft: test coverage of grafts and how merges can break duplicate detection

2017-05-08 Thread Mads Kiilerich
# HG changeset patch
# User Mads Kiilerich 
# Date 1494281490 -7200
#  Tue May 09 00:11:30 2017 +0200
# Branch stable
# Node ID 6710017995b4e8b361d6ad5b897ff7d0cc658285
# Parent  247bb7a2c492d8a946cc7ed61a627d53566b7c16
graft: test coverage of grafts and how merges can break duplicate detection

This demonstrates unfortunate behaviour: extending the graft range cause the
graft to behave differently. When the graft range includes a merge, we fail to
detect duplicates that are ancestors of the merge.

diff --git a/tests/test-graft.t b/tests/test-graft.t
--- a/tests/test-graft.t
+++ b/tests/test-graft.t
@@ -1309,4 +1309,49 @@ Graft a change into a new file previousl
   $ hg status --change .
   M b/x
 
+Prepare for test of skipped changesets and how merges can influence it:
+
+  $ hg merge -q -r 1 --tool :local
+  $ hg ci -m m
+  $ echo xx >> b/x
+  $ hg ci -m xx
+
+  $ hg log -G -T '{rev} {desc|firstline}'
+  @  7 xx
+  |
+  o6 m
+  |\
+  | o  5 y
+  | |
+  +---o  4 y
+  | |
+  | o  3 x
+  | |
+  | o  2 b
+  | |
+  o |  1 x
+  |/
+  o  0 a
+  
+Grafting of plain changes correctly detects that 3 and 5 should be skipped:
+
+  $ hg up -qCr 4
+  $ hg graft --tool :local -r 2::5
+  skipping already grafted revision 3:ca093ca2f1d9 (was grafted from 
1:13ec5badbf2a)
+  skipping already grafted revision 5:43e9eb70dab0 (was grafted from 
4:6c9a1289e5f1)
+  grafting 2:42127f193bcd "b"
+
+Extending the graft range to include a merge will unfortunately make us miss
+that 3 and 5 should be skipped:
+
+  $ hg up -qCr 4
+  $ hg graft --tool :local -r 2::7
+  skipping ungraftable merge revision 6
+  skipping already grafted revision 5:43e9eb70dab0 (was grafted from 
4:6c9a1289e5f1)
+  grafting 2:42127f193bcd "b"
+  grafting 3:ca093ca2f1d9 "x"
+  note: graft of 3:ca093ca2f1d9 created no changes to commit
+  grafting 7:d3c3f2b38ecc "xx"
+  note: graft of 7:d3c3f2b38ecc created no changes to commit
+
   $ cd ..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[Bug 5562] New: [Feature request] hg up -

2017-05-08 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=5562

Bug ID: 5562
   Summary: [Feature request] hg up -
   Product: Mercurial
   Version: 4.1
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: roma...@unity3d.com
CC: mercurial-devel@mercurial-scm.org

Hi!

It would be nice if hg could handle the syntax `hg up -` which would go to the
previous updated branch (ala `cd -`)

It's an incredibly useful feature that I use in git all the time.

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


[PATCH 1 of 2] tests: remove test targeting Python 2.6

2017-05-08 Thread Gregory Szorc
# HG changeset patch
# User Gregory Szorc 
# Date 1494282615 25200
#  Mon May 08 15:30:15 2017 -0700
# Node ID 50eabab39ddfb8b5db7acef36827755166a59a9d
# Parent  52ec3072fe46bc4b193b6273357e3cc40b4421ad
tests: remove test targeting Python 2.6

We just removed support for Python 2.7. This test is dead since it only
ran on <2.7.

diff --git a/tests/test-https.t b/tests/test-https.t
--- a/tests/test-https.t
+++ b/tests/test-https.t
@@ -333,20 +333,9 @@ Disabling the TLS 1.0 warning works
   > --config hostsecurity.disabletls10warning=true
   5fed3813f7f5
 
-#if no-sslcontext no-py27+
-Setting ciphers doesn't work in Python 2.6
-  $ P="$CERTSDIR" hg --config hostsecurity.ciphers=HIGH -R copy-pull id 
https://localhost:$HGPORT/
-  warning: connecting to localhost using legacy security technology (TLS 1.0); 
see https://mercurial-scm.org/wiki/SecureConnections for more info
-  abort: setting ciphers in [hostsecurity] is not supported by this version of 
Python
-  (remove the config option or run Mercurial with a modern Python version 
(preferred))
-  [255]
-#endif
+Error message for setting ciphers is different depending on SSLContext support
 
-Setting ciphers works in Python 2.7+ but the error message is different on
-legacy ssl. We test legacy once and do more feature checking on modern
-configs.
-
-#if py27+ no-sslcontext
+#if no-sslcontext
   $ P="$CERTSDIR" hg --config hostsecurity.ciphers=invalid -R copy-pull id 
https://localhost:$HGPORT/
   warning: connecting to localhost using legacy security technology (TLS 1.0); 
see https://mercurial-scm.org/wiki/SecureConnections for more info
   abort: *No cipher can be selected. (glob)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2] hghave: remove py27+ capability

2017-05-08 Thread Gregory Szorc
# HG changeset patch
# User Gregory Szorc 
# Date 1494282694 25200
#  Mon May 08 15:31:34 2017 -0700
# Node ID 48936726f8731b840cb7bd08fcf5ec5af0b4cc7a
# Parent  50eabab39ddfb8b5db7acef36827755166a59a9d
hghave: remove py27+ capability

It is now unused. And we require Python 2.7+ now so this check is not
necessary.

diff --git a/tests/hghave.py b/tests/hghave.py
--- a/tests/hghave.py
+++ b/tests/hghave.py
@@ -580,10 +580,6 @@ def has_absimport():
 from mercurial import util
 return util.safehasattr(__future__, "absolute_import")
 
-@check("py27+", "running with Python 2.7+")
-def has_python27ornewer():
-return sys.version_info[0:2] >= (2, 7)
-
 @check("py3k", "running with Python 3.x")
 def has_py3k():
 return 3 == sys.version_info[0]
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH V2] setup: drop support for Python 2.6 (BC)

2017-05-08 Thread Kevin Bullock
> On May 3, 2017, at 12:57, Gregory Szorc  wrote:
> 
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1493767144 25200
> #  Tue May 02 16:19:04 2017 -0700
> # Node ID 6a14047b05f5a9f1c3bf848f3a0b758015c4f8cd
> # Parent  efcaf6ab86f40b8cc6fbb0e28764d9c1e88dfb27
> setup: drop support for Python 2.6 (BC)

Adjusted the buildbot config and queued this, thanks.

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

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


Re: [PATCH 1 of 3] bundle: allow creation of changegroup3 bundles

2017-05-08 Thread Gregory Szorc


> On May 6, 2017, at 02:50, Pierre-Yves David  
> wrote:
> 
> 
> 
>> On 05/05/2017 12:14 AM, Gregory Szorc wrote:
>> On Thu, May 4, 2017 at 12:14 PM, Pierre-Yves David
>> >
>> wrote:
>> 
>> 
>> 
>>On 05/04/2017 07:04 PM, Martin von Zweigbergk via Mercurial-devel wrote:
>> 
>># HG changeset patch
>># User Martin von Zweigbergk >>
>># Date 1458952398 25200
>>#  Fri Mar 25 17:33:18 2016 -0700
>># Node ID f4b255ff67d05e329cc3d80ce1552f30005f58e9
>># Parent  06058cbb9209df54bfa0aaf9f7d10b836a1e3ee9
>>bundle: allow creation of changegroup3 bundles
>> 
>>With this change, one can use "hg bundle -t v3" to creat
>>changegroup3
>>bundles, which support treemanifests and revlog flags. In
>>treemanifest
>>repos, v3 is the default bundle format.
>> 
>> 
>>The bundle spec "version" cover a collection of setting for the
>>underlying content. It is not directly correlated to the changegroup
>>version.
>> 
>>Tree manifest is still experimental so it seems a bit early to burn
>>a new bundle spec version on this especially since we have other
>>bundle improvement coming (phase, tag cache, obsmarkers, etc).
>> 
>>So I don't think we should introduce a new bundlespec version yet.
>>Instead I would recommend the following:
>> 
>>1) introduce a parameter to control de cg-version (cgversion=03?)
>>2) automatically bump the cg version to '03' if no spec is passed
>>and tree manifest is used,
>>3) late in the 4.3 cycles consider introducing a v3 with all the new
>>improvements (if some make sense at the user-visible feature level).
>> 
>> 
>> There was confusion about this in IRC.
>> 
>> I agree with what Pierre-Yves said: while this will require a "v3" to
>> support cg3, it is still a bit too early in cg3's support cycle to
>> introduce a stable, user-facing bundle spec version. Until we have a
>> better API for controlling bundle generation via bundle specs, I think
>> this should be hacked in via an experimental config option while
>> recycling "v2." Alternatively, we can name the version "expcg3" or
>> something less stable and rename it (presumably to "v3") once the
>> feature is stable. The latter will make it much easier to test the
>> feature and won't result in accidentally producing "v2" bundles that
>> legacy clients choke on.
>> 
>> The concern with the "vN" versions is that every Mercurial client with
>> knowledge of that version string has to be capable of handling any
>> future bundle generated with that same "vN" version (or have code for
>> filtering from other data in the clone bundles manifest, preferably from
>> BUNDLESPEC). This means every time there is a new required bundle part,
>> we have to invent a new "vN" or find some other way to alter
>> clonebundles entries so old clients know they can't consume them.
> 
> TL;DR; We needs the flexibility of params based spec. We should start there 
> and care about the "vN" version later in the cycle.
> 
> About bundle parameters
> ---
> 
> (putting compatibility question aside for now)
> 
> There are two dimensions in play here:
> 
> 1) data format (how we encode the information),
> 2) data content (what data do we encore in the bundle).
> 
> Formats makes it "easy" to think in terms of linear increasing version 
> number, but it is less clear for content. The mix of both makes it more 
> complex.
> 
> The above make me think we should aim for a parameter centric solution here.
> 
> There are multiple kinds of data one -may- want includes into a bundles.
> 
> * changesets,
> * phases,
> * bookmarks,
> * obsolescence,
> * (and various caches)
> 
> I do not think there will be any definitive answer here. For example people 
> might want to generate a bundle with or without bookmarks. So we needs a 
> reasonable "interface" for users to select the bundle content. bundlespec 
> parameters seems like the way to go. (eg: 
> "v3;phases=1;bookmarks=0;obsolescence=0")
> 
> In addition to that, there are the question of -how- these data are encoded 
> (eg: changegroup version). Since there are multiple types of data, it seems 
> useful to be able to control version used for each part (eg: 
> v3;cg.version=04;obsolescence.version=05).
> 
> 
> Of course, we should have a reasonable interface for our simple user.
> So, the way I see the bundlespec's "vN" is more collection of default for the 
> various value described above. picking a "v3" will select value for the known 
> parameters, but parameters will override them. For example:
> 
> * v2 → cg.version=02;phases=no;bookmarks=no;obsolescence=no
> * v3 → cg.version=03;phases=yes;bookmarks=no;obs…=yes;obs….version=02
> 
> And the following would be valid
> 
> * v3;bookmark=yes
> * 

Re: [PATCH] fsmonitor: do not nuke dirstate filecache

2017-05-08 Thread Augie Fackler
On Sat, May 06, 2017 at 04:36:47PM -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1494113784 25200
> #  Sat May 06 16:36:24 2017 -0700
> # Node ID 7e038d1911a6472647d27d73f9de30923f51c3d3
> # Parent  31f42e683321f225eb9c306f8d4b3a9e8d82a1da
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 7e038d1911a6
> fsmonitor: do not nuke dirstate filecache

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


Re: [PATCH 3 of 3] revlog: rename _chunkraw to _getsegmentforrevs()

2017-05-08 Thread Augie Fackler
On Sat, May 06, 2017 at 12:19:46PM -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1494097973 25200
> #  Sat May 06 12:12:53 2017 -0700
> # Node ID 13ac158a12d3b1256a6910affdf3aa63eb660ac1
> # Parent  71ecddb2aa427e9d3c2372f5a616ff6cf99cb03f
> revlog: rename _chunkraw to _getsegmentforrevs()

queued, thanks

I particularly like how some of the *chunk* methods already had
"segment" in their docstring.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 5 of 5] perf: move revlog construction and length calculation out of benchmark

2017-05-08 Thread Augie Fackler
On Sat, May 06, 2017 at 11:22:01AM -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1494094619 25200
> #  Sat May 06 11:16:59 2017 -0700
> # Node ID 975e9dc35eccecb002843848d91964bca327e33a
> # Parent  cff951b580bade53bb5a520b690feb5ca73361d7
> perf: move revlog construction and length calculation out of benchmark

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


Re: [PATCH 6 of 6] bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543)

2017-05-08 Thread Augie Fackler
On Sat, May 06, 2017 at 10:05:00AM +0200, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1493998275 -7200
> #  Fri May 05 17:31:15 2017 +0200
> # Node ID 3a04e2424b2821fa92d41ac9e40430aa25d4560d
> # Parent  16b60a34def41f52e024d32d6e99e5d533cad02f
> # EXP-Topic bundle2.tagsfnodecache
> # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
> #  hg pull 
> https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 3a04e2424b28
> bundle: add optional 'tagsfnodecache' data to on disk bundle (issue5543)

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


Re: [PATCH 12 of 12 RFC] policy: add helper to import cext/pure module

2017-05-08 Thread Augie Fackler
On Sun, May 07, 2017 at 10:45:53AM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1470969017 -32400
> #  Fri Aug 12 11:30:17 2016 +0900
> # Node ID 7d94765310f0b8fb04765ce0bc958edfc3f12960
> # Parent  89045bec86dcb51ac0641e06abd59e82d3c22172
> policy: add helper to import cext/pure module

I've taken patches 1-10 since they seem to clean up a lot of things. I
don't have strong feelings on patch 12, and patch 11 looks fine to me,
but I didn't take either one.

Many thanks!

>
> These functions are sysstr API since __import__() and getattr() hate byte
> strings on Python 3.
>
> There's a minor BC, which is ImportError will be raised if invalid
> HGMODULEPOLICY is specified. I think this is more desirable behavior.
>
> THIS PATCH IS RFC because the current implementation uses a proxy module
> to dispatch attribute accesses to cext or pure. This appears the most
> controversial part in this series. We could instead add version checks
> if we plan to switch to per-module versioning (proposed by Jun Wu):
>
>   def _importversioned(pkgname, modname, locals):
>   mod = _importfrom(pkgname, modname, locals)
>   ver = getattr(mod, r'version', 0)  # TODO: select name of constant
>   if ver != 0:
>   raise ImportError(r'module version mismatch')
>   return mod
>
> Where a mod is loaded before assigned to locals, so we should disable
> demandimport in policy.importmod(). This means we won't need locals dict.
>
> diff --git a/mercurial/policy.py b/mercurial/policy.py
> --- a/mercurial/policy.py
> +++ b/mercurial/policy.py
> @@ -24,6 +24,13 @@ import sys
>  policy = b'allow'
>  policynoc = (b'cffi', b'cffi-allow', b'py')
>  policynocffi = (b'c', b'py')
> +_packageprefs = {
> +b'c': [r'cext'],
> +b'allow': [r'cext', r'pure'],
> +b'cffi': [r'pure'],  # TODO: [r'cffi']
> +b'cffi-allow': [r'pure'],  # TODO: [r'cffi', r'pure']
> +b'py': [r'pure'],
> +}
>
>  try:
>  from . import __modulepolicy__
> @@ -49,3 +56,53 @@ if sys.version_info[0] >= 3:
>  policy = os.environ[r'HGMODULEPOLICY'].encode(r'utf-8')
>  else:
>  policy = os.environ.get(r'HGMODULEPOLICY', policy)
> +
> +class _dualmod(object):
> +"""Proxy loading named attribute from mod1 or mod2
> +
> +mod2 is kept unloaded as long as the given name can be found in mod1.
> +"""
> +
> +def __init__(self, mod1, mod2):
> +self._mod1 = mod1
> +self._mod2 = mod2
> +
> +def __getattr__(self, name):
> +try:
> +obj = getattr(self._mod1, name)  # may be unloaded module
> +except (AttributeError, ImportError):
> +obj = getattr(self._mod2, name)
> +self.__dict__[name] = obj
> +return obj
> +
> +@property
> +def __doc__(self):
> +return self.__getattr__(r'__doc__')
> +
> +def __repr__(self):
> +return r'' % (self._mod1, self._mod2)
> +
> +def _importfrom(pkgname, modname, locals):
> +# pass globals() to resolve name relative to this module
> +pkg = __import__(pkgname, globals(), locals, [modname], level=1)
> +return getattr(pkg, modname)
> +
> +def importmod(modname, locals):
> +"""Import module according to policy
> +
> +locals dict must be specified so demandimport can update the module
> +reference in place.
> +"""
> +try:
> +prefs = _packageprefs[policy]
> +except KeyError:
> +raise ImportError(r'invalid HGMODULEPOLICY %r' % policy)
> +
> +if len(prefs) == 1:
> +return _importfrom(prefs[0], modname, locals)
> +try:
> +mods = [_importfrom(p, modname, locals) for p in prefs]
> +return _dualmod(*mods)
> +except ImportError:
> +# fallback module must exist
> +return _importfrom(prefs[-1], modname, locals)
> ___
> 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 5 of 5] extdiff: copy back files to the working directory if the size changed

2017-05-08 Thread Augie Fackler
On Sun, May 07, 2017 at 01:07:14AM -0400, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison 
> # Date 1494126057 14400
> #  Sat May 06 23:00:57 2017 -0400
> # Node ID e51c0ad57dcfeac4942816c5b669644638d5367c
> # Parent  edc212b7be4c621f39412055affab33f45973e9e
> extdiff: copy back files to the working directory if the size changed

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


Re: [PATCH 2 of 2] strip: make tree stripping O(changes) instead of O(repo)

2017-05-08 Thread Augie Fackler
On Mon, May 08, 2017 at 11:40:03AM -0700, Durham Goode wrote:
> # HG changeset patch
> # User Durham Goode 
> # Date 1494268523 25200
> #  Mon May 08 11:35:23 2017 -0700
> # Node ID 74881b9a39b2bab273d09009385e3c9ca717a13a
> # Parent  5dec5907fe49a488d3ade272d4a5cf090914e59c
> strip: make tree stripping O(changes) instead of O(repo)

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


Re: [PATCH] manifest: remove unused property _oldmanifest

2017-05-08 Thread Augie Fackler
On Mon, May 08, 2017 at 11:22:58AM -0700, Martin von Zweigbergk via 
Mercurial-devel wrote:
> # HG changeset patch
> # User Martin von Zweigbergk 
> # Date 1494261561 25200
> #  Mon May 08 09:39:21 2017 -0700
> # Node ID f7920a409fb0516b7dc48404537b1fd24cf8e23e
> # Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
> manifest: remove unused property _oldmanifest

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


[PATCH] manifest: remove unused property _oldmanifest

2017-05-08 Thread Martin von Zweigbergk via Mercurial-devel
# HG changeset patch
# User Martin von Zweigbergk 
# Date 1494261561 25200
#  Mon May 08 09:39:21 2017 -0700
# Node ID f7920a409fb0516b7dc48404537b1fd24cf8e23e
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
manifest: remove unused property _oldmanifest

The last use seems to have gone away in 7c7d845f8b64 (manifest: make
manifestlog use it's own cache, 2016-11-10).

diff --git a/mercurial/manifest.py b/mercurial/manifest.py
--- a/mercurial/manifest.py
+++ b/mercurial/manifest.py
@@ -1317,8 +1317,7 @@
 cachesize = opts.get('manifestcachesize', cachesize)
 self._treeinmem = usetreemanifest
 
-self._oldmanifest = repo._constructmanifest()
-self._revlog = self._oldmanifest
+self._revlog = repo._constructmanifest()
 
 # A cache of the manifestctx or treemanifestctx for each directory
 self._dirmancache = {}
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2] strip: make tree stripping O(changes) instead of O(repo)

2017-05-08 Thread Durham Goode
# HG changeset patch
# User Durham Goode 
# Date 1494268523 25200
#  Mon May 08 11:35:23 2017 -0700
# Node ID 74881b9a39b2bab273d09009385e3c9ca717a13a
# Parent  5dec5907fe49a488d3ade272d4a5cf090914e59c
strip: make tree stripping O(changes) instead of O(repo)

The old tree stripping logic iterated over every tree revlog in the repo looking
for commits that had revs to be stripped. That's very inefficient in large
repos. Instead, let's look at what files are touched by the strip and only
inspect those revlogs.

I don't have actual perf numbers, since internally we don't use a true
treemanifest, but simply iterating over hundreds of thousands of revlogs takes
many, many seconds, so this should help tremendously when stripping only a few
commits.

diff --git a/mercurial/repair.py b/mercurial/repair.py
--- a/mercurial/repair.py
+++ b/mercurial/repair.py
@@ -238,11 +238,12 @@ def strip(ui, repo, nodelist, backup=Tru
 def striptrees(repo, tr, striprev, files):
 if 'treemanifest' in repo.requirements: # safe but unnecessary
 # otherwise
-for unencoded, encoded, size in repo.store.datafiles():
-if (unencoded.startswith('meta/') and
-unencoded.endswith('00manifest.i')):
-dir = unencoded[5:-12]
-repo.manifestlog._revlog.dirlog(dir).strip(striprev, tr)
+treerevlog = repo.manifestlog._revlog
+for dir in util.dirs(files):
+# If the revlog doesn't exist, this returns an empty revlog and is 
a
+# no-op.
+rl = treerevlog.dirlog(dir)
+rl.strip(striprev, tr)
 
 def rebuildfncache(ui, repo):
 """Rebuilds the fncache file from repo history.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2] strip: move tree strip logic to it's own function

2017-05-08 Thread Durham Goode
# HG changeset patch
# User Durham Goode 
# Date 1494268523 25200
#  Mon May 08 11:35:23 2017 -0700
# Node ID 5dec5907fe49a488d3ade272d4a5cf090914e59c
# Parent  8f1a2b848b52ea7bf3fe2404e3b62924c7aae93f
strip: move tree strip logic to it's own function

This will allow external extensions to modify tree strip behavior more
precisely.

diff --git a/mercurial/repair.py b/mercurial/repair.py
--- a/mercurial/repair.py
+++ b/mercurial/repair.py
@@ -165,13 +165,8 @@ def strip(ui, repo, nodelist, backup=Tru
 tr.startgroup()
 cl.strip(striprev, tr)
 mfst.strip(striprev, tr)
-if 'treemanifest' in repo.requirements: # safe but unnecessary
-# otherwise
-for unencoded, encoded, size in repo.store.datafiles():
-if (unencoded.startswith('meta/') and
-unencoded.endswith('00manifest.i')):
-dir = unencoded[5:-12]
-repo.manifestlog._revlog.dirlog(dir).strip(striprev, 
tr)
+striptrees(repo, tr, striprev, files)
+
 for fn in files:
 repo.file(fn).strip(striprev, tr)
 tr.endgroup()
@@ -240,6 +235,15 @@ def strip(ui, repo, nodelist, backup=Tru
 # extensions can use it
 return backupfile
 
+def striptrees(repo, tr, striprev, files):
+if 'treemanifest' in repo.requirements: # safe but unnecessary
+# otherwise
+for unencoded, encoded, size in repo.store.datafiles():
+if (unencoded.startswith('meta/') and
+unencoded.endswith('00manifest.i')):
+dir = unencoded[5:-12]
+repo.manifestlog._revlog.dirlog(dir).strip(striprev, tr)
+
 def rebuildfncache(ui, repo):
 """Rebuilds the fncache file from repo history.
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] sslutil: reference fingerprints config option properly (issue5559)

2017-05-08 Thread Augie Fackler
On Mon, May 08, 2017 at 09:31:22AM -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1494261026 25200
> #  Mon May 08 09:30:26 2017 -0700
> # Branch stable
> # Node ID b0371710232710900977ff5fef1ee44a8dae90f0
> # Parent  1b27e1793156fc56850010342dbf07a99fba0307
> sslutil: reference fingerprints config option properly (issue5559)

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


Re: [PATCH 5 of 7] changegroup: deprecate 'getlocalchangroup' (API)

2017-05-08 Thread Pierre-Yves David



On 05/08/2017 06:15 PM, Martin von Zweigbergk wrote:

On Mon, May 8, 2017 at 9:10 AM, Durham Goode  wrote:



On 5/6/17 6:55 AM, Martin von Zweigbergk wrote:




On May 5, 2017 23:57, "Pierre-Yves David"
>
wrote:



On 05/05/2017 09:16 PM, Martin von Zweigbergk wrote:

On Fri, May 5, 2017 at 11:44 AM, Pierre-Yves David
> wrote:



On 05/05/2017 08:38 PM, Martin von Zweigbergk wrote:


On Fri, May 5, 2017 at 11:35 AM, Pierre-Yves David
> wrote:




On 05/05/2017 06:41 PM, Martin von Zweigbergk wrote:



On Thu, May 4, 2017 at 11:26 PM, Pierre-Yves David
> wrote:



# HG changeset patch
# User Pierre-Yves David
>
# Date 1493894621 -7200
#  Thu May 04 12:43:41 2017 +0200
# Node ID
2f51cfeac5bcf8ee266a6fada56517d5d44d9b6b
# Parent
1e8427b7d0b9ce66c5ba34c2cdb64821ff909267
# EXP-Topic changegroup.cleanup
# Available At

https://www.mercurial-scm.org/repo/users/marmoute/mercurial/


#  hg pull

https://www.mercurial-scm.org/repo/users/marmoute/mercurial/


-r
2f51cfeac5bc
changegroup: deprecate 'getlocalchangroup'
(API)

We have 'getchangegroup' with a shorter name
for the exactly same
feature. Now
that all users are gone we can formally
deprecate it.




We usually just delete methods that we no longer
use internally. Why
not do that here?




When function are likely to be used by extension we
try to avoid dropping
them and we deprecated them for a version. This
helps third party
extensions
to smoothly detect the API changes (usually through
test run) and
smoothly
upgrade their code over the version cycle.



In this case I suspect it won't help many of them
because I probably
broke most or all anyway with
https://www.mercurial-scm.org/repo/hg/rev/282b288aa20c

.

I thought we
were okay with that kind of changes. Are you saying I
should have
instead added duplicate methods with the new signatures
and only
deprecated the existing methods?



Generating changegroup is a quite core feature in Mercurial.
I suspect their
are extension out there using these and I tried to be
careful. That is a gut
feeling. I'm did not looked at actual data. (that gut
feeling proved right
for "vfs", but might be wrong here)

(so, yes I would have been more careful with your API change
too)


Well, given that my patch probably broke most of those extensions,
I
don't see much reason for your series to be more careful. But
there's
little harm in doing it, so I'll queue it once tests have run etc.


I agree doing both approach at the same time is sub-optimal :-)
We should either restore some of the (deprecated) 

Re: [PATCH 5 of 7] changegroup: deprecate 'getlocalchangroup' (API)

2017-05-08 Thread Pierre-Yves David

On 05/06/2017 03:55 PM, Martin von Zweigbergk wrote:


On May 5, 2017 23:57, "Pierre-Yves David"
>
wrote:
 […]

I've digged up a bit and  already found a couple of Facebook
extensions using getlocalchangegroup so I think it is safer to
assume there are external users.


I don't care much. Durham, do you guys care enough so we should back out
the change. I don't care enough to clean up that I'm going to bother
with deprecation.


The point is not so much about how Facebook will adapt to the API 
change. They have a good continuous test coverage and many dev about to 
do the adjustment. My point is more than if we can find usage of that 
API in Facebook extension, it is a good hint that other extensions might 
do the same too.


It is not too important, I'll do a cleanup path on this in the next 
couple of weeks and align things one way or another (dropping the old 
one or adding some deprecwarn).


On 05/06/2017 08:20 PM, Gregory Szorc wrote:
> The changegroup APIs are horrible and are low-level. I favor deleting
> legacy ones that are no longer used in core. Extensions can test for
> function presence at run-time.

Yep! We are dropping that function and cleaning the API in all cases. We 
are just discussing keeping it around for a couple of month to help with 
third party extension.


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


[Bug 5561] New: at least grep and churn need to have linkrevs adjusted in evolve repos

2017-05-08 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=5561

Bug ID: 5561
   Summary: at least grep and churn need to have linkrevs adjusted
in evolve repos
   Product: Mercurial
   Version: 4.2
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: martinv...@google.com
CC: mercurial-devel@mercurial-scm.org

cmdutil.walkfilerevs() simply calls filelog.linkrev(j), which does not do
linkrev adjustment to correct for hidden revisions. The result is that at least
grep and churn produce bad results if a linkrev points to a hidden commit.


For example:


Correct result (in a fresh clone):
$ hg churn -r ::4.2 mercurial/manifest.py | head -5
dur...@fb.com1315
**
martinv...@google.com1041
***
m...@selenic.com   477 ***
au...@google.com  428 
r...@durin42.com   311 **


Bad result in my repo:

$ hg churn -r ::4.2 mercurial/manifest.py | head -5
m...@selenic.com   477
**
martinv...@google.com 434
***
au...@google.com  372
**
dur...@fb.com 355
***
r...@durin42.com   311


-- 
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: [PATCH 2 of 2] setup: prevent setuptools from laying an egg

2017-05-08 Thread Gregory Szorc
On Sun, May 7, 2017 at 9:39 PM, Matt Harbison  wrote:

> # HG changeset patch
> # User Matt Harbison 
> # Date 1494214143 14400
> #  Sun May 07 23:29:03 2017 -0400
> # Node ID 707683d56e5cbd3fe3453ddab9a57222b998f2af
> # Parent  36d9a659b9d76837faaf73fde3f5c5455231c2f9
> setup: prevent setuptools from laying an egg
>

This patch seems reasonable. I'm, uh, actually quite surprised setuptools
doesn't have an easier way to disable egg generation considering eggs have
fallen out of favor for Python packaging. Who knows.


>
> Previously, test-hghave.t was failing on Windows (and on Linux if
> $FORCE_SETUPTOOLS was set) with the following:
>
>   --- c:/Users/Matt/Projects/hg/tests/test-hghave.t
>   +++ c:/Users/Matt/Projects/hg/tests/test-hghave.t.err
>   @@ -19,7 +19,11 @@
>  >   foo
>  > EOF
>  $ run-tests.py $HGTEST_RUN_TESTS_PURE test-hghaveaddon.t
>   +  warning: Testing with unexpected mercurial lib:
> c:\Users\Matt\Projects\hg\mercurial
>   +   (expected ...\hgtests.mu9rou\install\lib\python\mercurial)
>  .
>   +  warning: Tested with unexpected mercurial lib:
> c:\Users\Matt\Projects\hg\mercurial
>   +   (expected ...\hgtests.mu9rou\install\lib\python\mercurial)
>
> Also, `make install` was creating an *.egg-info in the local Mercurial
> source
> tree, which `make clean` wasn't deleting.
>
> Someone familiar with setuptools should take a close look at this.  I
> originally
> registered a subclass of 'install_egg_info' with an empty run(), which
> took care
> of the egg-info generated by `make install`.  Looking at the output of
> setup.py
> as run by run-tests._installhg(), I saw that 'bdist_egg' was being run.  I
> registered a similar empty class for that command, but the egg was still
> produced.  But when I registered this 'install' subclass with nothing but a
> run() that called the super class run, 'bdist_egg' was no longer being
> called,
> and the test worked.  Subsequently dropping everything except the 'install'
> subclass with a minimal delegating run() allowed the test to run (though
> the
> setup log had output from running 'install_egg_info').
>
> To be on the safe side (and to avoid output about eggs when the empty
> subclasses
> would have prevented any egg processing), I added a filter to
> get_sub_commands()
> to filter out the egg related stuff.  Unlike the others, 'bdist_egg' is
> part of
> setuptools, so registering a subclass and still working without setuptools
> probably isn't very clean.
>
> diff --git a/setup.py b/setup.py
> --- a/setup.py
> +++ b/setup.py
> @@ -77,6 +77,7 @@
>  from distutils.command.build_ext import build_ext
>  from distutils.command.build_py import build_py
>  from distutils.command.build_scripts import build_scripts
> +from distutils.command.install import install
>  from distutils.command.install_lib import install_lib
>  from distutils.command.install_scripts import install_scripts
>  from distutils.spawn import spawn, find_executable
> @@ -461,6 +462,12 @@
>  dir = os.path.dirname(self.get_ext_fullpath('dummy'))
>  return os.path.join(self.build_temp, dir, 'hg.exe')
>
> +class hginstall(install):
> +def get_sub_commands(self):
> +# Screen out egg related commands to prevent egg generation
> +excl = set(['install_egg_info', 'bdist_egg'])
> +return filter(lambda x: x not in excl,
> install.get_sub_commands(self))
> +
>  class hginstalllib(install_lib):
>  '''
>  This is a specialization of install_lib that replaces the copy_file
> used
> @@ -572,6 +579,7 @@
>  'build_py': hgbuildpy,
>  'build_scripts': hgbuildscripts,
>  'build_hgextindex': buildhgextindex,
> +'install': hginstall,
>  'install_lib': hginstalllib,
>  'install_scripts': hginstallscripts,
>  'build_hgexe': buildhgexe,
> ___
> 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] sslutil: reference fingerprints config option properly (issue5559)

2017-05-08 Thread Gregory Szorc
Forgot to add STABLE to the email subject.

On Mon, May 8, 2017 at 9:31 AM, Gregory Szorc 
wrote:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1494261026 25200
> #  Mon May 08 09:30:26 2017 -0700
> # Branch stable
> # Node ID b0371710232710900977ff5fef1ee44a8dae90f0
> # Parent  1b27e1793156fc56850010342dbf07a99fba0307
> sslutil: reference fingerprints config option properly (issue5559)
>
> The config option is "host:fingerprints" not "host.fingerprints".
>
> This warning message is bad and misleads users.
>
> diff --git a/mercurial/sslutil.py b/mercurial/sslutil.py
> --- a/mercurial/sslutil.py
> +++ b/mercurial/sslutil.py
> @@ -825,7 +825,7 @@ def validatesocket(sock):
>'remove the old one from [hostfingerprints]
> '
>'to upgrade to a more secure SHA-256 '
>'fingerprint: '
> -  '%s.fingerprints=%s)\n') % (
> +  '%s:fingerprints=%s)\n') % (
>host, host, nicefingerprint))
>  return
>
> diff --git a/tests/test-https.t b/tests/test-https.t
> --- a/tests/test-https.t
> +++ b/tests/test-https.t
> @@ -383,7 +383,7 @@ Fingerprints
>  - works without cacerts (hostfingerprints)
>$ hg -R copy-pull id https://localhost:$HGPORT/ --insecure --config
> hostfingerprints.localhost=ec:d8:7c:d6:b3:86:d0:4f:c1:b8:b4:
> 1c:9d:8f:5e:16:8e:ef:1c:03
>warning: connecting to localhost using legacy security technology (TLS
> 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info
> (?)
> -  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and remove the old one from [hostfingerprints] to upgrade to
> a more secure SHA-256 fingerprint: localhost.fingerprints=sha256:
> 20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:
> 9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
> +  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and remove the old one from [hostfingerprints] to upgrade to
> a more secure SHA-256 fingerprint: localhost:fingerprints=sha256:
> 20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:
> 9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
>5fed3813f7f5
>
>  - works without cacerts (hostsecurity)
> @@ -398,7 +398,7 @@ Fingerprints
>  - multiple fingerprints specified and first matches
>$ hg --config 'hostfingerprints.localhost=
> ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03, 
> deadbeefdeadbeefdeadbeefdeadbeefdeadbeef'
> -R copy-pull id https://localhost:$HGPORT/ --insecure
>warning: connecting to localhost using legacy security technology (TLS
> 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info
> (?)
> -  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and remove the old one from [hostfingerprints] to upgrade to
> a more secure SHA-256 fingerprint: localhost.fingerprints=sha256:
> 20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:
> 9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
> +  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and remove the old one from [hostfingerprints] to upgrade to
> a more secure SHA-256 fingerprint: localhost:fingerprints=sha256:
> 20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:
> 9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
>5fed3813f7f5
>
>$ hg --config 'hostsecurity.localhost:fingerprints=sha1:
> ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03, sha1:
> deadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id
> https://localhost:$HGPORT/
> @@ -408,7 +408,7 @@ Fingerprints
>  - multiple fingerprints specified and last matches
>$ hg --config 'hostfingerprints.localhost=
> deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 
> ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03'
> -R copy-pull id https://localhost:$HGPORT/ --insecure
>warning: connecting to localhost using legacy security technology (TLS
> 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info
> (?)
> -  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and remove the old one from [hostfingerprints] to upgrade to
> a more secure SHA-256 fingerprint: localhost.fingerprints=sha256:
> 20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:
> 9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
> +  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints]
> section; if you trust this fingerprint, set the following config value in
> [hostsecurity] and 

[PATCH] sslutil: reference fingerprints config option properly (issue5559)

2017-05-08 Thread Gregory Szorc
# HG changeset patch
# User Gregory Szorc 
# Date 1494261026 25200
#  Mon May 08 09:30:26 2017 -0700
# Branch stable
# Node ID b0371710232710900977ff5fef1ee44a8dae90f0
# Parent  1b27e1793156fc56850010342dbf07a99fba0307
sslutil: reference fingerprints config option properly (issue5559)

The config option is "host:fingerprints" not "host.fingerprints".

This warning message is bad and misleads users.

diff --git a/mercurial/sslutil.py b/mercurial/sslutil.py
--- a/mercurial/sslutil.py
+++ b/mercurial/sslutil.py
@@ -825,7 +825,7 @@ def validatesocket(sock):
   'remove the old one from [hostfingerprints] '
   'to upgrade to a more secure SHA-256 '
   'fingerprint: '
-  '%s.fingerprints=%s)\n') % (
+  '%s:fingerprints=%s)\n') % (
   host, host, nicefingerprint))
 return
 
diff --git a/tests/test-https.t b/tests/test-https.t
--- a/tests/test-https.t
+++ b/tests/test-https.t
@@ -383,7 +383,7 @@ Fingerprints
 - works without cacerts (hostfingerprints)
   $ hg -R copy-pull id https://localhost:$HGPORT/ --insecure --config 
hostfingerprints.localhost=ec:d8:7c:d6:b3:86:d0:4f:c1:b8:b4:1c:9d:8f:5e:16:8e:ef:1c:03
   warning: connecting to localhost using legacy security technology (TLS 1.0); 
see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
-  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost.fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
+  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
   5fed3813f7f5
 
 - works without cacerts (hostsecurity)
@@ -398,7 +398,7 @@ Fingerprints
 - multiple fingerprints specified and first matches
   $ hg --config 
'hostfingerprints.localhost=ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03, 
deadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id 
https://localhost:$HGPORT/ --insecure
   warning: connecting to localhost using legacy security technology (TLS 1.0); 
see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
-  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost.fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
+  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
   5fed3813f7f5
 
   $ hg --config 
'hostsecurity.localhost:fingerprints=sha1:ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03,
 sha1:deadbeefdeadbeefdeadbeefdeadbeefdeadbeef' -R copy-pull id 
https://localhost:$HGPORT/
@@ -408,7 +408,7 @@ Fingerprints
 - multiple fingerprints specified and last matches
   $ hg --config 
'hostfingerprints.localhost=deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 
ecd87cd6b386d04fc1b8b41c9d8f5e168eef1c03' -R copy-pull id 
https://localhost:$HGPORT/ --insecure
   warning: connecting to localhost using legacy security technology (TLS 1.0); 
see https://mercurial-scm.org/wiki/SecureConnections for more info (?)
-  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost.fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
+  (SHA-1 fingerprint for localhost found in legacy [hostfingerprints] section; 
if you trust this fingerprint, set the following config value in [hostsecurity] 
and remove the old one from [hostfingerprints] to upgrade to a more secure 
SHA-256 fingerprint: 
localhost:fingerprints=sha256:20:de:b3:ad:b4:cd:a5:42:f0:74:41:1c:a2:70:1e:da:6e:c0:5c:16:9e:e7:22:0f:f1:b7:e5:6e:e4:92:af:7e)
   5fed3813f7f5
 
   $ hg --config 

Re: [PATCH 5 of 7] changegroup: deprecate 'getlocalchangroup' (API)

2017-05-08 Thread Durham Goode



On 5/6/17 6:55 AM, Martin von Zweigbergk wrote:



On May 5, 2017 23:57, "Pierre-Yves David"
>
wrote:



On 05/05/2017 09:16 PM, Martin von Zweigbergk wrote:

On Fri, May 5, 2017 at 11:44 AM, Pierre-Yves David
> wrote:



On 05/05/2017 08:38 PM, Martin von Zweigbergk wrote:


On Fri, May 5, 2017 at 11:35 AM, Pierre-Yves David
> wrote:




On 05/05/2017 06:41 PM, Martin von Zweigbergk wrote:



On Thu, May 4, 2017 at 11:26 PM, Pierre-Yves David
> wrote:



# HG changeset patch
# User Pierre-Yves David
>
# Date 1493894621 -7200
#  Thu May 04 12:43:41 2017 +0200
# Node ID
2f51cfeac5bcf8ee266a6fada56517d5d44d9b6b
# Parent
1e8427b7d0b9ce66c5ba34c2cdb64821ff909267
# EXP-Topic changegroup.cleanup
# Available At

https://www.mercurial-scm.org/repo/users/marmoute/mercurial/


#  hg pull

https://www.mercurial-scm.org/repo/users/marmoute/mercurial/


-r
2f51cfeac5bc
changegroup: deprecate 'getlocalchangroup' (API)

We have 'getchangegroup' with a shorter name
for the exactly same
feature. Now
that all users are gone we can formally
deprecate it.




We usually just delete methods that we no longer
use internally. Why
not do that here?




When function are likely to be used by extension we
try to avoid dropping
them and we deprecated them for a version. This
helps third party
extensions
to smoothly detect the API changes (usually through
test run) and
smoothly
upgrade their code over the version cycle.



In this case I suspect it won't help many of them
because I probably
broke most or all anyway with
https://www.mercurial-scm.org/repo/hg/rev/282b288aa20c

.
I thought we
were okay with that kind of changes. Are you saying I
should have
instead added duplicate methods with the new signatures
and only
deprecated the existing methods?



Generating changegroup is a quite core feature in Mercurial.
I suspect their
are extension out there using these and I tried to be
careful. That is a gut
feeling. I'm did not looked at actual data. (that gut
feeling proved right
for "vfs", but might be wrong here)

(so, yes I would have been more careful with your API change
too)


Well, given that my patch probably broke most of those extensions, I
don't see much reason for your series to be more careful. But
there's
little harm in doing it, so I'll queue it once tests have run etc.


I agree doing both approach at the same time is sub-optimal :-)
We should either restore some of the (deprecated) 

[Bug 5560] New: Mercurial generates overly large HTTP headers on pull with many heads, causing HTTP 413 errors

2017-05-08 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=5560

Bug ID: 5560
   Summary: Mercurial generates overly large HTTP headers on pull
with many heads, causing HTTP 413 errors
   Product: Mercurial
   Version: 4.1.2
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: bug
  Priority: normal
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: gabor.stefa...@nng.com
CC: mercurial-devel@mercurial-scm.org

The total size of HTTP headers sent in the discovery phase of a HTTP pull grows
without limit as the number of topological heads increases in a repository.
This results in a constant need to adjust HTTP header buffer sizes on the
server, otherwise HTTP 413 Request entity too large errors start cropping up
during pulls.

We do have server.maxhttpheaderlen, but it doesn't help, as it only limits the
size of a single HTTP header, while most servers limit the total size of all
headers sent in a single request.
We either need to break up discovery into multiple requests, or switch to a
POST request (or another method that can have a body), and send the list of
known heads in the request body, which is usually unlimited in size.

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


[Bug 5559] New: sha256 upgrade error message prints wrong format: . instead of :

2017-05-08 Thread mercurial-bugs
https://bz.mercurial-scm.org/show_bug.cgi?id=5559

Bug ID: 5559
   Summary: sha256 upgrade error message prints wrong format: .
instead of :
   Product: Mercurial
   Version: 4.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: ro...@pep-project.org
CC: mercurial-devel@mercurial-scm.org

hg prints this update message when my .hgrc still contains SHA-1 host
fingerprints:

(SHA-1 fingerprint for xxx.yyy found in legacy [hostfingerprints] section; if
you trust this fingerprint, set the following config value in [hostsecurity]
and remove the old one from [hostfingerprints] to upgrade to a more secure
SHA-256 fingerprint: xxx.yyy.fingerprints=sha256:zz:zz:…:zz:zz)

I copied that line into my .hgrc, commented-out the old one but it does not
work.

After some googling I readed the "man 5 hgrc" more carefully and saw:

"Options  in  the [hostsecurity] section can have the form hostname:setting."

And changing .fingerprints into :fingerprints it works as it should. :-)

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