Re: [PATCH] hgweb: fix the MRO in Python 3

2016-10-26 Thread timeless
> Is there a checkcode test for this?

Martijn Pieters wrote:
> No, but tests simply fail when you make this mistake.
> In this *specific case* that was only visible in the Python 3 tests because 
> the base classes used in Python 2 were old-style classes, so in *Python 2* 
> the base class order happened to be legal.

I'm asking because I'm pretty sure I played w/ this specific glob of
code, and, from memory, the error messages weren't the easiest to
decipher. check-code warnings tend to be much easier for me to work
from to get to correct code.

But it doesn't sound like this is usually something that's easily
identified, so I'll drop the question.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] templates: update links to the book

2016-10-26 Thread Kevin Bullock
> On Oct 26, 2016, at 14:58, Mathias De Maré  wrote:
> 
> # HG changeset patch
> # User Mathias De Maré 
> # Date 1477511250 -7200
> #  Wed Oct 26 21:47:30 2016 +0200
> # Node ID 53e90a523b43efa8b34a9868eb692294edd75a22
> # Parent  4ec689699207cee6c4f2e09e9580df3b850f9441
> templates: update links to the book

Pushed this and one more fixup patch:

# HG changeset patch
# User Kevin Bullock 
# Date 1475272133 18000
#  Fri Sep 30 16:48:53 2016 -0500
# Node ID 7bd9da64acf574705f1d362ab2905deda39f3085
# Parent  53e90a523b43efa8b34a9868eb692294edd75a22
guide: link to the book via https and update one more link

diff --git a/templates/guide/index.html b/templates/guide/index.html
--- a/templates/guide/index.html
+++ b/templates/guide/index.html
@@ -10,7 +10,7 @@
 
 
  https://www.mercurial-scm.org/wiki/Tutorial;>Tutorial - a more 
exhaustive tutorial. 
-https://book.mercurial-scm.org/;>Mercurial: The Definitive Guide - a 
very detailed description of Mercurial including http://book.mercurial-scm.org/read/concepts.html;>behind the scenes, 
an indepth article on the design of Mercurial.
+https://book.mercurial-scm.org/;>Mercurial: The Definitive Guide - a 
very detailed description of Mercurial including https://book.mercurial-scm.org/read/concepts.html;>behind the scenes, 
an indepth article on the design of Mercurial.
 https://www.mercurial-scm.org/wiki/UnderstandingMercurial;>Understanding 
Mercurial - the concepts behind Mercurial.
 
 
@@ -516,7 +516,7 @@ If you want to see the diffs, you can us
 
 
 
-Now you have the history of feature1 inside your project, but the changes 
aren't yet visible. Instead they are only stored inside a ".hg" directory of 
the project (http://hgbook.red-bean.com/read/behind-the-scenes.html;>more information 
on the store).
+Now you have the history of feature1 inside your project, but the changes 
aren't yet visible. Instead they are only stored inside a ".hg" directory of 
the project (https://book.mercurial-scm.org/read/concepts.html;>more information on 
the store).
 
 output of hg pull:
 pulling from ../feature1

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 v5] copy: distinguish "file exists" cases and add a hint (BC)

2016-10-26 Thread Kevin Bullock
> On Oct 26, 2016, at 15:05, Augie Fackler  wrote:
> 
>> On Oct 26, 2016, at 15:03, timeless  wrote:
>> 
>> Augie Fackler wrote:
>>> +hint = _('(hg rename %s to replace the file by '
>>> + 'recording a rename)\n') % flags
>>> +hint = _('(hg copy %s to replace the file by '
>>> + 'recording a copy)\n') % flags
>>> +hint = _('(hg rename --after to record the 
>>> rename)\n')
>>> +hint = _('(hg copy --after to record the copy)\n')
>> 
>> I know it's too late, but do we want to include backticks around the
>> part that's a command?
>> 
>> Otherwise it's hard for people (and translators, and people reading
>> translations) to figure out what to do...
> 
> If that's something we normally do, can you prep a patch to mail early in the 
> 4.1 cycle? (This is just a hint, so we can change the hint text safely.)

Changes to hint text should be fine during a freeze. No need to wait until 
November.

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

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


Re: [PATCH 15 of 16] copies: make _checkcopies handle copy sequences spanning the TCA (issue4028)

2016-10-26 Thread timeless
> +  note: possible conflict - f3b was renamed multiple times to:
> +   f3e
> +   f3d
>merging f4e and f4a to f4e
>warning: can't find ancestor for 'f3d' copied from 'f3b'!

I know this isn't where the message was introduced, but I'm having a
hard time understanding "renamed multiple times".

Did you mean:

"multiple sequential renames of f3b":
0: f3b
0->1: f3b -> f3e
1->2: f3e -> f3d

Or "divergent commits renamed f3b":
0: f3b
0->1: f3b -> f3e
0->2: f3b -> f3d

My guess is that you mean the latter. I /think/ that using the concept
I've written for it could make the message /slightly/ easier to
understand. If you want to avoid "divergent", you can use "competing".
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] templates: update links to the book

2016-10-26 Thread Mathias De Maré
On Wed, Oct 26, 2016 at 9:58 PM, Mathias De Maré 
wrote:

> # HG changeset patch
> # User Mathias De Maré 
> # Date 1477511250 -7200
> #  Wed Oct 26 21:47:30 2016 +0200
> # Node ID 53e90a523b43efa8b34a9868eb692294edd75a22
> # Parent  4ec689699207cee6c4f2e09e9580df3b850f9441
> templates: update links to the book
>

Should have clarified in the topic: this is a patch for hg-website.

>
> diff -r 4ec689699207 -r 53e90a523b43 templates/guide/index.html
> --- a/templates/guide/index.htmlFri Jul 22 18:46:43 2016 +0800
> +++ b/templates/guide/index.htmlWed Oct 26 21:47:30 2016 +0200
> @@ -10,7 +10,7 @@
>
>  
>   https://www.mercurial-
> scm.org/wiki/Tutorial">Tutorial - a more exhaustive tutorial. 
> -http://hgbook.red-bean.com/;>Mercurial: The Definitive Guide - a very
> detailed description of Mercurial including  href="http://hgbook.red-bean.com/read/behind-the-scenes.html;>behind the
> scenes, an indepth article on the design of Mercurial.
> +https://book.mercurial-scm.org/;>Mercurial: The Definitive Guide - a
> very detailed description of Mercurial including http://book.mercurial-scm.org/read/concepts.html;>behind
> the scenes, an indepth article on the design of Mercurial.
>  https://www.mercurial-
> scm.org/wiki/UnderstandingMercurial">Understanding Mercurial - the
> concepts behind Mercurial.
>  
>
> diff -r 4ec689699207 -r 53e90a523b43 templates/learn/index.html
> --- a/templates/learn/index.htmlFri Jul 22 18:46:43 2016 +0800
> +++ b/templates/learn/index.htmlWed Oct 26 21:47:30 2016 +0200
> @@ -25,7 +25,7 @@
>In this user-friendly, six-part tutorial, Joel Spolsky teaches you the
> key concepts of Mercurial. Also includes a section explaining the
> differences between SVN and Mercurial. 
>  
>  
> -http://hgbook.red-bean.com/;>Mercurial: The Definitive
> Guide ("hgbook")
> +http://book.mercurial-scm.org/;>Mercurial: The Definitive
> Guide ("hgbook")
>The free book from Bryan O' Sullivan gives a detailed and easy to read
> introduction to Mercurial and the philosophy behind it. 
>  
>
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 07 of 16] copies: detect graft-like merges

2016-10-26 Thread timeless
Gábor Stefanik wrote:
> +# overridden We still need to know a real common ancestor in this case We

You're missing periods before `We` twice in this line...
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH RFC] perf: add asv benchmarks

2016-10-26 Thread timeless
On Wed, Oct 12, 2016 at 4:35 AM, Philippe Pepiot
 wrote:
> +"show_commit_url": "https://www.selenic.com/hg/rev/;,

Not a review, but I believe this should be:
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: Main and stable migrated

2016-10-26 Thread Kevin Bullock
> On Oct 26, 2016, at 13:34, Gábor STEFANIK  wrote:
> 
> -Original Message-
>> From: Mercurial-devel [mailto:mercurial-devel-boun...@mercurial-scm.org]
>> On Behalf Of Kevin Bullock
>> Sent: Wednesday, October 26, 2016 7:26 PM
>> To: mercurial-devel 
>> Subject: Main and stable migrated
>> 
>> Hi all,
>> 
>> We've just finished migrating the main and stable repos from selenic.com to
>> mercurial-scm.org. The new main repo is:
>> 
>> https://www.mercurial-scm.org/repo/hg/
>> 
>> Let me know if you run into any problems with the new location.
> 
> What about hg-push? Has it also been migrated? Is it being kept in sync with 
> the new location, or the old one?

Pushgate has not yet been migrated, although it's on my list. The new location 
is set up to automatically sync with the old one, so pushgate should also stay 
reasonably in sync.

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: Main and stable migrated

2016-10-26 Thread Gábor STEFANIK
>


--
This message, including its attachments, is confidential. For more information 
please read NNG's email policy here:
http://www.nng.com/emailpolicy/
By responding to this email you accept the email policy.


-Original Message-
> From: Mercurial-devel [mailto:mercurial-devel-boun...@mercurial-scm.org]
> On Behalf Of Kevin Bullock
> Sent: Wednesday, October 26, 2016 7:26 PM
> To: mercurial-devel 
> Subject: Main and stable migrated
>
> Hi all,
>
> We've just finished migrating the main and stable repos from selenic.com to
> mercurial-scm.org. The new main repo is:
>
> https://www.mercurial-scm.org/repo/hg/
>
> Let me know if you run into any problems with the new location.

What about hg-push? Has it also been migrated? Is it being kept in sync with 
the new location, or the old one?

>
> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
>
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


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

2016-10-26 Thread Mercurial Commits
3 new changesets (3 on stable) in mercurial:

http://selenic.com/repo/hg//rev/ad56071b37d4
changeset:   30224:ad56071b37d4
branch:  stable
user:Mads Kiilerich 
date:Tue Oct 18 16:52:35 2016 +0200
summary: dirstate: fix debug.dirstate.delaywrite to use the new "now" after 
sleeping

http://selenic.com/repo/hg//rev/7069d3d8a56e
changeset:   30225:7069d3d8a56e
branch:  stable
parent:  30223:76c57e1fe79b
user:Wagner Bruna 
date:Sat Oct 22 23:18:43 2016 -0200
summary: i18n-pt_BR: synchronized with 7b428b00a1d4

http://selenic.com/repo/hg//rev/264f00b3e5f0
changeset:   30226:264f00b3e5f0
branch:  stable
bookmark:@
tag: tip
parent:  30224:ad56071b37d4
parent:  30225:7069d3d8a56e
user:Kevin Bullock 
date:Mon Oct 24 09:14:34 2016 -0500
summary: merge with i18n

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


Re: [PATCH STABLE] tests: run "cwd was removed" test only if cwd can actually be removed

2016-10-26 Thread Danek Duvall
Yuya Nishihara wrote:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1477489806 -32400
> #  Wed Oct 26 22:50:06 2016 +0900
> # Branch stable
> # Node ID d389b88b942adb330819437ef46d1b9acb4392d7
> # Parent  b9f7b0c10027764cee77f9c6d61877fcffea837f
> tests: run "cwd was removed" test only if cwd can actually be removed
> 
> On some platforms, cwd can't be removed. In which case, util.unlinkpath()
> continues with no error since the failure isn't critical.

The problem here is a bit more specific: while Linux (for example) prevents
you from removing cwd when referring to it as ".", Solaris prevents you
from removing it under all names.  So because that failure isn't critical,
the cwd ends up remaining behind on Solaris because it's done via the full
path.  It might make sense to be more specific in the name, too, though I'm
not sure what to suggest.

There's also a second test that has some related output:

--- a/tests/test-rebase-scenario-global.t
+++ b/tests/test-rebase-scenario-global.t
@@ -758,8 +758,6 @@ Test that rebase is not confused by $CWD
   $ hg commit -m 'second source with subdir'
   $ hg rebase -b . -d 1 --traceback
   rebasing 2:779a07b1b7a0 "first source commit"
-  current directory was removed
-  (consider changing to repo root: $TESTTMP/cwd-vanish)
   rebasing 3:a7d6f3a00bf3 "second source with subdir" (tip)
   saved backup bundle to 
$TESTTMP/cwd-vanish/.hg/strip-backup/779a07b1b7a0-853e0073-backup.hg (glob)

is what I had to remove temporarily.

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


Re: [PATCH 3 of 3 STABLE V2] changectx: do not include hidden revisions on short node lookup (issue4964)

2016-10-26 Thread Yuya Nishihara
On Tue, 25 Oct 2016 23:17:14 +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1477199774 -32400
> #  Sun Oct 23 14:16:14 2016 +0900
> # Branch stable
> # Node ID 242b7a856495179795ee5662f298029c4b492563
> # Parent  ecbce2fe4dea116c925a2fecd1b7b50df0a62589
> changectx: do not include hidden revisions on short node lookup (issue4964)
> 
> It was changed at dc25ed84bee8, but which seems wrong since we filtered out
> hidden nodes by _partialmatch() before that change. This patch makes
> changectx() be consistent with the filtered changelog, and detect a hidden
> short node only if it has no unique match in the filtered changelog.
> 
> Though we've made shortest(node) use unfiltered changelog, I think this is
> a separate issue worth fixing.
> 
> diff --git a/mercurial/context.py b/mercurial/context.py
> --- a/mercurial/context.py
> +++ b/mercurial/context.py
> @@ -481,11 +481,16 @@ class changectx(basectx):
>  except error.RepoLookupError:
>  pass
>  
> -self._node = repo.unfiltered().changelog._partialmatch(changeid)
> +self._node = repo.changelog._partialmatch(changeid)
>  if self._node is not None:
>  self._rev = repo.changelog.rev(self._node)
>  return
>  
> +# lookup hidden node to provide a better error indication
> +n = repo.unfiltered().changelog._partialmatch(changeid)
> +if n is not None:
> +repo.changelog.rev(n)  # must raise FilteredLookupError

Please feel free to drop this, the last patch, if the performance is important.

This problem will be invisible since we're making shortest() use unfiltered
repo. We can fix it later when _partialmatch() gets fast enough.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable] revset: don't cache abstractsmartset min/max invocations infinitely

2016-10-26 Thread Mads Kiilerich

On 10/26/2016 02:31 PM, Yuya Nishihara wrote:

On Wed, 26 Oct 2016 14:09:17 +0200, Mads Kiilerich wrote:

Instead, I would perhaps prefer to introduce a 'gettercache' that works
on methods that only have self as parameter (and thus can set a simple
instance method as I do here)  ... or a 'methodcache' that would be like
cachefunc but store the cache on the first 'self' parameter.

That also seems fine. (I'm not a big fan of overwriting methods since we're
likely to create self->self cycle, but that wouldn't be the case here.)



I guess it could be slightly more gc efficient to use 'lambda v=v: v' to 
avoid having a reference to v in the outer scope that also has self ...


/Mads

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


Re: [PATCH STABLE v2] sslutil: guard against broken certifi installations (issue5406)

2016-10-26 Thread Yuya Nishihara
On Mon, 24 Oct 2016 05:19:14 -0500, Gábor Stefanik wrote:
> # HG changeset patch
> # User Gábor Stefanik 
> # Date 1476893174 -7200
> #  Wed Oct 19 18:06:14 2016 +0200
> # Branch stable
> # Node ID c3fe0e56546a44a7961354d4840cdcb82cbecefc
> # Parent  76c57e1fe79b0980b377b4f305635dea393d6315
> sslutil: guard against broken certifi installations (issue5406)
> 
> Certifi is currently incompatible with py2exe; the Python code for certifi 
> gets
> included in library.zip, but not the cacert.pem file - and even if it were
> included, SSLContext can't load a cacert.pem file from library.zip.
> This currently makes it impossible to build a standalone Windows version of
> Mercurial.
> 
> Guard against this, and possibly other situations where a module with the name
> "certifi" exists, but is not usable.

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


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

2016-10-26 Thread Yuya Nishihara
On Tue, 25 Oct 2016 12:46:58 -0700, Durham Goode wrote:
> On 10/22/16 1:59 AM, Yuya Nishihara wrote:
> > On Tue, 18 Oct 2016 17:50:16 -0700, Durham Goode wrote:
> >> # HG changeset patch
> >> # User Durham Goode 
> >> # Date 1476837866 25200
> >> #  Tue Oct 18 17:44:26 2016 -0700
> >> # Branch stable
> >> # Node ID 3efece5c59853908d65de53635488361dbf20c49
> >> # Parent  ed607426a3ff4deda8c7f2de8b86d5b6ca976d67
> >> manifest: make manifestctx store the repo
> >>
> >> The old manifestctx stored a reference to the revlog. If the inmemory 
> >> revlog
> >> became invalid, the ctx now held an old copy and would be incorrect. To fix
> >> this, we need the ctx to go through the manifestlog for each access.
> >>
> >> This is the same pattern that changectx already uses (it stores the repo, 
> >> and
> >> accesses commit data through self._repo.changelog).
> >>
> >> diff --git a/mercurial/manifest.py b/mercurial/manifest.py
> >> --- a/mercurial/manifest.py
> >> +++ b/mercurial/manifest.py
> >> @@ -1276,7 +1276,7 @@ class manifestlog(object):
> >>   if self._treeinmem:
> >>   m = treemanifestctx(self._revlog, '', node)
> >>   else:
> >> -m = manifestctx(self._revlog, node)
> >> +m = manifestctx(self._repo, node)
> >>   if node != revlog.nullid:
> >>   self._mancache[node] = m
> > This will create a reference cycle, but I don't know if the situation gets
> > better or worse after this patch.
> >
> >repo -> manifestlog -> _mancache -> manifestctx -> repo
> >
> > Is _mancache valid after the manifestlog is recreated?
> _mancache is not really valid after manifestlog is recreated, since it 
> may contain manifest entries that no longer exist in the file. Even if 
> it didn't contain bad entries, the manifestctx itself needs up-to-date 
> access to the manifest revlog, which is only available through the repo 
> object (since the repo object's property is what handles manifest revlog 
> cache checking).

Perhaps I miss the point. Do we have stale copies of manifestlog and manifestctx
somewhere? My understanding is we've moved the @storecache to manifestlog() at
3c8811efdddc, so manifestlog, _revlog (and _mancache) should be accessible only
when they are valid, and manifestlog doesn't live longer than repo.manifest().
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable] revset: don't cache abstractsmartset min/max invocations infinitely

2016-10-26 Thread Yuya Nishihara
On Wed, 26 Oct 2016 14:09:17 +0200, Mads Kiilerich wrote:
> On 10/26/2016 01:21 PM, Yuya Nishihara wrote:
> > On Tue, 25 Oct 2016 18:57:26 +0200, Mads Kiilerich wrote:
> >> # HG changeset patch
> >> # User Mads Kiilerich 
> >> # Date 1477414587 -7200
> >> #  Tue Oct 25 18:56:27 2016 +0200
> >> # Branch stable
> >> # Node ID c2fe58cd4235fc6c8cabea882794303d620bec3a
> >> # Parent  76c57e1fe79b0980b377b4f305635dea393d6315
> >> revset: don't cache abstractsmartset min/max invocations infinitely
> >>
> >> There was a "leak", apparently introduced in ab66c1dee405. When running:
> >>
> >>  hg = hglib.open('repo')
> >>  while True:
> >>  hg.log("max(branch('default'))")
> >>
> >> all filteredset instances from branch() would be cached indefinitely by the
> >> @util.cachefunc annotation on the max() implementation.
> > Indeed. We've cached {self: v} pair every time max() was called.
> > Queued this for stable, thanks.
> >
> >> -@util.cachefunc
> >>   def min(self):
> >>   """return the minimum element in the set"""
> >> -if self.fastasc is not None:
> >> -for r in self.fastasc():
> >> -return r
> >> -raise ValueError('arg is an empty sequence')
> >> -return min(self)
> >> -
> >> -@util.cachefunc
> >> +if self.fastasc is None:
> >> +v = min(self)
> >> +else:
> >> +for v in self.fastasc():
> >> +break
> >> +else:
> >> +raise ValueError('arg is an empty sequence')
> >> +self.min = lambda: v
> >> +return v
> > I slightly prefer using propertycache() and wrap it by a function, which
> > is a common pattern seen in context.py, but that's just a nitpicking.
> 
> Exactly what do you mean with wrapping the property by a function? I 
> don't see a clear pattern of that in context.py?

Yes. What I have in mind is parents() -> self._parents for instance.

> Instead, I would perhaps prefer to introduce a 'gettercache' that works 
> on methods that only have self as parameter (and thus can set a simple 
> instance method as I do here)  ... or a 'methodcache' that would be like 
> cachefunc but store the cache on the first 'self' parameter.

That also seems fine. (I'm not a big fan of overwriting methods since we're
likely to create self->self cycle, but that wouldn't be the case here.)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH stable] revset: don't cache abstractsmartset min/max invocations infinitely

2016-10-26 Thread Mads Kiilerich

On 10/26/2016 01:21 PM, Yuya Nishihara wrote:

On Tue, 25 Oct 2016 18:57:26 +0200, Mads Kiilerich wrote:

# HG changeset patch
# User Mads Kiilerich 
# Date 1477414587 -7200
#  Tue Oct 25 18:56:27 2016 +0200
# Branch stable
# Node ID c2fe58cd4235fc6c8cabea882794303d620bec3a
# Parent  76c57e1fe79b0980b377b4f305635dea393d6315
revset: don't cache abstractsmartset min/max invocations infinitely

There was a "leak", apparently introduced in ab66c1dee405. When running:

 hg = hglib.open('repo')
 while True:
 hg.log("max(branch('default'))")

all filteredset instances from branch() would be cached indefinitely by the
@util.cachefunc annotation on the max() implementation.

Indeed. We've cached {self: v} pair every time max() was called.
Queued this for stable, thanks.


-@util.cachefunc
  def min(self):
  """return the minimum element in the set"""
-if self.fastasc is not None:
-for r in self.fastasc():
-return r
-raise ValueError('arg is an empty sequence')
-return min(self)
-
-@util.cachefunc
+if self.fastasc is None:
+v = min(self)
+else:
+for v in self.fastasc():
+break
+else:
+raise ValueError('arg is an empty sequence')
+self.min = lambda: v
+return v

I slightly prefer using propertycache() and wrap it by a function, which
is a common pattern seen in context.py, but that's just a nitpicking.


Exactly what do you mean with wrapping the property by a function? I 
don't see a clear pattern of that in context.py?


Instead, I would perhaps prefer to introduce a 'gettercache' that works 
on methods that only have self as parameter (and thus can set a simple 
instance method as I do here)  ... or a 'methodcache' that would be like 
cachefunc but store the cache on the first 'self' parameter.


/Mads

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


Re: [PATCH 2 of 3 STABLE V2] templater: use unfiltered changelog to calculate shortest() at O(log(N))

2016-10-26 Thread Yuya Nishihara
On Tue, 25 Oct 2016 23:17:13 +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1477399770 -32400
> #  Tue Oct 25 21:49:30 2016 +0900
> # Branch stable
> # Node ID ecbce2fe4dea116c925a2fecd1b7b50df0a62589
> # Parent  869574e70105ec60b88b1bb85a12369e5e560279
> templater: use unfiltered changelog to calculate shortest() at O(log(N))
 ^

The summary line was wrong. It should say s/O(log(N))/constant time/ since
we use prefix tree and the length of node characters is constant.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


RE: [PATCH STABLE] merge: avoid superfluous filemerges when grafting through renames (issue5407)

2016-10-26 Thread Gábor STEFANIK
>


--
This message, including its attachments, is confidential. For more information 
please read NNG's email policy here:
http://www.nng.com/emailpolicy/
By responding to this email you accept the email policy.


-Original Message-
> From: Mercurial-devel [mailto:mercurial-devel-boun...@mercurial-scm.org]
> On Behalf Of Gábor Stefanik
> Sent: Wednesday, October 26, 2016 12:21 AM
> To: mercurial-devel@mercurial-scm.org
> Subject: [PATCH STABLE] merge: avoid superfluous filemerges when grafting
> through renames (issue5407)
>
> # HG changeset patch
> # User Gábor Stefanik  # Date 1477422113 -7200
> #  Tue Oct 25 21:01:53 2016 +0200
> # Branch stable
> # Node ID 1f40c1fe34442812291b000c5e1a8b22ad14f091
> # Parent  76c57e1fe79b0980b377b4f305635dea393d6315
> merge: avoid superfluous filemerges when grafting through renames
> (issue5407)
>
> This is a fix for a regression introduced by the patches for issue4028.
>
> The test changes are due to us doing fewer _checkcopies searches now,
> which makes some test outputs revert to the pre-issue4028 behavior. That
> issue itself remains fixed, we only skip copy tracing for files where it isn't
> relevant.
> As a nice side effect, this makes copy detection much faster when tracing
> backwards through lots of renames.
>
> diff --git a/mercurial/copies.py b/mercurial/copies.py
> --- a/mercurial/copies.py
> +++ b/mercurial/copies.py
> @@ -631,6 +631,10 @@
>  backwards = not remotebase and base != tca and f in mb
>  getfctx = _makegetfctx(ctx)
>
> +if m1[f] == mb.get(f) and not remotebase:

Note: this remotebase check is probably not needed, and removing it actually 
speeds
things up further. However, it also causes additional debug output changes in 
tests
(i.e. more output reverts to pre-4028 behavior), so I decided to keep it in for 
stable.

Let me know if it's OK to just remove it and adjust the tests.

After 4.0, if we remove the remotebase check, we can possibly get rid of or 
simplify
the "ping-pong" rename handling code.

> +# Nothing to merge
> +return
> +
>  of = None
>  seen = set([f])
>  for oc in getfctx(f, m1[f]).ancestors():
> diff --git a/tests/test-graft.t b/tests/test-graft.t
> --- a/tests/test-graft.t
> +++ b/tests/test-graft.t
> @@ -181,9 +181,6 @@
>  searching for copies back to rev 1
>  unmatched files in other (from topological common ancestor):
>   c
> -all copies found (* = to merge, ! = divergent, % = renamed and deleted):
> - src: 'c' -> dst: 'b' *
> -checking for directory renames
>resolving manifests
> branchmerge: True, force: True, partial: False
> ancestor: 4c60f11aa304, local: 6b9e5368ca4e+, remote: 97f8bfe72746 @@ -
> 200,9 +197,6 @@
>  searching for copies back to rev 1
>  unmatched files in other (from topological common ancestor):
>   c
> -all copies found (* = to merge, ! = divergent, % = renamed and deleted):
> - src: 'c' -> dst: 'b' *
> -checking for directory renames
>resolving manifests
> branchmerge: True, force: True, partial: False
> ancestor: 4c60f11aa304, local: 1905859650ec+, remote: 9c233e8e184d @@ -
> 1280,3 +1274,15 @@
>
>$ hg cat f2c
>c2e
> +
> +Check superfluous filemerge of files renamed in the past but untouched
> +by graft
> +
> +  $ echo a > a
> +  $ hg ci -qAma
> +  $ hg mv a b
> +  $ echo b > b
> +  $ hg ci -qAmb
> +  $ echo c > c
> +  $ hg ci -qAmc
> +  $ hg up -q .~2
> +  $ hg graft tip -qt:fail
> diff --git a/tests/test-merge-local.t b/tests/test-merge-local.t
> --- a/tests/test-merge-local.t
> +++ b/tests/test-merge-local.t
> @@ -66,7 +66,7 @@
>merging zzz1_merge_ok
>merging zzz2_merge_bad
>warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg
> resolve --mark')
> -  2 files updated, 1 files merged, 2 files removed, 1 files unresolved
> +  2 files updated, 1 files merged, 3 files removed, 1 files unresolved
>use 'hg resolve' to retry unresolved file merges
>[1]
>
> @@ -104,7 +104,7 @@
>merging zzz1_merge_ok
>merging zzz2_merge_bad
>warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg
> resolve --mark')
> -  2 files updated, 1 files merged, 2 files removed, 1 files unresolved
> +  2 files updated, 1 files merged, 3 files removed, 1 files unresolved
>use 'hg resolve' to retry unresolved file merges
>[1]
>
> diff --git a/tests/test-up-local-change.t b/tests/test-up-local-change.t
> --- a/tests/test-up-local-change.t
> +++ b/tests/test-up-local-change.t
> @@ -242,4 +242,11 @@
>-a
>+b
>
> +test for superfluous filemerge of clean files renamed in the past
> +
> +  $ hg up -qC tip
> +  $ echo c > c
> +  $ hg add c
> +  $ hg up -qt:fail 0
> +
>$ cd ..
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> 

Re: [PATCH stable] revset: don't cache abstractsmartset min/max invocations infinitely

2016-10-26 Thread Yuya Nishihara
On Tue, 25 Oct 2016 18:57:26 +0200, Mads Kiilerich wrote:
> # HG changeset patch
> # User Mads Kiilerich 
> # Date 1477414587 -7200
> #  Tue Oct 25 18:56:27 2016 +0200
> # Branch stable
> # Node ID c2fe58cd4235fc6c8cabea882794303d620bec3a
> # Parent  76c57e1fe79b0980b377b4f305635dea393d6315
> revset: don't cache abstractsmartset min/max invocations infinitely
> 
> There was a "leak", apparently introduced in ab66c1dee405. When running:
> 
> hg = hglib.open('repo')
> while True:
> hg.log("max(branch('default'))")
> 
> all filteredset instances from branch() would be cached indefinitely by the
> @util.cachefunc annotation on the max() implementation.

Indeed. We've cached {self: v} pair every time max() was called.
Queued this for stable, thanks.

> -@util.cachefunc
>  def min(self):
>  """return the minimum element in the set"""
> -if self.fastasc is not None:
> -for r in self.fastasc():
> -return r
> -raise ValueError('arg is an empty sequence')
> -return min(self)
> -
> -@util.cachefunc
> +if self.fastasc is None:
> +v = min(self)
> +else:
> +for v in self.fastasc():
> +break
> +else:
> +raise ValueError('arg is an empty sequence')
> +self.min = lambda: v
> +return v

I slightly prefer using propertycache() and wrap it by a function, which
is a common pattern seen in context.py, but that's just a nitpicking.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel