Re: [PATCH] hgweb: fix the MRO in Python 3
> 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
> 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)
> On Oct 26, 2016, at 15:05, Augie Facklerwrote: > >> 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)
> + 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
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
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
On Wed, Oct 12, 2016 at 4:35 AM, Philippe Pepiotwrote: > +"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
> On Oct 26, 2016, at 13:34, Gábor STEFANIKwrote: > > -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
> -- 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)
3 new changesets (3 on stable) in mercurial: http://selenic.com/repo/hg//rev/ad56071b37d4 changeset: 30224:ad56071b37d4 branch: stable user:Mads Kiilerichdate: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
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)
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
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)
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
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
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
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))
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)
> -- 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
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