[PATCH 1 of 3] setup: use a more strict way to test BSD or OSX's statfs

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490332536 25200
#  Thu Mar 23 22:15:36 2017 -0700
# Node ID 597a29c947fe2b9f9ac0a6a03cf710ab9f69757c
# Parent  2c02bb7fd7fc1212029dc903527e35a9efb7dbe1
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 597a29c947fe
setup: use a more strict way to test BSD or OSX's statfs

We want to use the `f_fstypename` field to get the filesystem type. Test it
directly. The new macro HAVE_BSD_STATFS implys the old HAVE_SYS_MOUNT_H and
HAVE_SYS_PARAM_H. So the latter ones are removed.

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -597,6 +597,4 @@ for plat, func in [('bsd', 'setproctitle
 
 for plat, header in [
-('bsd|darwin|linux', 'sys/mount.h'),
-('bsd|darwin|linux', 'sys/param.h'),
 ('linux', 'linux/magic.h'),
 ('linux', 'sys/vfs.h'),
@@ -606,4 +604,14 @@ for plat, header in [
 osutil_cflags.append('-DHAVE_%s' % macro)
 
+for plat, macro, code in [
+('bsd|darwin', 'BSD_STATFS', '''
+ #include 
+ #include 
+ int main() { struct statfs s; return sizeof(s.f_fstypename); }
+ '''),
+]:
+if re.search(plat, sys.platform) and cancompile(new_compiler(), code):
+osutil_cflags.append('-DHAVE_%s' % macro)
+
 if sys.platform == 'darwin':
 osutil_ldflags += ['-framework', 'ApplicationServices']
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3] osutil: report fstype for BSD and OSX

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490332382 25200
#  Thu Mar 23 22:13:02 2017 -0700
# Node ID 825bb185512c66a43ae6927933196b8356c99798
# Parent  597a29c947fe2b9f9ac0a6a03cf710ab9f69757c
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 825bb185512c
osutil: report fstype for BSD and OSX

diff --git a/mercurial/osutil.c b/mercurial/osutil.c
--- a/mercurial/osutil.c
+++ b/mercurial/osutil.c
@@ -28,8 +28,6 @@
 #include 
 #endif
-#ifdef HAVE_SYS_MOUNT_H
+#ifdef HAVE_BSD_STATFS
 #include 
-#endif
-#ifdef HAVE_SYS_PARAM_H
 #include 
 #endif
@@ -802,5 +800,10 @@ static PyObject *setprocname(PyObject *s
 /* given a directory path, return filesystem type (best-effort), or None */
 const char *getfstype(const char *path) {
+#ifdef HAVE_BSD_STATFS
+   /* need to return a string field */
+   static struct statfs buf;
+#else
struct statfs buf;
+#endif
int r;
memset(, 0, sizeof(buf));
@@ -808,4 +811,8 @@ const char *getfstype(const char *path) 
if (r != 0)
return NULL;
+#ifdef HAVE_BSD_STATFS
+   /* BSD or OSX provides a f_fstypename field */
+   return buf.f_fstypename;
+#endif
/* Begin of Linux filesystems */
 #ifdef ADFS_SUPER_MAGIC
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] util: enable hardlink for some BSD-family filesystems

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490333510 25200
#  Thu Mar 23 22:31:50 2017 -0700
# Node ID be965400bcca7b69bd8e81f53b4ab6b66a847ba0
# Parent  825bb185512c66a43ae6927933196b8356c99798
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r be965400bcca
util: enable hardlink for some BSD-family filesystems

Since we can now detect filesystems on FreeBSD and OSX. Add their major
filesystems (ufs, zfs for FreeBSD; hfs for OSX) to the hardlink whitelist.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -1062,8 +1062,11 @@ def checksignature(func):
 'ext3',
 'ext4',
+'hfs',
 'jfs',
 'reiserfs',
 'tmpfs',
+'ufs',
 'xfs',
+'zfs',
 ])
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@31587: new changeset (1 on stable)

[Mercurial Commits]

New changeset (1 on stable) in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/ed5b25874d99
changeset:   31587:ed5b25874d99
branch:  stable
tag: tip
parent:  31516:2915cc1d3429
user:Gregory Szorc 
date:Thu Mar 23 19:54:59 2017 -0700
summary: changegroup: store old heads as a set

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

Re: GSoC 17: Release notes extension

[Martin von Zweigbergk via Mercurial-devel]

As an alternative to compiling the release notes from commit messages, we
could do what Git does, which is to keep a file per release
(Documentation/Relnotes/.txt in their case) that we update every
now and then. I think Junio (the maintainer) generally updates that file.
We don't have a single maintainer, but we could accept patches to from
anyone of course.

We could also keep the current process, which is to keep the release notes
on the wiki (I just started on https://www.mercurial-scm.org/wiki/Release4.2
yesterday).

I did like Greg's extension, but I wonder if it's worth the trouble of
having each contributor write part of the release notes. I wonder if we
won't want to restructure it enough afterwards anyway that I'm not sure the
automated step is worth the trouble. I understand that it helps us not
forget to include things in the release notes, but maybe it would be as
effective to add a new commit message tag like (RN) in addition to the (BC)
and (API) we already have.


On Thu, Mar 23, 2017 at 9:14 PM, Gregory Szorc 
wrote:

> On Mon, Mar 20, 2017 at 6:04 PM, Rishabh Madan 
> wrote:
>
>> Hello,
>>
>> I am Rishabh Madan and I will be a GSoC applicant this year under
>> Mercurial.
>>
>> I wanted to discuss about the Release notes extension project.[1]
>> 
>> I have gone through the mailing list discussions. I am currently
>> understanding the intial patch sent by Gregory Szorc, for the releasenotes
>> extension.
>>
>
> I hacked on this for an hour or two several days ago. A newer version is
> at https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/releasenotes.
> Not much has fundamentally changed: I was just trying to make commit
> message parsing more robust.
>
>
>>
>> I would like to get a few inputs for this project:
>>
>> 1. Commit message parser
>> (i) I feel this is the core of the idea. From what I understand, we will
>> have to keep a specific format for the commit messages that will be parsed
>> and output will be stored in a changelog. But, this is a extension that
>> would help other organizations as well. Do we expect them to abide by
>> certain format for the commit message?
>>
>
> For this idea to work, you have to standardize on *something*. I chose to
> use ReStructured Text admonitions (".. directive:: ...") because a)
> Mercurial already has a basic ReST parser and it was easy to leverage ReST
> b) ReST is extensible and therefore is a natural fit for this use case.
> There's no reason other formats couldn't be leveraged. But for a minimal
> viable product, I'd focus on ReST.
>
> The code as currently written converts extracted release notes fragments
> to Python data structures. So it should be possible to plug in other
> formats/parsers easily enough.
>
>
>> (ii) Is this going to be a hybrid process? I mean, will the notes once
>> created be edited by maintainers at a later stage?
>>
>
> This isn't implemented in my proof-of-concept yet, but yes, we absolutely
> need to support edits. The way I envision this being implemented is that
> there is some kind of similarity detection to reconcile differences between
> release notes fragments in commit messages and release notes files.
> Currently, the extension parses commit messages and a release notes file to
> a common data structure type, merges/unions the data, and emits a new
> release notes file. We need to add a step that attempts to match edited
> release notes file entries to their original commit message fragments so
> duplicates aren't produced. This can likely utilize the APIs already in
> Mercurial for identifying similar content.
>
>
>> (iii) The extension shouldn't add extremely small changesets to the
>> changelog. I think this can be done by adding some keyword to the commit
>> message (like [IGNORERST]).
>>
>
> As currently implemented, a release notes entry is only produced if the
> commit message contains special syntax - a ReST admonition. This avoids the
> problem of "extremely small changesets" polluting the release notes. But it
> has the drawback of requiring changeset authors to remember to write a
> release notes admonition. This trade-off is arguably tailored towards
> Mercurial's workflow, which focuses on writing many, smaller changesets
> (which results in many changesets being irrelevant to release notes). Since
> this extension is being authored to benefit the Mercurial project and since
> many of us feel passionately that our "microcommit" approach is superior to
> other approaches, we should probably focus on this (as opposed to merely
> extracting commit message summary lines to release notes files) :)
>
>
>>
>> 2. Linking hgweb to release notes
>> I found this idea quite intriguing. Can someone please elaborate a bit
>> more on what exactly we're trying to accomplish with this?
>>
>
> I think the idea here is for pages that reference a series or range of
> changesets (such as a tag) to 

[PATCH 2 of 4] journal: use lowercase for docstring title

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490328989 25200
#  Thu Mar 23 21:16:29 2017 -0700
# Node ID ece9613e199b69fd07611cc0fff81b5be530acd2
# Parent  2dd5b13aab032af04b3e2cafb14ac9bdfd519007
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r ece9613e199b
journal: use lowercase for docstring title

See the previous patch for why.

diff --git a/hgext/journal.py b/hgext/journal.py
--- a/hgext/journal.py
+++ b/hgext/journal.py
@@ -5,5 +5,5 @@
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2 or any later version.
-"""Track previous positions of bookmarks (EXPERIMENTAL)
+"""track previous positions of bookmarks (EXPERIMENTAL)
 
 This extension adds a new command: `hg journal`, which shows you where
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 4] automv: use lowercase for docstring title

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490328939 25200
#  Thu Mar 23 21:15:39 2017 -0700
# Node ID 2dd5b13aab032af04b3e2cafb14ac9bdfd519007
# Parent  2c02bb7fd7fc1212029dc903527e35a9efb7dbe1
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 2dd5b13aab03
automv: use lowercase for docstring title

The first line of docstring is used in `hg help -e`. Use lowercase to be
consistent with most extensions.

diff --git a/hgext/automv.py b/hgext/automv.py
--- a/hgext/automv.py
+++ b/hgext/automv.py
@@ -5,5 +5,5 @@
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2 or any later version.
-"""Check for unrecorded moves at commit time (EXPERIMENTAL)
+"""check for unrecorded moves at commit time (EXPERIMENTAL)
 
 This extension checks at commit/amend time if any of the committed files
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 4 of 4] checkcode: enforce lowercase for extension docstring title

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490329401 25200
#  Thu Mar 23 21:23:21 2017 -0700
# Node ID 0a73985fe80237a67ca50d7642ba6e02ed45e8e3
# Parent  f2026595cb39cce3934995d6a3f8aa3d97b30501
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 0a73985fe802
checkcode: enforce lowercase for extension docstring title

This will ensure new extensions are consistent and `hg help -e` has a
consistent output.

I have to add a new group since the normal "pypats" will be filtered by
"pyfilters", which will remove comments and docstrings.

diff --git a/contrib/check-code.py b/contrib/check-code.py
--- a/contrib/check-code.py
+++ b/contrib/check-code.py
@@ -372,4 +372,11 @@ pyfilters = [
 ]
 
+# extension non-filter patterns
+pyextnfpats = [
+[(r'^"""\n?[A-Z]', "don't capitalize docstring title")],
+# warnings
+[],
+]
+
 txtfilters = []
 
@@ -481,4 +488,5 @@ py3pats = [
 checks = [
 ('python', r'.*\.(py|cgi)$', r'^#!.*python', pyfilters, pypats),
+('python', r'.*hgext.*\.py$', '', [], pyextnfpats),
 ('python 3', r'.*(hgext|mercurial).*(?https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 4] logtoprocess: use lowercase for docstring title

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490329015 25200
#  Thu Mar 23 21:16:55 2017 -0700
# Node ID f2026595cb39cce3934995d6a3f8aa3d97b30501
# Parent  ece9613e199b69fd07611cc0fff81b5be530acd2
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r f2026595cb39
logtoprocess: use lowercase for docstring title

diff --git a/hgext/logtoprocess.py b/hgext/logtoprocess.py
--- a/hgext/logtoprocess.py
+++ b/hgext/logtoprocess.py
@@ -5,5 +5,5 @@
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2 or any later version.
-"""Send ui.log() data to a subprocess (EXPERIMENTAL)
+"""send ui.log() data to a subprocess (EXPERIMENTAL)
 
 This extension lets you specify a shell command per ui.log() event,
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH hglib] hglib: fix hg clone --uncompressed option typo

[Long Vu]

# HG changeset patch
# User Long Vu 
# Date 1490322881 14400
#  Thu Mar 23 22:34:41 2017 -0400
# Node ID a6ae14f83d7a5e822b214ab0216e9685395b778f
# Parent  ae38fb772613604dac7fcf63705e8a2a17ff50cd
hglib: fix hg clone --uncompressed option typo

Was getting error.CommandError
"hg clone: option --uncompresses not recognized".

diff --git a/hglib/__init__.py b/hglib/__init__.py
--- a/hglib/__init__.py
+++ b/hglib/__init__.py
@@ -28,7 +28,7 @@
   insecure=False, encoding=None, configs=None):
 args = util.cmdbuilder('clone', source, dest, noupdate=noupdate,
updaterev=updaterev, rev=rev, branch=branch,
-   pull=pull, uncompresses=uncompressed,
+   pull=pull, uncompressed=uncompressed,
e=ssh, remotecmd=remotecmd, insecure=insecure)
 
 args.insert(0, HGPATH)
diff --git a/tests/test-clone.py b/tests/test-clone.py
--- a/tests/test-clone.py
+++ b/tests/test-clone.py
@@ -11,3 +11,6 @@
 self.assertRaises(ValueError, cloned.log)
 cloned.open()
 self.assertEquals(self.client.log(), cloned.log())
+
+def test_clone_uncompressed(self):
+hglib.clone(b('.'), b('cloned'), uncompressed=True)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: GSoC 17: Release notes extension

[Gregory Szorc]

On Mon, Mar 20, 2017 at 6:04 PM, Rishabh Madan 
wrote:

> Hello,
>
> I am Rishabh Madan and I will be a GSoC applicant this year under
> Mercurial.
>
> I wanted to discuss about the Release notes extension project.[1]
> 
> I have gone through the mailing list discussions. I am currently
> understanding the intial patch sent by Gregory Szorc, for the releasenotes
> extension.
>

I hacked on this for an hour or two several days ago. A newer version is at
https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/releasenotes. Not
much has fundamentally changed: I was just trying to make commit message
parsing more robust.


>
> I would like to get a few inputs for this project:
>
> 1. Commit message parser
> (i) I feel this is the core of the idea. From what I understand, we will
> have to keep a specific format for the commit messages that will be parsed
> and output will be stored in a changelog. But, this is a extension that
> would help other organizations as well. Do we expect them to abide by
> certain format for the commit message?
>

For this idea to work, you have to standardize on *something*. I chose to
use ReStructured Text admonitions (".. directive:: ...") because a)
Mercurial already has a basic ReST parser and it was easy to leverage ReST
b) ReST is extensible and therefore is a natural fit for this use case.
There's no reason other formats couldn't be leveraged. But for a minimal
viable product, I'd focus on ReST.

The code as currently written converts extracted release notes fragments to
Python data structures. So it should be possible to plug in other
formats/parsers easily enough.


> (ii) Is this going to be a hybrid process? I mean, will the notes once
> created be edited by maintainers at a later stage?
>

This isn't implemented in my proof-of-concept yet, but yes, we absolutely
need to support edits. The way I envision this being implemented is that
there is some kind of similarity detection to reconcile differences between
release notes fragments in commit messages and release notes files.
Currently, the extension parses commit messages and a release notes file to
a common data structure type, merges/unions the data, and emits a new
release notes file. We need to add a step that attempts to match edited
release notes file entries to their original commit message fragments so
duplicates aren't produced. This can likely utilize the APIs already in
Mercurial for identifying similar content.


> (iii) The extension shouldn't add extremely small changesets to the
> changelog. I think this can be done by adding some keyword to the commit
> message (like [IGNORERST]).
>

As currently implemented, a release notes entry is only produced if the
commit message contains special syntax - a ReST admonition. This avoids the
problem of "extremely small changesets" polluting the release notes. But it
has the drawback of requiring changeset authors to remember to write a
release notes admonition. This trade-off is arguably tailored towards
Mercurial's workflow, which focuses on writing many, smaller changesets
(which results in many changesets being irrelevant to release notes). Since
this extension is being authored to benefit the Mercurial project and since
many of us feel passionately that our "microcommit" approach is superior to
other approaches, we should probably focus on this (as opposed to merely
extracting commit message summary lines to release notes files) :)


>
> 2. Linking hgweb to release notes
> I found this idea quite intriguing. Can someone please elaborate a bit
> more on what exactly we're trying to accomplish with this?
>

I think the idea here is for pages that reference a series or range of
changesets (such as a tag) to automatically extract release notes from
changesets in that range. For example, if you load the "4.2" tag page, you
would have a link to or inline rendering of all release notes relevant to
changesets between 4.1 and 4.2.

There is a lot of ambiguity in this feature. For example, how do you handle
edits to release notes files? This would require the server to define where
release notes files are stored in the repo. Otherwise, the hgweb view would
only render commit message content, which may not be complete! For this
reason, I think hgweb support should be a secondary goal of the project.


>
> I also found some open source implementations like [2]
>  similar to this
> idea that might help in implementing this project.
>

Yes, there is a lot of prior art in this topic. We can and should look to
others for inspiration for good ideas.

One thing to keep in mind is that many of these solutions simply assemble
*all* changes. For projects with ~1000 commits every release (like
Mercurial), listing every change is too noisy: you need to curate the
information in release notes or people will get lost in the noise. This is
why the 

Re: [PATCH STABLE] changegroup: store old heads as a set

[Augie Fackler]

> On Mar 23, 2017, at 10:59 PM, Gregory Szorc  wrote:
> 
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1490324099 25200
> #  Thu Mar 23 19:54:59 2017 -0700
> # Branch stable
> # Node ID ba2c20c45b3e0202e52bbd3252f9a8214d8a2e06
> # Parent  2915cc1d3429f9b11c9cf48d45990f982fff8e7a
> changegroup: store old heads as a set

Queued for stable. Thanks.


> Previously, the "oldheads" variable was a list. On a repository at
> Mozilla with 46,492 heads, profiling revealed that list membership
> testing was dominating execution time of applying small changegroups.
> 
> This patch converts the list of old heads to a set. This makes
> membership testing significantly faster. On the aforementioned
> repository with 46,492 heads:
> 
> $ hg unbundle 
> before: 18.535s wall
> after:   1.303s
> 
> Consumers of this variable only check for truthiness (`if oldheads`),
> length (`len(oldheads)`), and (most importantly) item membership
> (`h not in oldheads` - which occurs twice). So, the change to a set
> should be safe and suitable for stable.
> 
> The practical effect of this change is that changegroup application
> and related operations (like `hg push`) no longer exhibit an O(n^2)
> CPU explosion as the number of heads grows.
> 
> diff --git a/mercurial/changegroup.py b/mercurial/changegroup.py
> --- a/mercurial/changegroup.py
> +++ b/mercurial/changegroup.py
> @@ -293,7 +293,7 @@ class cg1unpacker(object):
> # will not see an inconsistent view
> cl = repo.changelog
> cl.delayupdate(tr)
> -oldheads = cl.heads()
> +oldheads = set(cl.heads())
> 
> trp = weakref.proxy(tr)
> # pull off the changeset group
> ___
> 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 3 of 3] [RFC] dispatch: setup color before pager

[Matt Harbison]

On Tue, 21 Mar 2017 23:10:36 -0400, Gregory Szorc  
 wrote:



On Tue, Mar 21, 2017 at 6:11 PM, Matt Harbison 
wrote:


(+CC: indygreg, since he added this functionality in 4e02418b4236)

On Tue, 21 Mar 2017 17:36:29 -0400, Augie Fackler   
wrote:


On Mon, Mar 20, 2017 at 12:53:19AM -0400, Matt Harbison wrote:



# HG changeset patch
# User Matt Harbison 
# Date 1489985511 14400
#  Mon Mar 20 00:51:51 2017 -0400
# Node ID 2a323109f8e7ec5548dd506c2cff05f27fa20c1e
# Parent  6e72bb689e57c985b138c580acb4cad8053dc180
[RFC] dispatch: setup color before pager



Oy, these two I just dunno. I'll defer to other Windows experts.



Heh. You have no idea how sad my Sunday was :-/

Just to be clear, these last two can't be taken as-is.  The output on
Windows without a pager is black text on a green background.

I did a little more playing, and if we don't do something, this will be  
a

regression.  In 4.1, both of these commands colorize in MSYS:

[extensions]
color =

[pager]
pager = less

$ hg log -l 5 --config extensions.pager= --config color.pagermode=ansi

$ hg log -l 5 --config color.pagermode=ansi


Now, neither of them do (both are now paged).  You have to set
'--pager=no' to get the color back, or add '--config color.mode=ansi'.   
But

the latter breaks the output when disabling pager.  And even if that
magically worked, that doesn't help with switching between MSYS and
cmd.exe, which is why I'd love to make 'auto' smarter.  (I'd rather not
resort to %include hacks).



So the whole reason behind 4e02418b4236 (as documented in the commit
message) is that different pagers support different escape sequences. At
the time, I couldn't figure out an elegant way to detect the pager's
capabilities at run time. So, I added a config option that could be  
defined

in certain environments (like a controlled msys environment where `less`
was installed as the pager such as the one that Mozilla uses to build
Firefox) so that pager+color would "just work" in both cmd.exe and an  
msys

environment. More info at
https://bugzilla.mozilla.org/show_bug.cgi?id=545432#c59 and below (search
for my name).

Core Mercurial should focus on behavior in a stock cmd.exe environment  
and

be best-effort - but not broken - for cygwin, msys, etc. This is what
a7d98606 aimed to achieve. If someone is running a non-cmd.exe
terminal, I think it is up to the packager to enable a reasonable default
(such as Mozilla setting color.pagermode in our MozillaBuild msys
environment).


That seems reasonable.  But color.pagermode seems broken for auto pager,  
now that everything has transitioned to the core.  It works on stable (if  
the color/pager load order is right).


4.1:

1) Color wrapped dispatch._runcommand() and pager wrapped color's wrapper.
2) Running a command will:
   a) Call the pager wrapper, set ui.pageractive, and spawn the pager if
  True
   b) Call the color wrapper, and examine ui.pageractive to see if it cares
  about color.pagermode
   c) Call the actual command

Default branch:

1) Pager settings are forced on or off in dispatch.  '--pager=on' fires up
   a pager; 'auto' pager mode defers spawning a pager.
2) Color is setup (examining ui.pageractive), and color.mode=auto is
   resolved
3) Run the command
   a) spawn a pager the pager, setting ui.pageractive=True

I think this means that the process of spawning the pager needs to be able  
to call color.setup() again, so that it can reexamine ui.pageractive.   
Otherwise, the only way 'ui.pageractive' is ever true when color is  
getting setup is if --pager != 'auto|off'.  IDK the implications of a  
second setup, and I'm perplexed by all of the various ui objects that  
exist.  I didn't check yet to see if there's any possibility to output  
before the calls to ui.pager() now.  (I wonder if there are instances in  
largefiles with all of its overrides.)


Thoughts?

Also, if you want a new challenge, the Windows console apparently  
supports

24-bit color (
https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/)
and ANSI+VT-100 escape sequences now.
https://github.com/symfony/symfony/pull/18385 and
https://github.com/Microsoft/BashOnWindows/issues/1173 are somewhat
informative. We could likely detect the Windows version and active  
terminal

to call SetConsoleMode with ENABLE_VIRTUAL_TERMINAL_PROCESSING. Then
pager.color=ansi should "just work" on Windows.


Thanks for the tip- I forgot about this.  I'm not on Windows 10, so it  
isn't a high priority for me, but I'll look into it if I can find some  
spare time.




IIRC, the inter-operation between these two extensions was why the  
ability

to register an afterload callback was added.  I'll keep looking at this,
but I suspect we need a color+pager expert more than a Windows expert.



I think that afterload callback was always buggy and should be fixed or
removed :/







With 

[PATCH STABLE] changegroup: store old heads as a set

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1490324099 25200
#  Thu Mar 23 19:54:59 2017 -0700
# Branch stable
# Node ID ba2c20c45b3e0202e52bbd3252f9a8214d8a2e06
# Parent  2915cc1d3429f9b11c9cf48d45990f982fff8e7a
changegroup: store old heads as a set

Previously, the "oldheads" variable was a list. On a repository at
Mozilla with 46,492 heads, profiling revealed that list membership
testing was dominating execution time of applying small changegroups.

This patch converts the list of old heads to a set. This makes
membership testing significantly faster. On the aforementioned
repository with 46,492 heads:

$ hg unbundle 
before: 18.535s wall
after:   1.303s

Consumers of this variable only check for truthiness (`if oldheads`),
length (`len(oldheads)`), and (most importantly) item membership
(`h not in oldheads` - which occurs twice). So, the change to a set
should be safe and suitable for stable.

The practical effect of this change is that changegroup application
and related operations (like `hg push`) no longer exhibit an O(n^2)
CPU explosion as the number of heads grows.

diff --git a/mercurial/changegroup.py b/mercurial/changegroup.py
--- a/mercurial/changegroup.py
+++ b/mercurial/changegroup.py
@@ -293,7 +293,7 @@ class cg1unpacker(object):
 # will not see an inconsistent view
 cl = repo.changelog
 cl.delayupdate(tr)
-oldheads = cl.heads()
+oldheads = set(cl.heads())
 
 trp = weakref.proxy(tr)
 # pull off the changeset group
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 3] util: add a getfstype method

[Augie Fackler]

> On Mar 23, 2017, at 3:07 PM, Jun Wu  wrote:
> 
> # HG changeset patch
> # User Jun Wu 
> # Date 1490295525 25200
> #  Thu Mar 23 11:58:45 2017 -0700
> # Node ID 235f1212559d03f115e21992b5725a7dc7787632
> # Parent  2c02bb7fd7fc1212029dc903527e35a9efb7dbe1
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 235f1212559d
> util: add a getfstype method

Queued these, thanks

> 
> The util version is a thin wrapper of the osutil version, which is not
> always available.
> 
> diff --git a/mercurial/util.py b/mercurial/util.py
> --- a/mercurial/util.py
> +++ b/mercurial/util.py
> @@ -1368,4 +1368,11 @@ def fspath(name, root):
> return ''.join(result)
> 
> +def getfstype(dirpath):
> +'''Get the filesystem type name from a directory (best-effort)
> +
> +Returns None if we are unsure, or errors like ENOENT, EPERM happen.
> +'''
> +return getattr(osutil, 'getfstype', lambda x: None)(dirpath)
> +
> def checknlink(testfile):
> '''check whether hardlink count reporting works properly'''
> ___
> 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

[PATCH V3] pager: fix the invocation of `more` on Windows

[Matt Harbison]

# HG changeset patch
# User Matt Harbison 
# Date 1489983573 14400
#  Mon Mar 20 00:19:33 2017 -0400
# Node ID d0c2db2d9f13dca534c598de050eb1919ef79059
# Parent  df82f375fa005b9c71b463182e6b54aa47fa5999
pager: fix the invocation of `more` on Windows

After 9335dc6b2a9c, with 'shell' being (mostly) set to False, invoking `more` no
longer worked.  Instead, a warning was printed and the pager was disabled.
Invoking `more.com` works.  Since a user may have configured 'pager.pager=more',
do this substitution at the end.  Surprisingly, `more` does allow for arguments,
so those are preserved.  This also allows `more` to work in MSYS.

Setting 'shell=False' runs the executable via CreateProcess(), which has rather
wonky rules for resolving an executable without an extension [1].  Resolving to
*.com is not among them.  Since 'shell=True' yields a cryptic error for a bad
$PAGER, and a *.exe program will work without specifying the extension, sticking
with current 'shell=False' seems like the right thing to do.  I don't think
there are any other *.com pagers out there, so this one special case seems OK.

If somebody wants to do something crazy that requires cmd.exe, I was able to get
normal paged output with 'pager.pager="cmd.exe /c more"'.  I assume you can
replace `more` with *.bat, *.vbs or various other creatures listed in $PATHEXT.

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -844,6 +844,15 @@
 if not pagercmd:
 return
 
+if pycompat.osname == 'nt':
+# `more` cannot be invoked with shell=False, but `more.com` can.
+# Hide this implementation detail from the user, so we can also get
+# sane bad PAGER behavior.  If args are also given, the space in 
the
+# command line forces shell=True, so that case doesn't need to be
+# handled here.
+if pagercmd == 'more':
+pagercmd = 'more.com'
+
 self.debug('starting pager for command %r\n' % command)
 self.flush()
 self.pageractive = True
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] obsolete: allow cycles

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-03-23 20:59:03 -0400:
> > For clocks going backwards, we can detect that, say we get
> > maxdate = max(m.date for m in markers), then if we are going to write a
> > marker with date < maxdate, we could warn people, and/or write 
> > (date+rand(0 to 1)) as a fake date. That would at least make non-exchange
> > experience always expected.
> 
> Could we default to using the current timestamp, but if there’s a member
> of the obsmarker chain we’re about to add to with a time ahead of our
> clock, we do (that time + rand(0,1)) as the time? Greg, does that
> alleviate most of your concern around using times?

That was what I suggested. A warning is probably worthy if that happens.

More strictly, when loading the obsstore, if any marker has a time greater
than the local system time, it may be worth a warning so we can detect
problems early.

> (This has the negative that in the presence of marker cycles time is
> somewhat a lie, but I think the overall ergonomics seem to be about right
> at least as a thought experiment...)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

> On Mar 23, 2017, at 6:15 PM, Jun Wu  wrote:
> 
> Excerpts from Augie Fackler's message of 2017-03-23 17:53:39 -0400:
>> On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu  wrote:
 As for alternatives, a correct solution needs to refer to the marker it is
 replacing. Since cycles should be rare, can we record the full "replaced
 marker" data inline in the new marker? In local storage, that could be an
>>> 
>>> If "markers being replaced" are explicitly recorded, you will miss remote
>>> markers that can be possibly replaced because you don't know them at the
>>> time appending a new local marker. So you end up with some "conflict
>>> resolution" logic during exchange.
>>> 
>>> That is not very different from just using the offsets - since obsstore is
>>> append-only, new markers just "replace" old ones (I don't think there is an
>>> exception that the newly added marker is intended to be replaced by a
>>> previous one when working locally). It's simpler but has the same exchange
>>> headache.
>> 
>> I wonder: could we get away from using dates by putting some kind of
>> generation number in the marker? So if a marker would create a cycle,
>> we increment its generation number relative to the previous highest
>> value in the cycle.
> 
> The problem is you don't know if a marker will create a cycle (or should
> invalidate another marker), because remote markers are unknown. If you do
> that during exchange, it makes exchange more complex.
> 
> I think that is not very different from just using the offsets.
> 
> Basically, if the new filed which is meant to be spread globally, date is
> probably the best option. If it is not meant to be spread globally, offset
> is already a decent choice, without format change. But offsets brings up
> the exchange headache.
> 
> marmoute preferred date to offsets. And I agree because I don't have good
> idea to handle the exchange headache (or I think it's better to be fully
> automatic).
> 
>> It still means a bad actor can produce a hard-to-defeat cycle (sort
>> of), but it solves the clock skew issue.
> 
> For clocks going backwards, we can detect that, say we get
> maxdate = max(m.date for m in markers), then if we are going to write a
> marker with date < maxdate, we could warn people, and/or write 
> (date+rand(0 to 1)) as a fake date. That would at least make non-exchange
> experience always expected.

Could we default to using the current timestamp, but if there’s a member of the 
obsmarker chain we’re about to add to with a time ahead of our clock, we do 
(that time + rand(0,1)) as the time? Greg, does that alleviate most of your 
concern around using times?

(This has the negative that in the presence of marker cycles time is somewhat a 
lie, but I think the overall ergonomics seem to be about right at least as a 
thought experiment...)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@31586: 8 new changesets

[Mercurial Commits]

8 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/3a383caa97f4
changeset:   31579:3a383caa97f4
user:Yuya Nishihara 
date:Sun Mar 15 18:58:56 2015 +0900
summary: similar: sort files not by object id but by path for stable result

https://www.mercurial-scm.org/repo/hg/rev/d3e2af4e0128
changeset:   31580:d3e2af4e0128
user:Yuya Nishihara 
date:Thu Mar 23 20:50:33 2017 +0900
summary: similar: get rid of quadratic addedfiles.remove()

https://www.mercurial-scm.org/repo/hg/rev/b1528d195a13
changeset:   31581:b1528d195a13
user:Yuya Nishihara 
date:Thu Mar 23 21:10:45 2017 +0900
summary: similar: use common names for changectx variables

https://www.mercurial-scm.org/repo/hg/rev/2e254165a37c
changeset:   31582:2e254165a37c
user:Yuya Nishihara 
date:Thu Mar 23 21:17:08 2017 +0900
summary: similar: do not look up and create filectx more than once

https://www.mercurial-scm.org/repo/hg/rev/2efd9771323e
changeset:   31583:2efd9771323e
user:Yuya Nishihara 
date:Thu Mar 23 20:52:41 2017 +0900
summary: similar: take the first match instead of the last

https://www.mercurial-scm.org/repo/hg/rev/985a98c6bad0
changeset:   31584:985a98c6bad0
user:Yuya Nishihara 
date:Thu Mar 23 20:57:27 2017 +0900
summary: similar: use cheaper hash() function to test exact matches

https://www.mercurial-scm.org/repo/hg/rev/c6921568cd20
changeset:   31585:c6921568cd20
user:Kostia Balytskyi 
date:Wed Mar 22 11:26:23 2017 -0700
summary: tests: make test-simplekeyvaluefile.py py2.6-compatible

https://www.mercurial-scm.org/repo/hg/rev/df82f375fa00
changeset:   31586:df82f375fa00
bookmark:@
tag: tip
user:Pierre-Yves David 
date:Tue Mar 21 23:30:13 2017 +0100
summary: checkheads: extract obsolete post processing in its own function

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

Re: [PATCH 4 of 4 V2] obsolete: allow cycles

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-03-23 17:53:39 -0400:
> On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu  wrote:
> >> As for alternatives, a correct solution needs to refer to the marker it is
> >> replacing. Since cycles should be rare, can we record the full "replaced
> >> marker" data inline in the new marker? In local storage, that could be an
> >
> > If "markers being replaced" are explicitly recorded, you will miss remote
> > markers that can be possibly replaced because you don't know them at the
> > time appending a new local marker. So you end up with some "conflict
> > resolution" logic during exchange.
> >
> > That is not very different from just using the offsets - since obsstore is
> > append-only, new markers just "replace" old ones (I don't think there is an
> > exception that the newly added marker is intended to be replaced by a
> > previous one when working locally). It's simpler but has the same exchange
> > headache.
> 
> I wonder: could we get away from using dates by putting some kind of
> generation number in the marker? So if a marker would create a cycle,
> we increment its generation number relative to the previous highest
> value in the cycle.

The problem is you don't know if a marker will create a cycle (or should
invalidate another marker), because remote markers are unknown. If you do
that during exchange, it makes exchange more complex.

I think that is not very different from just using the offsets.

Basically, if the new filed which is meant to be spread globally, date is
probably the best option. If it is not meant to be spread globally, offset
is already a decent choice, without format change. But offsets brings up
the exchange headache.

marmoute preferred date to offsets. And I agree because I don't have good
idea to handle the exchange headache (or I think it's better to be fully
automatic).

> It still means a bad actor can produce a hard-to-defeat cycle (sort
> of), but it solves the clock skew issue.

For clocks going backwards, we can detect that, say we get
maxdate = max(m.date for m in markers), then if we are going to write a
marker with date < maxdate, we could warn people, and/or write 
(date+rand(0 to 1)) as a fake date. That would at least make non-exchange
experience always expected.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 09 of 13 V3] ui: use scmutil.rccomponents to load configs (BC)

[Augie Fackler]

On Thu, Mar 23, 2017 at 09:53:26AM -0700, Jun Wu wrote:
> Excerpts from Martin von Zweigbergk's message of 2017-03-22 22:34:47 -0700:
> > On Wed, Mar 22, 2017 at 10:23 AM, Jun Wu  wrote:
> > > # HG changeset patch
> > > # User Jun Wu 
> > > # Date 1489462886 25200
> > > #  Mon Mar 13 20:41:26 2017 -0700
> > > # Node ID 6c04717d3b4958800a39fdf6e2c28e2caf6629bd
> > > # Parent  c537d04829a8dc0b88fe03ec41e95a85638c696b
> > > # Available At https://bitbucket.org/quark-zju/hg-draft
> > > #  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 
> > > 6c04717d3b49
> > > ui: use scmutil.rccomponents to load configs (BC)
> > >
> > > This is BC because system configs won't be able to override $EDITOR, 
> > > $PAGER.
> > > The new behavior is arguably more rational.
> > >
> > > The code added is somehow temporary. Once we have immutable config 
> > > objects,
> > > this area will be cleaner.
> > >
> > > diff --git a/mercurial/ui.py b/mercurial/ui.py
> > > --- a/mercurial/ui.py
> > > +++ b/mercurial/ui.py
> > > @@ -212,6 +212,19 @@ class ui(object):
> > >  u = cls()
> > >  # we always trust global config files
> >
> > Do you know what this comment refers to? Should it be moved a few
> > lines down now (I'm thinking maybe just before u.readconfig())?
>
> I think it can be updated to "trust global config files and environment" so
> it says at the current position and explains the 'items' case.

That's what this comment is referring to (as a confirmation).

>
> >
> > > -for f in scmutil.rcpath():
> > > -u.readconfig(f, trust=True)
> > > +for (t, f) in scmutil.rccomponents():
> > > +if t == 'path':
> > > +u.readconfig(f, trust=True)
> > > +elif t == 'items':
> > > +sections = set()
> > > +for section, name, value, source in f:
> > > +# do not set ocfg
> > > +# XXX change this once we have immutable config 
> > > objects
> > > +u._tcfg.set(section, name, value, source)
> > > +u._ucfg.set(section, name, value, source)
> > > +sections.add(section)
> > > +for section in sections:
> > > +u.fixconfig(section=section)
> > > +else:
> > > +raise error.ProgrammingError('unexpected rccomponent: 
> > > %s' % t)
> > >  return u
> > >
> > > diff --git a/tests/test-config-env.py b/tests/test-config-env.py
> > > new file mode 100644
> > > --- /dev/null
> > > +++ b/tests/test-config-env.py
> > > @@ -0,0 +1,48 @@
> > > +# Test the config layer generated by environment variables
> > > +
> > > +from __future__ import absolute_import, print_function
> > > +
> > > +import os
> > > +
> > > +from mercurial import (
> > > +encoding,
> > > +scmutil,
> > > +ui as uimod,
> > > +)
> > > +
> > > +testtmp = encoding.environ['TESTTMP']
> > > +
> > > +# prepare hgrc files
> > > +def join(name):
> > > +return os.path.join(testtmp, name)
> > > +
> > > +with open(join('sysrc'), 'w') as f:
> > > +f.write('[ui]\neditor=e0\n[pager]\npager=p0\n')
> > > +
> > > +with open(join('userrc'), 'w') as f:
> > > +f.write('[ui]\neditor=e1')
> > > +
> > > +# replace rcpath functions so they point to the files above
> > > +def systemrcpath():
> > > +return [join('sysrc')]
> > > +
> > > +def userrcpath():
> > > +return [join('userrc')]
> > > +
> > > +scmutil.systemrcpath = systemrcpath
> > > +scmutil.userrcpath = userrcpath
> > > +os.path.isdir = lambda x: False # hack: do not load default.d/*.rc
> > > +
> > > +# utility to print configs
> > > +def printconfigs(env):
> > > +encoding.environ = env
> > > +scmutil._rccomponents = None # reset cache
> > > +ui = uimod.ui.load()
> > > +for section, name, value in ui.walkconfig():
> > > +source = ui.configsource(section, name)
> > > +print('%s.%s=%s # %s' % (section, name, value, source))
> > > +print('')
> > > +
> > > +# environment variable overrides
> > > +printconfigs({})
> > > +printconfigs({'EDITOR': 'e2', 'PAGER': 'p2'})
> > > diff --git a/tests/test-config-env.py.out b/tests/test-config-env.py.out
> > > new file mode 100644
> > > --- /dev/null
> > > +++ b/tests/test-config-env.py.out
> > > @@ -0,0 +1,6 @@
> > > +pager.pager=p0 # $TESTTMP/sysrc:4
> > > +ui.editor=e1 # $TESTTMP/userrc:2
> > > +
> > > +pager.pager=p2 # $PAGER
> > > +ui.editor=e1 # $TESTTMP/userrc:2
> > > +
> > > diff --git a/tests/test-config.t b/tests/test-config.t
> > > --- a/tests/test-config.t
> > > +++ b/tests/test-config.t
> > > @@ -165,2 +165,16 @@ edit failure
> > >abort: edit failed: false exited with status 1
> > >[255]
> > > +
> > > +config affected by environment variables
> > > +
> > > +  $ EDITOR=e1 VISUAL=e2 hg config --debug | grep 'ui\.editor'
> > > +  $VISUAL: ui.editor=e2
> > > +
> > > +  $ VISUAL=e2 hg config --debug --config ui.editor=e3 

Re: [PATCH 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

On Mon, Mar 13, 2017 at 11:57:08AM -0700, Pierre-Yves David wrote:
>
>
> On 03/13/2017 09:23 AM, Durham Goode wrote:
> >On 3/13/17 2:48 AM, Jun Wu wrote:
> >># HG changeset patch
> >># User Jun Wu 
> >># Date 1489395002 25200
> >>#  Mon Mar 13 01:50:02 2017 -0700
> >># Node ID 6ae6d1069ba1d4089afaeb0bb8ef2411983a1292
> >># Parent  0280ee091bd0ae33aa0a67b0c8a55ccffd2e0718
> >># Available At
> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_quark-2Dzju_hg-2Ddraft=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=nuarHzhP1wi1T9iURRCj1A=teHrSOWg352cIHpPJ_QkfGT4tGnEsAx8upZBTGYdh94=aOoZRXz4F1btSijuLHmlEK-JsH1Sp_YSgBvT6DoaL-E=
> >>
> >>#  hg pull
> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_quark-2Dzju_hg-2Ddraft=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=nuarHzhP1wi1T9iURRCj1A=teHrSOWg352cIHpPJ_QkfGT4tGnEsAx8upZBTGYdh94=aOoZRXz4F1btSijuLHmlEK-JsH1Sp_YSgBvT6DoaL-E=
> >>-r 6ae6d1069ba1
> >>obsolete: allow cycles
> >>
> >>Now we can handle cycles nicely, allow them to be created. Some practical
> >>examples:
> >>
> >>  - To revive X, just create a marker X -> X, with a newer date.
> >>  - To prune X again, just create a marker X -> (), with a newer date.
> >>  - The above two could be repeated.
> >>
> >>  - To unamend A -> B, just create a marker B -> A, with a newer date.
> >>
> >>It's now possible for "touch" and "unamend" to reuse hashes (therefore
> >>more
> >>user-friendly). And it's no longer necessary to write "*_source" in
> >>commit
> >>metadata to workarounds obs cycles. The hacky inhibit extension also
> >>becomes
> >>unnecessary.
> >>
> >>Finally. I have been wanting all these for a long time.
> >
> >Seems pretty elegant, though I haven't fully understood it yet. Maybe
> >you guys talked about this in person, but what effect (if any) does this
> >have on exchange?
>
> We did not really discuss this at the sprint :-/
>
> This probably has effect on two aspects of pull and push:
>
> * Computation of the relevant markers for a None
>
> * Computation of "head replacement" when pushing branches obsoleting another
> one.
>
> The proposal have some very interesting aspect, I'll try to do a deep review
> of its impact on the general concept soon™ (probably not this week)

I've had a look over the code, and it's surprisingly simple (though it
could probably use more comments for future code archaeologists.) I'm
wary (as is indygreg) of using the date field for this sorting, just
because clocks are known sources of evil and consternation.

(I acknowledge we might not have a significantly better choice though,
although I'd like to give it some more thought.)

>
> 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 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

On Wed, Mar 22, 2017 at 4:59 PM, Sean Farley  wrote:
>>> > By the way, I'm not sure if you have noticed that "inhibit" was recently
>>> > moved to a directory called "hack/" in mutable-history.
>>>
>>> Yes, things in evolve are still baking. I don't see the need to rush obs
>>> cycles into core based on that, though.
>>
>> Shall we have "unamend", "unrebase", "unhistedit" and "undo" ready, please
>> do not use them as you don't need them.
>
> But that's part of the problem: all the edge cases mentioned here will
> affect normal use of obs markers. Why not put this in an extension for
> now? I don't see how this is more important than fixing terminology /
> error messages / UI / UX / etc etc etc.

I'm deeply sympathetic to the desire to "just roll back to an old
version of this" and not have the hash change, and I'm also extremely
sympathetic to the idea that cycles should have an obvious, easy way
to recover. Something like what Jun has proposed in this series
strikes me as the least-awful option to date, though I haven't
considered it as much as I'm sure Jun and Pierre-Yves have.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu  wrote:
>> As for alternatives, a correct solution needs to refer to the marker it is
>> replacing. Since cycles should be rare, can we record the full "replaced
>> marker" data inline in the new marker? In local storage, that could be an
>
> If "markers being replaced" are explicitly recorded, you will miss remote
> markers that can be possibly replaced because you don't know them at the
> time appending a new local marker. So you end up with some "conflict
> resolution" logic during exchange.
>
> That is not very different from just using the offsets - since obsstore is
> append-only, new markers just "replace" old ones (I don't think there is an
> exception that the newly added marker is intended to be replaced by a
> previous one when working locally). It's simpler but has the same exchange
> headache.

I wonder: could we get away from using dates by putting some kind of
generation number in the marker? So if a marker would create a cycle,
we increment its generation number relative to the previous highest
value in the cycle.

It still means a bad actor can produce a hard-to-defeat cycle (sort
of), but it solves the clock skew issue.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 01 of 13 V3] scmutil: add a method to convert environment variables to config items

[Martin von Zweigbergk via Mercurial-devel]

On Thu, Mar 23, 2017 at 1:21 PM, Kevin Bullock
 wrote:
>> On Mar 23, 2017, at 13:27, Jun Wu  wrote:
>>
>> Thanks for the detailed review and especially for raising the pattern
>> issue! I think you have a very good point, and I actually prefer the less
>> commits way.
>>
>> I'd like to provide the reason for this particular series. The general
>> question will be left for others to comment.
>>
>> The reason was simple - I was involuntarily avoiding changing "ui.py" and
>> "scmutil.py" together. I should have just changed them together in a single
>> commit called "change rcpath return type and update its users", despite the
>> OneChangePerPatch wiki [1] says "and" indicates something wrong.
>
> I wouldn't consider "change a function's signature and update its callers" to 
> be separate changes

+1

> -- in fact, we often make such changes and summarize them simply as "change 
> function's signature". That implies strongly enough that the call sites are 
> updated too.
>
> If there are _lots_ of call sites, then sometimes it's helpful to add a new 
> function, and one by one transition call sites to use the new function. A 
> good recent example of this is 279cbde7bf3d::fb1b5cd17664.
>
> But in the case of your series, I'd suggest an order very similar to Martin's:
>
> [01] scmutil: extract rc.d listing function from rccomponents
> [02] scmutil: split osrcpath to return default.d paths (API)
> [03] scmutil: rename rcpath to rccomponents (API)
> [04] scmutil: implement rccomponents to return a list of [('path', 
> '/path/to/hgrc'), ...], but NOT consult environment yet -- this also implies 
> changing the call sites (API)

Agreed. I actually meant for that to be the case (i.e. not introducing
'items' types yet), but I should have clarified it as you did. Thanks.

> [05] run-tests: drop environment variables affecting configs
> [06] scmutil: add a method to convert environment variables to config items
> [07] scmutil: define a list of configs overriding system rc, but not users

I would fold these two into the next. I think we just disagree on
that, but I wanted to mention it in case it was just not clear (I
didn't say it explicitly, I think).

> [08] config: let env variables override system hgrc (BC) -- here update 
> commands.py and ui.py to deal with 'items' entries (i.e., fold most of your 
> V3 patches 9 and 10 into this)
> [09] ui: simplify geteditor
> [10] pager: do not read from environment variable
>
>> The fact that most codemods are done one-commit-per-file, and per-file
>> commit message exists for a good reason [2] made me wonder if a changeset
>> should just change one file. But that shouldn't be a strict rule anyway.
>
> One logical change can definitely span more than one file. We generally go 
> file-by-file only when there's a bunch of call sites. And in those cases, it 
> seems to always be the right approach to introduce the new API with a new 
> name, convert all the callers incrementally, and then deprecate/remove the 
> old API.
>
> This series is a more localized refactor, so I don't think that approach is 
> called for here.
>
> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
>

Thanks to both of you for your replies. I'm glad we three seem to
mostly agree about this.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 07 of 13 V3] scmutil: extract rc.d listing function from rccomponents

[Kevin Bullock]

> On Mar 22, 2017, at 12:23, Jun Wu  wrote:
> 
> # HG changeset patch
> # User Jun Wu 
> # Date 1490201429 25200
> #  Wed Mar 22 09:50:29 2017 -0700
> # Node ID d604e5baed4ac2f5470860bff89728c282d71e3a
> # Parent  44c865487bfd2f081bfb322b1fb1b700d57f7adf
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> d604e5baed4a
> scmutil: extract rc.d listing function from rccomponents
> 
> This is suggested by dsop and makes the code cleaner. A side effect is
> "normpath" will be called on paths in $HGRCPATH, which seems to be more
> correct.
> 
> diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
> --- a/mercurial/scmutil.py
> +++ b/mercurial/scmutil.py
> @@ -452,4 +452,13 @@ def rcpath():
> _rccomponents = None
> 
> +def _expandrcpath(path):
> +'''path could be a file or a directory. return a list of file paths'''
> +p = util.expandpath(path)
> +join = os.path.join
> +if os.path.isdir(p):
> +return [join(p, f) for f, k in osutil.listdir(p) if 
> f.endswith('.rc')]
> +else:
> +return [p]

Nit: this `else:` line is unnecessary -- remove it and unindent the `return 
[p]`.

Also: it looks to me like you could reuse this in defaultrcpath() as well?

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 01 of 13 V3] scmutil: add a method to convert environment variables to config items

[Kevin Bullock]

> On Mar 23, 2017, at 13:27, Jun Wu  wrote:
> 
> Thanks for the detailed review and especially for raising the pattern
> issue! I think you have a very good point, and I actually prefer the less
> commits way.
> 
> I'd like to provide the reason for this particular series. The general
> question will be left for others to comment.
> 
> The reason was simple - I was involuntarily avoiding changing "ui.py" and
> "scmutil.py" together. I should have just changed them together in a single
> commit called "change rcpath return type and update its users", despite the
> OneChangePerPatch wiki [1] says "and" indicates something wrong.

I wouldn't consider "change a function's signature and update its callers" to 
be separate changes -- in fact, we often make such changes and summarize them 
simply as "change function's signature". That implies strongly enough that the 
call sites are updated too.

If there are _lots_ of call sites, then sometimes it's helpful to add a new 
function, and one by one transition call sites to use the new function. A good 
recent example of this is 279cbde7bf3d::fb1b5cd17664.

But in the case of your series, I'd suggest an order very similar to Martin's:

[01] scmutil: extract rc.d listing function from rccomponents
[02] scmutil: split osrcpath to return default.d paths (API)
[03] scmutil: rename rcpath to rccomponents (API)
[04] scmutil: implement rccomponents to return a list of [('path', 
'/path/to/hgrc'), ...], but NOT consult environment yet -- this also implies 
changing the call sites (API)
[05] run-tests: drop environment variables affecting configs
[06] scmutil: add a method to convert environment variables to config items
[07] scmutil: define a list of configs overriding system rc, but not users
[08] config: let env variables override system hgrc (BC) -- here update 
commands.py and ui.py to deal with 'items' entries (i.e., fold most of your V3 
patches 9 and 10 into this)
[09] ui: simplify geteditor
[10] pager: do not read from environment variable

> The fact that most codemods are done one-commit-per-file, and per-file
> commit message exists for a good reason [2] made me wonder if a changeset
> should just change one file. But that shouldn't be a strict rule anyway.

One logical change can definitely span more than one file. We generally go 
file-by-file only when there's a bunch of call sites. And in those cases, it 
seems to always be the right approach to introduce the new API with a new name, 
convert all the callers incrementally, and then deprecate/remove the old API.

This series is a more localized refactor, so I don't think that approach is 
called for here.

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 7 of 7 V3] hgweb: expose a followlines UI in filerevision view (RFC)

[Denis Laxalde]

Augie Fackler a écrit :

On Wed, Mar 22, 2017 at 11:37:32AM +0100, Denis Laxalde wrote:

> # HG changeset patch
> # User Denis Laxalde 
> # Date 1489594320 -3600
> #  Wed Mar 15 17:12:00 2017 +0100
> # Node ID cb742fcfe0edb2d393b59674c4eebcf8775ecfe1
> # Parent  9e3ae74c1ca558f0584067c62835bec82034c245
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r cb742fcfe0ed
> hgweb: expose a followlines UI in filerevision view (RFC)

Neat idea.


>
> In filerevision view (/file//) we add some event listeners on
> mouse selection of  elements in the  block.
> Those listeners will capture the range of mouse-selected lines and, upon mouse
> release, a box inviting to follow the history of selected lines will show up.
> This action is advertised by a :after pseudo-element on file lines that shows
> up on hover and invite to "select a block of lines to follow its history".
>
> This is proposal implementation, comments welcome on any aspects.

It's a neat idea. I think I like it...


>
> diff --git a/mercurial/templates/paper/filerevision.tmpl 
b/mercurial/templates/paper/filerevision.tmpl
> --- a/mercurial/templates/paper/filerevision.tmpl
> +++ b/mercurial/templates/paper/filerevision.tmpl
> @@ -73,6 +73,11 @@
>   line source
>  {text%fileline}
>  
> +
> +
> +installLineSelect("{url|urlescape}log/{symrev}/{file|urlescape}");
> +

I suspect you can't do this inline javascript because of our 
Content-Security-Policy support. Greg?

(Maybe the nonce makes this okay. I don't really understand modern JS yet...)



Yes, it'd be probably better if I move the JS code in a dedicated script
file.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 3] util: add a getfstype method

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490295525 25200
#  Thu Mar 23 11:58:45 2017 -0700
# Node ID 235f1212559d03f115e21992b5725a7dc7787632
# Parent  2c02bb7fd7fc1212029dc903527e35a9efb7dbe1
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 235f1212559d
util: add a getfstype method

The util version is a thin wrapper of the osutil version, which is not
always available.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -1368,4 +1368,11 @@ def fspath(name, root):
 return ''.join(result)
 
+def getfstype(dirpath):
+'''Get the filesystem type name from a directory (best-effort)
+
+Returns None if we are unsure, or errors like ENOENT, EPERM happen.
+'''
+return getattr(osutil, 'getfstype', lambda x: None)(dirpath)
+
 def checknlink(testfile):
 '''check whether hardlink count reporting works properly'''
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] debugfsinfo: use util.getfstype

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490295799 25200
#  Thu Mar 23 12:03:19 2017 -0700
# Node ID 1dbe21f38b4c3242f85e0af4772ca715a3eaab10
# Parent  bff5a7461d770ed6db75b446d518b272fe423a47
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 1dbe21f38b4c
debugfsinfo: use util.getfstype

This changes the behavior slightly. It now always prints fstype, regardless
of whether osutil.getfstype exists.

diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
--- a/mercurial/debugcommands.py
+++ b/mercurial/debugcommands.py
@@ -791,8 +791,5 @@ def debugfsinfo(ui, path="."):
 util.writefile('.debugfsinfo', '')
 ui.write(('exec: %s\n') % (util.checkexec(path) and 'yes' or 'no'))
-from . import osutil
-if util.safehasattr(osutil, 'getfstype'):
-fstype = osutil.getfstype('.')
-ui.write(('fstype: %s\n') % (fstype or '(unknown)'))
+ui.write(('fstype: %s\n') % (util.getfstype('.') or '(unknown)'))
 ui.write(('symlink: %s\n') % (util.checklink(path) and 'yes' or 'no'))
 ui.write(('hardlink: %s\n') % (util.checknlink(path) and 'yes' or 'no'))
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3] util: use util.getfstype

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1490295678 25200
#  Thu Mar 23 12:01:18 2017 -0700
# Node ID bff5a7461d770ed6db75b446d518b272fe423a47
# Parent  235f1212559d03f115e21992b5725a7dc7787632
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r bff5a7461d77
util: use util.getfstype

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -1087,6 +1087,5 @@ def copyfile(src, dest, hardlink=False, 
 # Hardlinks are problematic on CIFS (issue4546), do not allow hardlinks
 # unless we are confident that dest is on a whitelisted filesystem.
-destdir = os.path.dirname(dest)
-fstype = getattr(osutil, 'getfstype', lambda x: None)(destdir)
+fstype = getfstype(os.path.dirname(dest))
 if fstype not in _hardlinkfswhitelist:
 hardlink = False
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] debugfsinfo: print fstype information

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-03-23 23:34:41 +0900:
> On Tue, 21 Mar 2017 19:00:56 -0700, Jun Wu wrote:
> > # HG changeset patch
> > # User Jun Wu 
> > # Date 1489311257 28800
> > #  Sun Mar 12 01:34:17 2017 -0800
> > # Node ID ea4573691618ea1937cfe0c03c6caa4693b64b05
> > # Parent  e960baabf0da65e84e99466d4be9acaa4b9b91b2
> > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > #  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 
> > ea4573691618
> > debugfsinfo: print fstype information
> 
> These generally look good. Queued, thanks.
> 
> > diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
> > --- a/mercurial/debugcommands.py
> > +++ b/mercurial/debugcommands.py
> > @@ -791,4 +791,8 @@ def debugfsinfo(ui, path="."):
> >  util.writefile('.debugfsinfo', '')
> >  ui.write(('exec: %s\n') % (util.checkexec(path) and 'yes' or 'no'))
> > +from . import osutil
> 
> Is there an import cycle?

Probably no. But "from . import osutil" is also in "debuginstall" so I
assumed it's safer to not import it directly.

> 
> > +if util.safehasattr(osutil, 'getfstype'):
> > +fstype = osutil.getfstype('.')
> > +ui.write(('fstype: %s\n') % (fstype or '(unknown)'))
> 
> Let's add util.getfstype() so we don't have to test the existence of
> getfstype(). It should be okay to print '(unknown)' if unsupported.

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

Re: [PATCH 01 of 13 V3] scmutil: add a method to convert environment variables to config items

[Jun Wu]

Thanks for the detailed review and especially for raising the pattern
issue! I think you have a very good point, and I actually prefer the less
commits way.

I'd like to provide the reason for this particular series. The general
question will be left for others to comment.

The reason was simple - I was involuntarily avoiding changing "ui.py" and
"scmutil.py" together. I should have just changed them together in a single
commit called "change rcpath return type and update its users", despite the
OneChangePerPatch wiki [1] says "and" indicates something wrong.

The fact that most codemods are done one-commit-per-file, and per-file
commit message exists for a good reason [2] made me wonder if a changeset
should just change one file. But that shouldn't be a strict rule anyway.

At the point, I wonder if we can change the rule a little bit so we could
prefer to do codemod in a single commit. The usual benefit of small patch -
"reviewability, selectability, and bisectability" seem less effective for
repetitive changes. It also seems helpful to reduce overhead of reviewing
and tooling, and the code history seems cleaner, with a better density of
information.

[1]: https://www.mercurial-scm.org/wiki/OneChangePerPatch
[2]: https://news.ycombinator.com/item?id=11670080

Excerpts from Martin von Zweigbergk's message of 2017-03-22 22:28:37 -0700:
> On Wed, Mar 22, 2017 at 10:23 AM, Jun Wu  wrote:
> > # HG changeset patch
> > # User Jun Wu 
> > # Date 1489449998 25200
> > #  Mon Mar 13 17:06:38 2017 -0700
> > # Node ID 04259bd73d263306f16e25bd4e6bc53faf80911c
> > # Parent  55c6788c54e2faf80ec14f2b0844bfe429012bc3
> > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > #  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 
> > 04259bd73d26
> > scmutil: add a method to convert environment variables to config items
> 
> First of all, thanks for working on this!
> 
> I just have a comment on the structure of of this series for now. This
> is the current structure:
> 
> [01] scmutil: add a method to convert environment variables to config items
> [02] scmutil: define a list of configs overriding system rc, but not users
> [03] scmutil: split osrcpath to return default.d paths (API)
> [04] scmutil: copy rcpath to rcpath2
> [05] scmutil: use _rccomponents in rcpath2
> [06] scmutil: implement rccomponents to return multiple config sources
> [07] scmutil: extract rc.d listing function from rccomponents
> [08] run-tests: drop environment variables affecting configs
> [09] ui: use scmutil.rccomponents to load configs (BC)
> [10] config: list environment variables in debug output
> [11] scmutil: remove rcpath (API)
> [12] ui: simplify geteditor
> [13] pager: do not read from environment variable
> 
> Patches 1,2,4,5,6,7 all introduce and/or update dead code (AFAICT).
> The dead code becomes live only in patch 9. This is a common pattern
> on this list, so I may very well be a minority in disliking it, but I
> do really dislike it. When reviewing the patches, I end up looking at
> the description, then I ignore the content and go to the next patch,
> because I don't yet know how the added code will be used. And since
> there are no tests exercising it, it doesn't really matter if it's
> working or not anyway, so it's safe to ignore it. Then, when I get to
> patch that hooks things up (patch 9 in this case), I have to try to
> recall the commit messages of all the previous patches to understand
> what all the things that changed were. Again, the structure you follow
> is common on this list, so maybe most people don't have the problem I
> have with it (and also, I don't mean to pick on you; this series was
> just an example).
> 
> I would really have preferred something like this (and since I haven't
> followed all the changes in the patches, it may very well not work as
> I think it would):
> 
> [01] scmutil: extract rc.d listing function from rccomponents
> [02] scmutil: split osrcpath to return default.d paths (API)
> [03] scmutil: rename rcpath to rccomponents (API)
> [04] scmutil: implement rccomponents to return multiple config sources
> [05] run-tests: drop environment variables affecting configs
> [06] config: let env variables override system hgrc (BC)
> [07] config: list environment variables in debug output
> [08] ui: simplify geteditor
> [09] pager: do not read from environment variable
> 
> Patch 6 above would be a fold of your patches 1,2, and 9, so it would
> be a larger patch to review. However, as I tried to explain above,
> that's effectively what I review at that point anyway, and having it
> all in one patch makes it much easier for me as a reviewer.
> 
> I'm sure there there are things I missed that make the above not quite
> possible, but hopefully it's close enough to possible that you at
> least get the idea. And then you get to decide what to do with the
> idea, of course :-) Perhaps you decide that it's a bad idea. Or
> perhaps you decide it has some 

Re: [PATCH] help: correct title undescore length

[Martin von Zweigbergk via Mercurial-devel]

Heh, this is the third patch that does the same (previous ones from Kostia
and me).

On Mar 23, 2017 10:55, "David Soria Parra"  wrote:

> # HG changeset patch
> # User David Soria Parra 
> # Date 1490290521 -3600
> #  Thu Mar 23 18:35:21 2017 +0100
> # Node ID a58314d8ab7f4cd910c238441779731ad16372d6
> # Parent  55c6788c54e2faf80ec14f2b0844bfe429012bc3
> help: correct title undescore length
>
> The underscores for a title must have the same lenght as the title,
> otherwise gendoc will throw an error. This leads to `make install` fail.
>
> diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
> --- a/mercurial/help/config.txt
> +++ b/mercurial/help/config.txt
> @@ -415,7 +415,7 @@
>  extension).
>
>  ``commands``
> ---
> +
>
>  ``update.requiredest``
>  Require that the user pass a destination when running ``hg update``.
> ___
> 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

[PATCH] help: correct title undescore length

[David Soria Parra]

# HG changeset patch
# User David Soria Parra 
# Date 1490290521 -3600
#  Thu Mar 23 18:35:21 2017 +0100
# Node ID a58314d8ab7f4cd910c238441779731ad16372d6
# Parent  55c6788c54e2faf80ec14f2b0844bfe429012bc3
help: correct title undescore length

The underscores for a title must have the same lenght as the title,
otherwise gendoc will throw an error. This leads to `make install` fail.

diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
--- a/mercurial/help/config.txt
+++ b/mercurial/help/config.txt
@@ -415,7 +415,7 @@
 extension).
 
 ``commands``
---
+
 
 ``update.requiredest``
 Require that the user pass a destination when running ``hg update``.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@31578: 5 new changesets

[Mercurial Commits]

5 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/a8e55d6f1d67
changeset:   31574:a8e55d6f1d67
user:Augie Fackler 
date:Tue Mar 21 17:39:49 2017 -0400
summary: revlog: use pycompat.maplist to eagerly evaluate map on Python 3

https://www.mercurial-scm.org/repo/hg/rev/e506e461c7a9
changeset:   31575:e506e461c7a9
user:Jun Wu 
date:Sun Mar 12 00:23:07 2017 -0800
summary: util: disable hardlink for copyfile if fstype is outside a 
whitelist

https://www.mercurial-scm.org/repo/hg/rev/07f0cddb0594
changeset:   31576:07f0cddb0594
user:Jun Wu 
date:Sun Mar 12 00:26:20 2017 -0800
summary: hghave: add a check about whitelisted filesystem that supports 
hardlink

https://www.mercurial-scm.org/repo/hg/rev/e7a02e9ad162
changeset:   31577:e7a02e9ad162
user:Jun Wu 
date:Sun Mar 12 01:03:23 2017 -0800
summary: util: enable hardlink for copyfile

https://www.mercurial-scm.org/repo/hg/rev/6262e30b0c09
changeset:   31578:6262e30b0c09
bookmark:@
tag: tip
user:Jun Wu 
date:Sun Mar 12 01:34:17 2017 -0800
summary: debugfsinfo: print fstype information

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

Re: [PATCH 07 of 13 V3] scmutil: extract rc.d listing function from rccomponents

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-03-22 22:32:53 -0700:
> On Wed, Mar 22, 2017 at 10:23 AM, Jun Wu  wrote:
> > # HG changeset patch
> > # User Jun Wu 
> > # Date 1490201429 25200
> > #  Wed Mar 22 09:50:29 2017 -0700
> > # Node ID d604e5baed4ac2f5470860bff89728c282d71e3a
> > # Parent  44c865487bfd2f081bfb322b1fb1b700d57f7adf
> > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > #  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 
> > d604e5baed4a
> > scmutil: extract rc.d listing function from rccomponents
> >
> > This is suggested by dsop and makes the code cleaner. A side effect is
> > "normpath" will be called on paths in $HGRCPATH, which seems to be more
> > correct.
> 
> Is that last part still true? It looks like pathize() is called on all
> paths even in the preimage, and I believe pathize() calls normpath().
> I'm thinking that maybe the commit message is outdated.

Good catch. Sorry, I didn't realize the code change changes the behavior.

> >
> > diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
> > --- a/mercurial/scmutil.py
> > +++ b/mercurial/scmutil.py
> > @@ -452,4 +452,13 @@ def rcpath():
> >  _rccomponents = None
> >
> > +def _expandrcpath(path):
> > +'''path could be a file or a directory. return a list of file paths'''
> > +p = util.expandpath(path)
> > +join = os.path.join
> > +if os.path.isdir(p):
> > +return [join(p, f) for f, k in osutil.listdir(p) if 
> > f.endswith('.rc')]
> > +else:
> > +return [p]
> > +
> >  def rccomponents():
> >  '''return an ordered [(type, obj)] about where to load configs.
> > @@ -478,11 +487,5 @@ def rccomponents():
> >  if not p:
> >  continue
> > -p = util.expandpath(p)
> > -if os.path.isdir(p):
> > -for f, kind in osutil.listdir(p):
> > -if f.endswith('.rc'):
> > -_rccomponents.append(pathize(os.path.join(p, 
> > f)))
> > -else:
> > -_rccomponents.append(pathize(p))
> > +_rccomponents.extend(map(pathize, _expandrcpath(p)))
> >  else:
> >  _rccomponents = map(pathize, defaultrcpath() + systemrcpath())
> > ___
> > 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 1 of 7 V3] hgweb: drop "parity" from webutil.diffs arguments

[Denis Laxalde]

Augie Fackler a écrit :

On Wed, Mar 22, 2017 at 11:37:26AM +0100, Denis Laxalde wrote:

# HG changeset patch
# User Denis Laxalde 
# Date 1489398019 -3600
#  Mon Mar 13 10:40:19 2017 +0100
# Node ID 2620dc84c013ab9d60d9327aa33435936bd25a01
# Parent  527a247f114f8af37326805fd6cce923f9ac6453
# Available At http://hg.logilab.org/users/dlaxalde/hg
#  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 2620dc84c013
# EXP-Topic linerange-log/hgweb-filelog
hgweb: drop "parity" from webutil.diffs arguments

From mercurial/templates/spartan/map:
diffblock = '{lines}'

So I don't think this is unused?



You're right. I will change this in a V4 so that "parity" is computed
inside the function.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 7 V3] hgweb: add a "patch" query parameter to filelog command

[Augie Fackler]

On Thu, Mar 23, 2017 at 11:51 AM, Augie Fackler  wrote:
>> # EXP-Topic linerange-log/hgweb-filelog
>> hgweb: add a "patch" query parameter to filelog command
>
> I've taken this one, thanks.


Discarded it since it depends on patch 1 and I didn't notice. Sorry. :/
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 7 of 7 V3] hgweb: expose a followlines UI in filerevision view (RFC)

[Augie Fackler]

On Wed, Mar 22, 2017 at 11:37:32AM +0100, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1489594320 -3600
> #  Wed Mar 15 17:12:00 2017 +0100
> # Node ID cb742fcfe0edb2d393b59674c4eebcf8775ecfe1
> # Parent  9e3ae74c1ca558f0584067c62835bec82034c245
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r cb742fcfe0ed
> hgweb: expose a followlines UI in filerevision view (RFC)

Neat idea.

>
> In filerevision view (/file//) we add some event listeners on
> mouse selection of  elements in the  block.
> Those listeners will capture the range of mouse-selected lines and, upon mouse
> release, a box inviting to follow the history of selected lines will show up.
> This action is advertised by a :after pseudo-element on file lines that shows
> up on hover and invite to "select a block of lines to follow its history".
>
> This is proposal implementation, comments welcome on any aspects.

It's a neat idea. I think I like it...

>
> diff --git a/mercurial/templates/paper/filerevision.tmpl 
> b/mercurial/templates/paper/filerevision.tmpl
> --- a/mercurial/templates/paper/filerevision.tmpl
> +++ b/mercurial/templates/paper/filerevision.tmpl
> @@ -73,6 +73,11 @@
>   line source
>  {text%fileline}
>  
> +
> +
> +installLineSelect("{url|urlescape}log/{symrev}/{file|urlescape}");
> +

I suspect you can't do this inline javascript because of our 
Content-Security-Policy support. Greg?

(Maybe the nonce makes this okay. I don't really understand modern JS yet...)

> +
>  
>  
>
> diff --git a/mercurial/templates/static/mercurial.js 
> b/mercurial/templates/static/mercurial.js
> --- a/mercurial/templates/static/mercurial.js
> +++ b/mercurial/templates/static/mercurial.js
> @@ -434,6 +434,81 @@ function ajaxScrollInit(urlFormat,
>  scrollHandler();
>  }
>
> +//** install mouse event listeners on  */
> +function installLineSelect(targetUri) {
> +var sourcelines = document.getElementsByClassName('sourcelines')[0];
> +if (typeof sourcelines === 'undefined') {
> +return;
> +}
> +// add event listener to the whole  block to 
> have
> +// it available in all children 
> +sourcelines.addEventListener('mousedown', lineSelectStart);
> +
> +//** event handler for "mousedown" */
> +function lineSelectStart(e) {
> +var startElement = e.target;
> +if (startElement.tagName !== 'SPAN') {
> +// we may be on a 
> +return;
> +}
> +// retarget "mouseup" to sourcelines element so that if this event
> +// occurs outside the  we don't miss it
> +sourcelines.setCapture();
> +// drop any prior 
> +var previousInvite = document.getElementById('followlines');
> +if (previousInvite !== null) {
> +previousInvite.parentNode.removeChild(previousInvite);
> +}
> +
> +var startId = parseInt(startElement.id.slice(1));
> +
> +//** event handler for "mouseup" */
> +function lineSelectEnd(e) {
> +// remove "mouseup" listener
> +sourcelines.removeEventListener('mouseup', lineSelectEnd);
> +
> +var endElement = e.target;
> +if (endElement.tagName !== 'SPAN') {
> +// not on , probably outside ,
> +// we cannot compute endId
> +return;
> +}
> +
> +// compute line range (startId, endId) and insert the
> +// "followlines" element
> +var endId = parseInt(endElement.id.slice(1));
> +if (endId == startId) {
> +return;
> +}
> +var inviteElement = endElement;
> +if (endId < startId) {
> +var tmp = endId;
> +endId = startId;
> +startId = tmp;
> +inviteElement = startElement;
> +}
> +var div = followlinesBox(startId, endId);
> +inviteElement.appendChild(div);
> +}
> +
> +sourcelines.addEventListener('mouseup', lineSelectEnd);
> +
> +}
> +
> +//** return a  with a link for followlines action 
> */
> +function followlinesBox(startId, endId) {
> +var div = document.createElement('div');
> +div.id = 'followlines';
> +var a = document.createElement('a');
> +var url = targetUri + '?patch==' + startId + ':' + endId;
> +a.setAttribute('href', url);
> +a.textContent = 'follow lines ' + startId + ':' + endId;
> +div.appendChild(a);
> +return div;
> +}
> +
> +}
> +
>  document.addEventListener('DOMContentLoaded', function() {
> process_dates();
>  }, false);
> diff --git a/mercurial/templates/static/style-paper.css 
> b/mercurial/templates/static/style-paper.css
> --- a/mercurial/templates/static/style-paper.css
> +++ b/mercurial/templates/static/style-paper.css
> @@ -276,10 

Re: [PATCH 1 of 7 V3] hgweb: drop "parity" from webutil.diffs arguments

[Augie Fackler]

On Wed, Mar 22, 2017 at 11:37:26AM +0100, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1489398019 -3600
> #  Mon Mar 13 10:40:19 2017 +0100
> # Node ID 2620dc84c013ab9d60d9327aa33435936bd25a01
> # Parent  527a247f114f8af37326805fd6cce923f9ac6453
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 2620dc84c013
> # EXP-Topic linerange-log/hgweb-filelog
> hgweb: drop "parity" from webutil.diffs arguments

From mercurial/templates/spartan/map:
diffblock = '{lines}'

So I don't think this is unused?

>
> This function yields "diffblock" templates which do not make use of "parity".
> In fact, maybe this template *should* make use of parity stripes as it would
> make /rev views more readable with the diff involves several files?
>
> diff --git a/mercurial/hgweb/webcommands.py b/mercurial/hgweb/webcommands.py
> --- a/mercurial/hgweb/webcommands.py
> +++ b/mercurial/hgweb/webcommands.py
> @@ -756,12 +756,11 @@ def filediff(web, req, tmpl):
>  ctx = fctx.changectx()
>  basectx = ctx.p1()
>
> -parity = paritygen(web.stripecount)
>  style = web.config('web', 'style', 'paper')
>  if 'style' in req.form:
>  style = req.form['style'][0]
>
> -diffs = webutil.diffs(web.repo, tmpl, ctx, basectx, [path], parity, 
> style)
> +diffs = webutil.diffs(web.repo, tmpl, ctx, basectx, [path], style)
>  if fctx is not None:
>  rename = webutil.renamelink(fctx)
>  ctx = fctx
> diff --git a/mercurial/hgweb/webutil.py b/mercurial/hgweb/webutil.py
> --- a/mercurial/hgweb/webutil.py
> +++ b/mercurial/hgweb/webutil.py
> @@ -388,8 +388,7 @@ def changesetentry(web, req, tmpl, ctx):
>  if 'style' in req.form:
>  style = req.form['style'][0]
>
> -parity = paritygen(web.stripecount)
> -diff = diffs(web.repo, tmpl, ctx, basectx, None, parity, style)
> +diff = diffs(web.repo, tmpl, ctx, basectx, None, style)
>
>  parity = paritygen(web.stripecount)
>  diffstatsgen = diffstatgen(ctx, basectx)
> @@ -414,7 +413,7 @@ def listfilediffs(tmpl, files, node, max
>  if len(files) > max:
>  yield tmpl('fileellipses')
>
> -def diffs(repo, tmpl, ctx, basectx, files, parity, style):
> +def diffs(repo, tmpl, ctx, basectx, files, style):
>
>  def prettyprintlines(lines, blockno):
>  for lineno, l in enumerate(lines, 1):
> @@ -450,7 +449,7 @@ def diffs(repo, tmpl, ctx, basectx, file
>  for hunkrange, hunklines in hunks:
>  lines.extend(hunklines)
>  if lines:
> -yield tmpl('diffblock', parity=next(parity), blockno=blockno,
> +yield tmpl('diffblock', blockno=blockno,
> lines=prettyprintlines(lines, blockno))
>
>  def compare(tmpl, context, leftlines, rightlines):
> ___
> 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 2 of 2 V2] status: support commands.status.relative config

[Augie Fackler]

On Thu, Mar 23, 2017 at 09:49:35AM +, Ryan McElroy wrote:
> On 3/22/17 4:25 PM, Martin von Zweigbergk via Mercurial-devel wrote:
> ># HG changeset patch
> ># User Martin von Zweigbergk 
> ># Date 1490143844 25200
> >#  Tue Mar 21 17:50:44 2017 -0700
> ># Node ID 32fb4dfa78cb43ac9d6b42dcd9e8735bf02cefe4
> ># Parent  1ed5ec882c49934a16428fc72e7a366f39747cc5
> >status: support commands.status.relative config
>
> This series looks good to me.

Agreed, queued.

>
> >
> >When the config is set to true, status output becomes relative to the
> >working directory. This has bugged me since I started using hg and it
> >turns it is sillily simple to support it (unless I missed something,
> >of course).
> >
> >We could also add a --relative flag, but I would personally always
> >want that on, and I haven't heard any use for having it sometimes on,
> >so this patch only lets you enable it via config.
> >
> >diff -r 1ed5ec882c49 -r 32fb4dfa78cb mercurial/commands.py
> >--- a/mercurial/commands.py  Tue Mar 21 21:26:52 2017 -0700
> >+++ b/mercurial/commands.py  Tue Mar 21 17:50:44 2017 -0700
> >@@ -4734,7 +4734,7 @@
> >  else:
> >  node1, node2 = scmutil.revpair(repo, revs)
> >-if pats:
> >+if pats or ui.configbool('commands', 'status.relative'):
> >  cwd = repo.getcwd()
> >  else:
> >  cwd = ''
> >diff -r 1ed5ec882c49 -r 32fb4dfa78cb mercurial/help/config.txt
> >--- a/mercurial/help/config.txt  Tue Mar 21 21:26:52 2017 -0700
> >+++ b/mercurial/help/config.txt  Tue Mar 21 17:50:44 2017 -0700
> >@@ -417,6 +417,10 @@
> >  ``commands``
> >  --
> >+``status.relative``
> >+Make paths in ``hg status`` output relative to the current directory.
> >+(default: False)
> >+
> >  ``update.requiredest``
> >  Require that the user pass a destination when running ``hg update``.
> >  For example, ``hg update .::`` will be allowed, but a plain ``hg 
> > update``
> >diff -r 1ed5ec882c49 -r 32fb4dfa78cb tests/test-status.t
> >--- a/tests/test-status.tTue Mar 21 21:26:52 2017 -0700
> >+++ b/tests/test-status.tTue Mar 21 17:50:44 2017 -0700
> >@@ -107,6 +107,27 @@
> >? a/in_a
> >? b/in_b
> >+relative paths can be requested
> >+
> >+  $ cat >> $HGRCPATH < >+  > [commands]
> >+  > status.relative = True
> >+  > EOF
> >+  $ hg status --cwd a
> >+  ? 1/in_a_1
> >+  ? in_a
> >+  ? ../b/1/in_b_1
> >+  ? ../b/2/in_b_2
> >+  ? ../b/in_b
> >+  ? ../in_root
> >+  $ HGPLAIN=1 hg status --cwd a
> >+  ? a/1/in_a_1
> >+  ? a/in_a
> >+  ? b/1/in_b_1
> >+  ? b/2/in_b_2
> >+  ? b/in_b
> >+  ? in_root
> >+
> >$ cd ..
> >$ hg init repo2
> >
>
> ___
> 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] fancyopts: making config defaults actually override defaults

[Augie Fackler]

On Wed, Mar 22, 2017 at 11:51:30AM -0700, Martin von Zweigbergk via 
Mercurial-devel wrote:
> On Wed, Mar 22, 2017 at 10:14 AM, Rodrigo Damazio  wrote:
> > On Wed, Mar 22, 2017 at 3:50 AM, Ryan McElroy  wrote:
> >>
> >> Rodrigo: for some reason, patchwork thinks you are Martin. Any idea why?
> >> https://patchwork.mercurial-scm.org/patch/19133/
> >
> > No idea, but I'm using a script he created for mailing patches directly to
> > gmail's backend servers (to avoid reformatting) - Martin, any chance you
> > hardcoded your own address there? :)
>
> Nope. IIUC, patchwork has decided to associate any email from
> mercurial-devel@mercurial-scm.org with me, because it probably first
> received one from there from me. And the reason it is from
> mercurial-devel@mercurial-scm.org in the first place is because we
> (Google) set the DMARC/SPF/whatever headers to prevent spoofing of
> @google.com addresses, so the mailing list has no choice but to
> rewrite it as coming from the mailing list itself. I may very well
> have misunderstood how that works, but hopefully you get the idea
> anyway.

This matches my understanding of the collective mail transfer damage here, FWIW.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] tests: make test-simplekeyvaluefile.py py2.6-compatible

[Augie Fackler]

On Thu, Mar 23, 2017 at 03:25:59AM -0700, Kostia Balytskyi wrote:
> # HG changeset patch
> # User Kostia Balytskyi 
> # Date 1490207183 25200
> #  Wed Mar 22 11:26:23 2017 -0700
> # Node ID 5d11feaf6bf6dc0a15d5fa3ac34fe48fd31233e6
> # Parent  55c6788c54e2faf80ec14f2b0844bfe429012bc3
> tests: make test-simplekeyvaluefile.py py2.6-compatible

Queued, thanks.

>
> Python 2.6 unittest.TestCase does not have assertRaisesRegexp.

Python 2.6 delenda est.

>
> diff --git a/tests/test-simplekeyvaluefile.py 
> b/tests/test-simplekeyvaluefile.py
> --- a/tests/test-simplekeyvaluefile.py
> +++ b/tests/test-simplekeyvaluefile.py
> @@ -50,23 +50,24 @@ class testsimplekeyvaluefile(unittest.Te
>
>  def testinvalidkeys(self):
>  d = {'0key1': 'value1', 'Key2': 'value2'}
> -with self.assertRaisesRegexp(error.ProgrammingError,
> - "keys must start with a letter.*"):
> -scmutil.simplekeyvaluefile(self.vfs, 'kvfile').write(d)
> +self.assertRaises(error.ProgrammingError,
> +  scmutil.simplekeyvaluefile(self.vfs, 
> 'kvfile').write,
> +  d)
>  d = {'key1@': 'value1', 'Key2': 'value2'}
> -with self.assertRaisesRegexp(error.ProgrammingError, "invalid 
> key.*"):
> -scmutil.simplekeyvaluefile(self.vfs, 'kvfile').write(d)
> +self.assertRaises(error.ProgrammingError,
> +  scmutil.simplekeyvaluefile(self.vfs, 
> 'kvfile').write,
> +  d)
>
>  def testinvalidvalues(self):
>  d = {'key1': 'value1', 'Key2': 'value2\n'}
> -with self.assertRaisesRegexp(error.ProgrammingError, "invalid 
> val.*"):
> -scmutil.simplekeyvaluefile(self.vfs, 'kvfile').write(d)
> +self.assertRaises(error.ProgrammingError,
> +  scmutil.simplekeyvaluefile(self.vfs, 
> 'kvfile').write,
> +  d)
>
>  def testcorruptedfile(self):
>  self.vfs.contents['badfile'] = 'ababagalamaga\n'
> -with self.assertRaisesRegexp(error.CorruptedState,
> - "dictionary.*element.*"):
> -scmutil.simplekeyvaluefile(self.vfs, 'badfile').read()
> +self.assertRaises(error.CorruptedState,
> +  scmutil.simplekeyvaluefile(self.vfs, 
> 'badfile').read)
>
>  if __name__ == "__main__":
>  silenttestrunner.main(__name__)
> ___
> 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 6 of 6 V2] similar: use cheaper hash() function to test exact matches

[Augie Fackler]

On Thu, Mar 23, 2017 at 11:13:48PM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1490270247 -32400
> #  Thu Mar 23 20:57:27 2017 +0900
> # Node ID 5954caab67d569bc680339175b4a12b400b9ad12
> # Parent  d628846ce8182338b112820860b3c7fe4dcbc33d
> similar: use cheaper hash() function to test exact matches

Queued these, thanks.

>
> We just need a hash table {fctx.data(): fctx} which doesn't keep fctx.data()
> in memory. Let's simply use hash(fctx.data()) to put data out from memory,
> and manage collided fctx objects by list.
>
> This isn't significantly faster than using sha1, but is more correct as we
> know SHA-1 collision attack is getting practical.
>
> Benchmark with 50k added/removed files, on tmpfs:
>
>   $ hg addremove --dry-run --time -q
>
>   previous:   real 12.420 secs (user 11.120+0.000 sys 1.280+0.000)
>   this patch: real 12.350 secs (user 11.210+0.000 sys 1.140+0.000)
>
> diff --git a/mercurial/similar.py b/mercurial/similar.py
> --- a/mercurial/similar.py
> +++ b/mercurial/similar.py
> @@ -7,8 +7,6 @@
>
>  from __future__ import absolute_import
>
> -import hashlib
> -
>  from .i18n import _
>  from . import (
>  bdiff,
> @@ -23,25 +21,29 @@ def _findexactmatches(repo, added, remov
>  '''
>  numfiles = len(added) + len(removed)
>
> -# Get hashes of removed files.
> +# Build table of removed files: {hash(fctx.data()): [fctx, ...]}.
> +# We use hash() to discard fctx.data() from memory.
>  hashes = {}
> -for i, fctx in enumerate(reversed(removed)):
> +for i, fctx in enumerate(removed):
>  repo.ui.progress(_('searching for exact renames'), i, total=numfiles,
>   unit=_('files'))
> -h = hashlib.sha1(fctx.data()).digest()
> -hashes[h] = fctx
> +h = hash(fctx.data())
> +if h not in hashes:
> +hashes[h] = [fctx]
> +else:
> +hashes[h].append(fctx)
>
>  # For each added file, see if it corresponds to a removed file.
>  for i, fctx in enumerate(added):
>  repo.ui.progress(_('searching for exact renames'), i + len(removed),
>  total=numfiles, unit=_('files'))
>  adata = fctx.data()
> -h = hashlib.sha1(adata).digest()
> -if h in hashes:
> -rfctx = hashes[h]
> +h = hash(adata)
> +for rfctx in hashes.get(h, []):
>  # compare between actual file contents for exact identity
>  if adata == rfctx.data():
>  yield (rfctx, fctx)
> +break
>
>  # Done
>  repo.ui.progress(_('searching for exact renames'), None)
> ___
> 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

[PATCH 6 of 6 py3 v2] py3: prove `hg {add,addremove,commit} all work

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1489902476 14400
#  Sun Mar 19 01:47:56 2017 -0400
# Node ID 980459b9d372315478b5657c3a4271b903736f6f
# Parent  2190115dab97a551cd5aac44a8a55e2df9fd6307
py3: prove `hg {add,addremove,commit} all work

We can't do a second commit in a repo yet, because pure-Python bdiff
is broken on Python 3. That is probably a good next step.

diff --git a/tests/test-check-py3-commands.t b/tests/test-check-py3-commands.t
--- a/tests/test-check-py3-commands.t
+++ b/tests/test-check-py3-commands.t
@@ -122,4 +122,44 @@ Test bytes-ness of policy.policy with HG
 
 `hg init` can create empty repos
 
-  $ $PYTHON3 `which hg` init emptyrepo
+  $ $PYTHON3 `which hg` init py3repo
+  $ cd py3repo
+  $ echo "This is the file 'iota'." > iota
+  $ $PYTHON3 $HGBIN status
+  ? iota
+  $ $PYTHON3 $HGBIN add iota
+  $ $PYTHON3 $HGBIN status
+  A iota
+  $ $PYTHON3 $HGBIN commit --message 'commit performed in Python 3'
+  $ $PYTHON3 $HGBIN status
+
+TODO: bdiff is broken on Python 3 so we can't do a second commit yet,
+when that works remove this rollback command.
+  $ hg rollback
+  repository tip rolled back to revision -1 (undo commit)
+  working directory now based on revision -1
+
+  $ mkdir A
+  $ echo "This is the file 'mu'." > A/mu
+  $ $PYTHON3 $HGBIN addremove
+  adding A/mu
+  $ $PYTHON3 $HGBIN status
+  A A/mu
+  A iota
+  $ HGEDITOR='echo message > ' $PYTHON3 $HGBIN commit
+  $ $PYTHON3 $HGBIN status
+
+Prove the repo is valid using the Python 2 `hg`:
+  $ hg verify
+  checking changesets
+  checking manifests
+  crosschecking files in changesets and manifests
+  checking files
+  2 files, 1 changesets, 2 total revisions
+  $ hg log
+  changeset:   0:e825505ba339
+  tag: tip
+  user:test
+  date:Thu Jan 01 00:00:00 1970 +
+  summary: message
+  
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] debugfsinfo: print fstype information

[Augie Fackler]

On Thu, Mar 23, 2017 at 11:34:41PM +0900, Yuya Nishihara wrote:
> On Tue, 21 Mar 2017 19:00:56 -0700, Jun Wu wrote:
> > # HG changeset patch
> > # User Jun Wu 
> > # Date 1489311257 28800
> > #  Sun Mar 12 01:34:17 2017 -0800
> > # Node ID ea4573691618ea1937cfe0c03c6caa4693b64b05
> > # Parent  e960baabf0da65e84e99466d4be9acaa4b9b91b2
> > # Available At https://bitbucket.org/quark-zju/hg-draft
> > #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> > ea4573691618
> > debugfsinfo: print fstype information
>
> These generally look good. Queued, thanks.

+1. Many thanks to Jun for sticking with this long enough to find the
safe solution. :)

>
> > diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
> > --- a/mercurial/debugcommands.py
> > +++ b/mercurial/debugcommands.py
> > @@ -791,4 +791,8 @@ def debugfsinfo(ui, path="."):
> >  util.writefile('.debugfsinfo', '')
> >  ui.write(('exec: %s\n') % (util.checkexec(path) and 'yes' or 'no'))
> > +from . import osutil
>
> Is there an import cycle?
>
> > +if util.safehasattr(osutil, 'getfstype'):
> > +fstype = osutil.getfstype('.')
> > +ui.write(('fstype: %s\n') % (fstype or '(unknown)'))
>
> Let's add util.getfstype() so we don't have to test the existence of
> getfstype(). It should be okay to print '(unknown)' if unsupported.
> ___
> 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

[PATCH 5 of 6 py3 v2] revsetlang: perform quoting using ui.escapestr instead of repr()

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1490280410 14400
#  Thu Mar 23 10:46:50 2017 -0400
# Node ID 2190115dab97a551cd5aac44a8a55e2df9fd6307
# Parent  6158a45eb9f22ee651f2677b420665788fcc72e2
revsetlang: perform quoting using ui.escapestr instead of repr()

This changes one of the doctest results, but I'm pretty sure on
inspection that it's an equivalent result.

diff --git a/mercurial/revsetlang.py b/mercurial/revsetlang.py
--- a/mercurial/revsetlang.py
+++ b/mercurial/revsetlang.py
@@ -15,6 +15,7 @@ from . import (
 node,
 parser,
 pycompat,
+util,
 )
 
 elements = {
@@ -581,11 +582,11 @@ def _quote(s):
 >>> _quote("asdf'\"")
 '\'asdf\\\'"\''
 >>> _quote('asdf\'')
-'"asdf\'"'
+"'asdf\\''"
 >>> _quote(1)
 "'1'"
 """
-return repr(str(s))
+return "'%s'" % util.escapestr('%s' % s)
 
 def formatspec(expr, *args):
 '''
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 4 of 6 py3 v2] revsetlang: add docstring with some tests to _quote

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1490280094 14400
#  Thu Mar 23 10:41:34 2017 -0400
# Node ID 6158a45eb9f22ee651f2677b420665788fcc72e2
# Parent  e0077b4e92e0d4d22afc6343c9c2182bc2912916
revsetlang: add docstring with some tests to _quote

diff --git a/mercurial/revsetlang.py b/mercurial/revsetlang.py
--- a/mercurial/revsetlang.py
+++ b/mercurial/revsetlang.py
@@ -574,6 +574,17 @@ def parse(spec, lookup=None):
 return _parsewith(spec, lookup=lookup)
 
 def _quote(s):
+r"""Quote a value in order to make it safe for the revset engine.
+
+>>> _quote('asdf')
+"'asdf'"
+>>> _quote("asdf'\"")
+'\'asdf\\\'"\''
+>>> _quote('asdf\'')
+'"asdf\'"'
+>>> _quote(1)
+"'1'"
+"""
 return repr(str(s))
 
 def formatspec(expr, *args):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 6 py3 v2] similar: sort workingfilectx instances by .path()

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1490280492 14400
#  Thu Mar 23 10:48:12 2017 -0400
# Node ID 1f45b1946c0cb34f84f93f8a4931ab5ea5114b1a
# Parent  66c3ae6d886cae0e3a3cff6a0058e2d2a866fd9d
similar: sort workingfilectx instances by .path()

We'd have to define rich comparison operators for workingfilectx in
Python 3, but in this case we can just get away with sorting the
filenames. Since we're cleaning this up anyway, also avoid sorting the
both sets twice. We still sort addedfiles twice because we mutate it
in the exact-matches block, and removals from a set are cheaper than
removals from a sorted list.

Note that the code works if we don't sort the set before passing it
along to the other functions, but the result can be unpredictable
depending on the set iteration order, which we'd like to avoid.

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -106,14 +106,17 @@ def findrenames(repo, added, removed, th
 removedfiles = set([parentctx[fp] for fp in removed
 if fp in parentctx and parentctx[fp].size() > 0])
 
+pathsorted = lambda s: sorted(s, key=lambda x: x.path())
+sremovedfiles = pathsorted(removedfiles)
+
 # Find exact matches.
 for (a, b) in _findexactmatches(repo,
-sorted(addedfiles), sorted(removedfiles)):
+pathsorted(addedfiles), sremovedfiles):
 addedfiles.remove(b)
 yield (a.path(), b.path(), 1.0)
 
 # If the user requested similar files to be matched, search for them also.
 if threshold < 1.0:
 for (a, b, score) in _findsimilarmatches(repo,
-sorted(addedfiles), sorted(removedfiles), threshold):
+pathsorted(addedfiles), sremovedfiles, threshold):
 yield (a.path(), b.path(), score)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 6 py3 v2] revsetlang: portably bytestring-ify another pair of int() calls

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1490279600 14400
#  Thu Mar 23 10:33:20 2017 -0400
# Node ID 28e859b6032c8c5c1b3186a5356f0e344575eb6b
# Parent  1f45b1946c0cb34f84f93f8a4931ab5ea5114b1a
revsetlang: portably bytestring-ify another pair of int() calls

diff --git a/mercurial/revsetlang.py b/mercurial/revsetlang.py
--- a/mercurial/revsetlang.py
+++ b/mercurial/revsetlang.py
@@ -611,7 +611,7 @@ def formatspec(expr, *args):
 
 def argtype(c, arg):
 if c == 'd':
-return str(int(arg))
+return '%d' % int(arg)
 elif c == 's':
 return quote(arg)
 elif c == 'r':
@@ -629,7 +629,7 @@ def formatspec(expr, *args):
 elif l == 1:
 return argtype(t, s[0])
 elif t == 'd':
-return "_intlist('%s')" % "\0".join(str(int(a)) for a in s)
+return "_intlist('%s')" % "\0".join('%d' % int(a) for a in s)
 elif t == 's':
 return "_list('%s')" % "\0".join(s)
 elif t == 'n':
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 4 V2] util: enable hardlink for copyfile

[Yuya Nishihara]

On Tue, 21 Mar 2017 19:00:55 -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1489309403 28800
> #  Sun Mar 12 01:03:23 2017 -0800
> # Node ID e960baabf0da65e84e99466d4be9acaa4b9b91b2
> # Parent  fef923fbdbaece1d3ea237f96088e5086ee6367c
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> e960baabf0da
> util: enable hardlink for copyfile

> diff --git a/tests/test-hardlinks.t b/tests/test-hardlinks-whitelisted.t
> copy from tests/test-hardlinks.t
> copy to tests/test-hardlinks-whitelisted.t

test-check-commit.t complains about double empty line, but that's probably
because of the copy source, test-hardlinks.t. So I've pushed this with no
modification.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 8 py3] dispatch: consolidate formatting of arguments

[Augie Fackler]

On Tue, Mar 21, 2017 at 10:11 PM, Kevin Bullock
 wrote:
> $ PYTHON3=/path/to/python3 python run-tests.py test-check-py3-commands.t


Should be `python run-tests.py
--with-python3=/absolute/path/to/python3 test-check-py3-commands.t`.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 V2] debugfsinfo: print fstype information

[Yuya Nishihara]

On Tue, 21 Mar 2017 19:00:56 -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1489311257 28800
> #  Sun Mar 12 01:34:17 2017 -0800
> # Node ID ea4573691618ea1937cfe0c03c6caa4693b64b05
> # Parent  e960baabf0da65e84e99466d4be9acaa4b9b91b2
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> ea4573691618
> debugfsinfo: print fstype information

These generally look good. Queued, thanks.

> diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
> --- a/mercurial/debugcommands.py
> +++ b/mercurial/debugcommands.py
> @@ -791,4 +791,8 @@ def debugfsinfo(ui, path="."):
>  util.writefile('.debugfsinfo', '')
>  ui.write(('exec: %s\n') % (util.checkexec(path) and 'yes' or 'no'))
> +from . import osutil

Is there an import cycle?

> +if util.safehasattr(osutil, 'getfstype'):
> +fstype = osutil.getfstype('.')
> +ui.write(('fstype: %s\n') % (fstype or '(unknown)'))

Let's add util.getfstype() so we don't have to test the existence of
getfstype(). It should be okay to print '(unknown)' if unsupported.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revlog: use pycompat.maplist to eagerly evaluate map on Python 3

[Yuya Nishihara]

On Tue, 21 Mar 2017 17:40:02 -0400, Augie Fackler wrote:
> # HG changeset patch
> # User Augie Fackler 
> # Date 1490132389 14400
> #  Tue Mar 21 17:39:49 2017 -0400
> # Node ID c4547c92a05c9efcf779846f02c1308d1b09ed11
> # Parent  e245da2a41b16b28ac48d85e8f70f1216de6e074
> revlog: use pycompat.maplist to eagerly evaluate map on Python 3

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

[PATCH 4 of 6 V2] similar: do not look up and create filectx more than once

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1490271428 -32400
#  Thu Mar 23 21:17:08 2017 +0900
# Node ID 9c622785c2b0a4f4f157dd8ac6a0d0c6816d3725
# Parent  f1b08899545270dea26ac954d21a02ebd5beb5f3
similar: do not look up and create filectx more than once

Benchmark with 50k added/removed files, on tmpfs:

  $ hg addremove --dry-run --time -q

  previous:   real 16.070 secs (user 14.470+0.000 sys 1.580+0.000)
  this patch: real 12.420 secs (user 11.120+0.000 sys 1.280+0.000)

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -93,6 +93,9 @@ def _findsimilarmatches(repo, added, rem
 source, bscore = v
 yield source, dest, bscore
 
+def _dropempty(fctxs):
+return [x for x in fctxs if x.size() > 0]
+
 def findrenames(repo, added, removed, threshold):
 '''find renamed files -- yields (before, after, score) tuples'''
 wctx = repo[None]
@@ -101,10 +104,8 @@ def findrenames(repo, added, removed, th
 # Zero length files will be frequently unrelated to each other, and
 # tracking the deletion/addition of such a file will probably cause more
 # harm than good. We strip them out here to avoid matching them later on.
-addedfiles = [wctx[fp] for fp in sorted(added)
-  if wctx[fp].size() > 0]
-removedfiles = [pctx[fp] for fp in sorted(removed)
-if fp in pctx and pctx[fp].size() > 0]
+addedfiles = _dropempty(wctx[fp] for fp in sorted(added))
+removedfiles = _dropempty(pctx[fp] for fp in sorted(removed) if fp in pctx)
 
 # Find exact matches.
 matchedfiles = set()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 6 of 6 V2] similar: use cheaper hash() function to test exact matches

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1490270247 -32400
#  Thu Mar 23 20:57:27 2017 +0900
# Node ID 5954caab67d569bc680339175b4a12b400b9ad12
# Parent  d628846ce8182338b112820860b3c7fe4dcbc33d
similar: use cheaper hash() function to test exact matches

We just need a hash table {fctx.data(): fctx} which doesn't keep fctx.data()
in memory. Let's simply use hash(fctx.data()) to put data out from memory,
and manage collided fctx objects by list.

This isn't significantly faster than using sha1, but is more correct as we
know SHA-1 collision attack is getting practical.

Benchmark with 50k added/removed files, on tmpfs:

  $ hg addremove --dry-run --time -q

  previous:   real 12.420 secs (user 11.120+0.000 sys 1.280+0.000)
  this patch: real 12.350 secs (user 11.210+0.000 sys 1.140+0.000)

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -7,8 +7,6 @@
 
 from __future__ import absolute_import
 
-import hashlib
-
 from .i18n import _
 from . import (
 bdiff,
@@ -23,25 +21,29 @@ def _findexactmatches(repo, added, remov
 '''
 numfiles = len(added) + len(removed)
 
-# Get hashes of removed files.
+# Build table of removed files: {hash(fctx.data()): [fctx, ...]}.
+# We use hash() to discard fctx.data() from memory.
 hashes = {}
-for i, fctx in enumerate(reversed(removed)):
+for i, fctx in enumerate(removed):
 repo.ui.progress(_('searching for exact renames'), i, total=numfiles,
  unit=_('files'))
-h = hashlib.sha1(fctx.data()).digest()
-hashes[h] = fctx
+h = hash(fctx.data())
+if h not in hashes:
+hashes[h] = [fctx]
+else:
+hashes[h].append(fctx)
 
 # For each added file, see if it corresponds to a removed file.
 for i, fctx in enumerate(added):
 repo.ui.progress(_('searching for exact renames'), i + len(removed),
 total=numfiles, unit=_('files'))
 adata = fctx.data()
-h = hashlib.sha1(adata).digest()
-if h in hashes:
-rfctx = hashes[h]
+h = hash(adata)
+for rfctx in hashes.get(h, []):
 # compare between actual file contents for exact identity
 if adata == rfctx.data():
 yield (rfctx, fctx)
+break
 
 # Done
 repo.ui.progress(_('searching for exact renames'), None)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 6 V2] similar: use common names for changectx variables

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1490271045 -32400
#  Thu Mar 23 21:10:45 2017 +0900
# Node ID f1b08899545270dea26ac954d21a02ebd5beb5f3
# Parent  8b33a51771425d2623aa37dbcff05cdb5cc8e2fa
similar: use common names for changectx variables

We generally use 'wctx' and 'pctx' for working context and its parent
respectively.

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -95,16 +95,16 @@ def _findsimilarmatches(repo, added, rem
 
 def findrenames(repo, added, removed, threshold):
 '''find renamed files -- yields (before, after, score) tuples'''
-parentctx = repo['.']
-workingctx = repo[None]
+wctx = repo[None]
+pctx = wctx.p1()
 
 # Zero length files will be frequently unrelated to each other, and
 # tracking the deletion/addition of such a file will probably cause more
 # harm than good. We strip them out here to avoid matching them later on.
-addedfiles = [workingctx[fp] for fp in sorted(added)
-  if workingctx[fp].size() > 0]
-removedfiles = [parentctx[fp] for fp in sorted(removed)
-if fp in parentctx and parentctx[fp].size() > 0]
+addedfiles = [wctx[fp] for fp in sorted(added)
+  if wctx[fp].size() > 0]
+removedfiles = [pctx[fp] for fp in sorted(removed)
+if fp in pctx and pctx[fp].size() > 0]
 
 # Find exact matches.
 matchedfiles = set()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 6 V2] similar: sort files not by object id but by path for stable result

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1426413536 -32400
#  Sun Mar 15 18:58:56 2015 +0900
# Node ID 146e03f2e50d8fe4ef85eecbacb495724a6d0664
# Parent  102f291807c92864a2231e5e925d6cd64783bb59
similar: sort files not by object id but by path for stable result

Perhaps the original implementation would want to sort added/removed files
alphabetically, but actually it did sort fctx objects by memory location.

This patch removes the use of set()s in order to preserve the order of
added/removed files. addedfiles.remove() becomes quadratic, but its cost
appears not dominant. Anyway, the quadratic behavior will be eliminated by
the next patch.

Benchmark with 50k added/removed files, on tmpfs:

  $ mkdir src
  $ for n in `seq 0 49`; do
  > mkdir `printf src/%02d $n`
  > done

  $ for n in `seq 0 4`; do
  > f=`printf src/%02d/%05d $(($n/1000)) $n`
  > dd if=/dev/urandom of=$f bs=8k count=1 status=none
  > done

  $ hg ci -qAm 'add 50k files of random content'
  $ mv src dest

  $ hg addremove --dry-run --time -q

  original:   real 16.550 secs (user 15.000+0.000 sys 1.540+0.000)
  this patch: real 16.730 secs (user 15.280+0.000 sys 1.440+0.000)

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -101,19 +101,18 @@ def findrenames(repo, added, removed, th
 # Zero length files will be frequently unrelated to each other, and
 # tracking the deletion/addition of such a file will probably cause more
 # harm than good. We strip them out here to avoid matching them later on.
-addedfiles = set([workingctx[fp] for fp in added
-if workingctx[fp].size() > 0])
-removedfiles = set([parentctx[fp] for fp in removed
-if fp in parentctx and parentctx[fp].size() > 0])
+addedfiles = [workingctx[fp] for fp in sorted(added)
+  if workingctx[fp].size() > 0]
+removedfiles = [parentctx[fp] for fp in sorted(removed)
+if fp in parentctx and parentctx[fp].size() > 0]
 
 # Find exact matches.
-for (a, b) in _findexactmatches(repo,
-sorted(addedfiles), sorted(removedfiles)):
+for (a, b) in _findexactmatches(repo, addedfiles[:], removedfiles):
 addedfiles.remove(b)
 yield (a.path(), b.path(), 1.0)
 
 # If the user requested similar files to be matched, search for them also.
 if threshold < 1.0:
-for (a, b, score) in _findsimilarmatches(repo,
-sorted(addedfiles), sorted(removedfiles), threshold):
+for (a, b, score) in _findsimilarmatches(repo, addedfiles,
+ removedfiles, threshold):
 yield (a.path(), b.path(), score)
diff --git a/tests/test-addremove-similar.t b/tests/test-addremove-similar.t
--- a/tests/test-addremove-similar.t
+++ b/tests/test-addremove-similar.t
@@ -55,6 +55,78 @@ comparing two empty files caused ZeroDiv
 
   $ hg commit -m B
 
+should be sorted by path for stable result
+
+  $ for i in `python $TESTDIR/seq.py 0 9`; do
+  > cp small-file $i
+  > done
+  $ rm small-file
+  $ hg addremove
+  adding 0
+  adding 1
+  adding 2
+  adding 3
+  adding 4
+  adding 5
+  adding 6
+  adding 7
+  adding 8
+  adding 9
+  removing small-file
+  recording removal of small-file as rename to 0 (100% similar)
+  recording removal of small-file as rename to 1 (100% similar)
+  recording removal of small-file as rename to 2 (100% similar)
+  recording removal of small-file as rename to 3 (100% similar)
+  recording removal of small-file as rename to 4 (100% similar)
+  recording removal of small-file as rename to 5 (100% similar)
+  recording removal of small-file as rename to 6 (100% similar)
+  recording removal of small-file as rename to 7 (100% similar)
+  recording removal of small-file as rename to 8 (100% similar)
+  recording removal of small-file as rename to 9 (100% similar)
+  $ hg commit -m '10 same files'
+
+pick one from many identical files
+
+  $ cp 0 a
+  $ rm `python $TESTDIR/seq.py 0 9`
+  $ hg addremove
+  removing 0
+  removing 1
+  removing 2
+  removing 3
+  removing 4
+  removing 5
+  removing 6
+  removing 7
+  removing 8
+  removing 9
+  adding a
+  recording removal of 9 as rename to a (100% similar)
+  $ hg revert -aq
+
+pick one from many similar files
+
+  $ cp 0 a
+  $ for i in `python $TESTDIR/seq.py 0 9`; do
+  > echo $i >> $i
+  > done
+  $ hg commit -m 'make them slightly different'
+  $ rm `python $TESTDIR/seq.py 0 9`
+  $ hg addremove -s50
+  removing 0
+  removing 1
+  removing 2
+  removing 3
+  removing 4
+  removing 5
+  removing 6
+  removing 7
+  removing 8
+  removing 9
+  adding a
+  recording removal of 9 as rename to a (99% similar)
+  $ hg commit -m 'always the same file should be selected'
+
 should all fail
 
   $ hg addremove -s foo
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org

[PATCH 5 of 6 V2] similar: take the first match instead of the last

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1490269961 -32400
#  Thu Mar 23 20:52:41 2017 +0900
# Node ID d628846ce8182338b112820860b3c7fe4dcbc33d
# Parent  9c622785c2b0a4f4f157dd8ac6a0d0c6816d3725
similar: take the first match instead of the last

It seems more natural. This makes the next patch slightly cleaner.

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -25,7 +25,7 @@ def _findexactmatches(repo, added, remov
 
 # Get hashes of removed files.
 hashes = {}
-for i, fctx in enumerate(removed):
+for i, fctx in enumerate(reversed(removed)):
 repo.ui.progress(_('searching for exact renames'), i, total=numfiles,
  unit=_('files'))
 h = hashlib.sha1(fctx.data()).digest()
@@ -85,7 +85,7 @@ def _findsimilarmatches(repo, added, rem
 if data is None:
 data = _ctxdata(r)
 myscore = _score(a, data)
-if myscore >= bestscore:
+if myscore > bestscore:
 copies[a] = (r, myscore)
 repo.ui.progress(_('searching'), None)
 
diff --git a/tests/test-addremove-similar.t b/tests/test-addremove-similar.t
--- a/tests/test-addremove-similar.t
+++ b/tests/test-addremove-similar.t
@@ -101,7 +101,7 @@ pick one from many identical files
   removing 8
   removing 9
   adding a
-  recording removal of 9 as rename to a (100% similar)
+  recording removal of 0 as rename to a (100% similar)
   $ hg revert -aq
 
 pick one from many similar files
@@ -124,7 +124,7 @@ pick one from many similar files
   removing 8
   removing 9
   adding a
-  recording removal of 9 as rename to a (99% similar)
+  recording removal of 0 as rename to a (99% similar)
   $ hg commit -m 'always the same file should be selected'
 
 should all fail
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 6 V2] similar: get rid of quadratic addedfiles.remove()

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1490269833 -32400
#  Thu Mar 23 20:50:33 2017 +0900
# Node ID 8b33a51771425d2623aa37dbcff05cdb5cc8e2fa
# Parent  146e03f2e50d8fe4ef85eecbacb495724a6d0664
similar: get rid of quadratic addedfiles.remove()

Instead, build a set of files to be removed and recreate addedfiles
only if necessary.

Benchmark with 50k added/removed files, on tmpfs:

  $ hg addremove --dry-run --time -q

  original:   real 16.550 secs (user 15.000+0.000 sys 1.540+0.000)
  previous:   real 16.730 secs (user 15.280+0.000 sys 1.440+0.000)
  this patch: real 16.070 secs (user 14.470+0.000 sys 1.580+0.000)

diff --git a/mercurial/similar.py b/mercurial/similar.py
--- a/mercurial/similar.py
+++ b/mercurial/similar.py
@@ -107,12 +107,14 @@ def findrenames(repo, added, removed, th
 if fp in parentctx and parentctx[fp].size() > 0]
 
 # Find exact matches.
-for (a, b) in _findexactmatches(repo, addedfiles[:], removedfiles):
-addedfiles.remove(b)
+matchedfiles = set()
+for (a, b) in _findexactmatches(repo, addedfiles, removedfiles):
+matchedfiles.add(b)
 yield (a.path(), b.path(), 1.0)
 
 # If the user requested similar files to be matched, search for them also.
 if threshold < 1.0:
+addedfiles = [x for x in addedfiles if x not in matchedfiles]
 for (a, b, score) in _findsimilarmatches(repo, addedfiles,
  removedfiles, threshold):
 yield (a.path(), b.path(), score)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] findrenames: sort files not by object id but by path for stable result

[Yuya Nishihara]

On Wed, 22 Mar 2017 16:14:01 +, Ryan McElroy wrote:
> On 3/22/17 1:48 PM, Yuya Nishihara wrote:
> > # HG changeset patch
> > # User Yuya Nishihara 
> > # Date 1426413536 -32400
> > #  Sun Mar 15 18:58:56 2015 +0900
> > # Node ID 425379e72e817b6c79e955173b015b9a0fe090e9
> > # Parent  102f291807c92864a2231e5e925d6cd64783bb59
> > findrenames: sort files not by object id but by path for stable result
> >
> > It seems the original implementation tried to sort added/removed files
> > alphabetically, but actually it did sort fctx objects by address.
> >
> > This patch removes the use of set()s in order to preserve the order of
> > added/removed files. addedfiles.remove() could be slightly slower than
> > before, but it doesn't make much difference.
> ...except perhaps on a large number of files added/removed, right? Why 
> not re-sort and move the possible O(n^2) to at worst O(n log n)? It 
> doesn't seem like it would be too much more work to me.
> >
> > benchmark (on tmpfs):
> >$ hg up -C 15afda349b11; hg purge --all; mv tests tests.new
> >$ LANG=C hg --time addremove -n > /dev/null
> >
> >original:   real 0.420 secs (user 0.390+0.000 sys 0.030+0.000)
> >this patch: real 0.430 secs (user 0.390+0.000 sys 0.040+0.000)
> I think the algorithm scales O(n^2), so I'd be much more interested in a 
> move of, say, 100k files than a move of 1 file that is dominated by 
> startup time.

This moves "tests" directory which contains ~600 files. I'll show the number
of 50k files in V2, but this quadratic list.remove() is relatively cheap in
"hg addremove".
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH evolve-ext] tests: add glob for Windows

[Matt Harbison]

> On Mar 23, 2017, at 3:13 AM, Pierre-Yves David 
>  wrote:
> 
> 
> 
>> On 03/21/2017 06:48 PM, Ryan McElroy wrote:
>>> On 3/17/17 3:32 AM, Matt Harbison wrote:
>>> # HG changeset patch
>>> # User Matt Harbison 
>>> # Date 1489720627 14400
>>> #  Thu Mar 16 23:17:07 2017 -0400
>>> # Node ID ab5c2bef148bfb60e1956a55de4b7ba00ebe1817
>>> # Parent  6a3248558b6929378450b572bb27406afe703ffd
>>> tests: add glob for Windows
>> 
>> This looks good to me.
> 
> This one is pushed, thanks.
> 
> Does this mean someone is actually running the evolve test on windows ?

This is the first time I've run them in awhile.  There's still something broke 
around pruning bookmarks.  I was able to make it work a few years ago by 
calling invalidate(), but that seemed like a sledgehammer.  I'll post more 
detail next time I have the repo in front of me.

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

Re: [PATCH] help: format ``commands`` heading correctly

[Ryan McElroy]

On 3/22/17 11:37 PM, Martin von Zweigbergk via Mercurial-devel wrote:

# HG changeset patch
# User Martin von Zweigbergk 
# Date 1490225813 25200
#  Wed Mar 22 16:36:53 2017 -0700
# Node ID cd99f61579194767aaa958a29d8de88e639d1578
# Parent  55c6788c54e2faf80ec14f2b0844bfe429012bc3
help: format ``commands`` heading correctly
Kostia also send this patch out (see 
https://patchwork.mercurial-scm.org/patch/19579/), and either one will 
work fine. Let's just get one of them in.


Sorry for breaking this when I renamed the section. I should probably 
add a check-code for this as penance.




The number of dashes under it needs to match exactly for it to be
rendered as a heading. Without this change, the dashes end up on the
same line as "commands", and "hg help config.commands" does not work.

diff -r 55c6788c54e2 -r cd99f6157919 mercurial/help/config.txt
--- a/mercurial/help/config.txt Tue Mar 21 22:47:49 2017 -0700
+++ b/mercurial/help/config.txt Wed Mar 22 16:36:53 2017 -0700
@@ -415,7 +415,7 @@
  extension).
  
  ``commands``

---
+
  
  ``update.requiredest``

  Require that the user pass a destination when running ``hg update``.



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

Re: [PATCH] fancyopts: making config defaults actually override defaults

[Ryan McElroy]

On 3/22/17 6:51 PM, Martin von Zweigbergk wrote:

On Wed, Mar 22, 2017 at 10:14 AM, Rodrigo Damazio  wrote:

On Wed, Mar 22, 2017 at 3:50 AM, Ryan McElroy  wrote:

Rodrigo: for some reason, patchwork thinks you are Martin. Any idea why?
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.mercurial-2Dscm.org_patch_19133_=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=Jw8rundaE7TbmqBYd1txIQ=qgti-7e8saOlUI0k7ljLZ6HAh4SsKVlgoONeD60WZRA=pKbjIO05blt_27t3IcMhFfzDFctfA-bMMaXrmGmiXJM=

No idea, but I'm using a script he created for mailing patches directly to
gmail's backend servers (to avoid reformatting) - Martin, any chance you
hardcoded your own address there? :)

Nope. IIUC, patchwork has decided to associate any email from
mercurial-devel@mercurial-scm.org with me, because it probably first
received one from there from me. And the reason it is from
mercurial-devel@mercurial-scm.org in the first place is because we
(Google) set the DMARC/SPF/whatever headers to prevent spoofing of
@google.com addresses, so the mailing list has no choice but to
rewrite it as coming from the mailing list itself. I may very well
have misunderstood how that works, but hopefully you get the idea
anyway.


On 3/14/17 10:16 PM, Rodrigo Damazio via Mercurial-devel wrote:

On Tue, Mar 14, 2017 at 12:50 PM, David Soria Parra
 wrote:

On Sat, Mar 11, 2017 at 06:03:30PM -0800, Rodrigo Damazio Bovendorp via
Mercurial-devel wrote:

# HG changeset patch
# User Rodrigo Damazio 
# Date 1489274373 28800
#  Sat Mar 11 15:19:33 2017 -0800
# Node ID 8c833b81a994e2d3304c3b06793f536355528aab
# Parent  62939e0148f170b67ca8c7374f36c413b67fd387
fancyopts: making config defaults actually override defaults


Overall this LGTM, and clearly makes defaults much better :).  My concern
is that we are encouraging the use of defaults again, while they are
deprecated. Defaults have inherent problems that they overwrite arguments
which might be mutable exclusive with others (e.g. --graph in incoming
and outgoing), or lead to undesired behavior if it's set by an admin. an
exmaple
is if you would specifiy defaults.update.check=True, the user will not
find an
--no-check option in the help message or anywhere else. This is not a
problem if
we assume defaults are alway set by the user and he knows about them.


Thanks for the review.

Yes, we discussed the update --check case specifically during Sprint:
https://urldefense.proofpoint.com/v2/url?u=https-3A__public.etherpad-2Dmozilla.org_p_sprint-2Dhg4.2=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=Jw8rundaE7TbmqBYd1txIQ=qgti-7e8saOlUI0k7ljLZ6HAh4SsKVlgoONeD60WZRA=usophD9VL71sbr6iMbVTWMVQPbQLoK4f-qe9si7v3rU=
(search for "Flags and defaults breakout")


Note that I copied the notes over the the wiki for posterity:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_wiki_4.2sprint_Notes=DwIBaQ=5VD0RTtNlTh3ycd41b3MUw=Jw8rundaE7TbmqBYd1txIQ=qgti-7e8saOlUI0k7ljLZ6HAh4SsKVlgoONeD60WZRA=5pz07una5PeOy9ugeIPoZIk4uGiP7gE5cwdweE6HcTI=

If people do some cleanup passes and categorization, that would be useful.
I may contribute here at some point as well.


The conclusion was that this gains us the ability to do proper single-flag
overrides, which is good, but doesn't solve all the issues. There are other
changes we also want to make flags and defaults useful again:
- make the passed-in flag values not be simple primitive types, but rather
enhance them with addition information about where the value is coming from,
so commands like update can decide that an explicit --clean overrides a
system default of --check, and should only fail if both come from the same
level
- we want to add a --no- counterflag for every flag, not just booleans, as
a way to unset it (useful for revision-specifying flags for instance)
- we want to add environment variables to the stack of overrides along
with the different levels of config files and command-line arguments
- we want to try making all positional arguments map to flags (e.g. "hg
update 123" would be equivalent to "hg update -r 123" by making 123 be
passed to the command as the -r flag, also allowing config overrides for
those)
- we want to investigate why we support callables in flag defaults, and
remove support if that's not useful to anyone



While I like this initial direction, I think this needs to be turned into
a series of smaller steps, and we need more discussion around whether we
will revive the defaults section or keep it deprecated. I'll drop this from
patchwork for now while we discuss.


No problem. How/where/when/what would you like to discuss?



I suggest we keep discussing on this thread. If there isn't enough 
opposition to "reviving" defaults, then maybe just keep this direction 
and submit as a few smaller patches.


That being said, I'm a bit opposed to un-deprecating defaults. Even if 
it makes sense for this new functionality, reusing it makes it harder to 
de-emphasize as a