[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: +# 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 https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 9 of 9 V4] manifest: remove manifest.readshallowdelta
On 9/21/16 1:33 PM, Martin von Zweigbergk wrote: On Tue, Sep 20, 2016 at 4:47 PM, Durham Goodewrote: # HG changeset patch # User Durham Goode # Date 1474399441 25200 # Tue Sep 20 12:24:01 2016 -0700 # Node ID f24ed91bde0ea4307546848e1100735d13879372 # Parent b16ce237ed47ef8c6f0f72bbc511b29ea9289ef3 manifest: remove manifest.readshallowdelta This removes manifest.readshallowdelta and converts its one consumer to use manifestlog instead. diff --git a/mercurial/manifest.py b/mercurial/manifest.py --- a/mercurial/manifest.py +++ b/mercurial/manifest.py @@ -1246,41 +1246,6 @@ class manifest(manifestrevlog): self._dirlogcache) return self._dirlogcache[dir] -def _slowreaddelta(self, node): -r0 = self.deltaparent(self.rev(node)) -m0 = self.read(self.node(r0)) -m1 = self.read(node) -md = self._newmanifest() -for f, ((n0, fl0), (n1, fl1)) in m0.diff(m1).iteritems(): -if n1: -md[f] = n1 -if fl1: -md.setflag(f, fl1) -return md - -def readdelta(self, node): -if self._usemanifestv2 or self._treeondisk: -return self._slowreaddelta(node) -r = self.rev(node) -d = mdiff.patchtext(self.revdiff(self.deltaparent(r), r)) -return self._newmanifest(d) - -def readshallowdelta(self, node): -'''For flat manifests, this is the same as readdelta(). For -treemanifests, this will read the delta for this revlog's directory, -without recursively reading subdirectory manifests. Instead, any -subdirectory entry will be reported as it appears in the manifests, i.e. -the subdirectory will be reported among files and distinguished only by -its 't' flag.''' I thought this comment might be useful. Could you add it to the new method, thanks. Same thing applies to readshallow() in the previous patch. Will do. -if not self._treeondisk: -return self.readdelta(node) -if self._usemanifestv2: -raise error.Abort( -_("readshallowdelta() not implemented for manifestv2")) -r = self.rev(node) -d = mdiff.patchtext(self.revdiff(self.deltaparent(r), r)) -return manifestdict(d) - def read(self, node): if node == revlog.nullid: return self._newmanifest() # don't upset local cache diff --git a/mercurial/verify.py b/mercurial/verify.py --- a/mercurial/verify.py +++ b/mercurial/verify.py @@ -201,7 +201,8 @@ class verifier(object): progress=None): repo = self.repo ui = self.ui -mf = self.repo.manifest.dirlog(dir) +mf = self.repo.manifestlog._revlog.dirlog(dir) +mfl = self.repo.manifestlog nit: write mf in terms of mfl instead, but feel free to leave as is if this is changing again before the end of the series (feel free to ignore otherwise too :-)) I'm not sure I understand what you mean by "in terms of mfl"? if not dir: self.ui.status(_("checking manifests\n")) @@ -235,7 +236,8 @@ class verifier(object): self.err(lr, _("%s not in changesets") % short(n), label) try: -for f, fn, fl in mf.readshallowdelta(n).iterentries(): +mfdelta = mfl.get(dir, n).readdelta(shallow=True) +for f, fn, fl in mfdelta.iterentries(): if not f: self.err(lr, _("entry without name in manifest")) elif f == "/dev/null": # ignore this in very old repos ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DQIBaQ=5VD0RTtNlTh3ycd41b3MUw=nuarHzhP1wi1T9iURRCj1A=g23kxRa7I_WePzUCgsxSI92ed8zsD4GVzkhJgLrw8eg=-N_dUrq34DPROF4fJwAyTK6oFG8nFVVMUaUVPCRskfY= ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 7 of 9 V4] manifest: add shallow option to treemanifestctx.readdelta and readfast
On 9/21/16 1:32 PM, Martin von Zweigbergk wrote: On Tue, Sep 20, 2016 at 4:47 PM, Durham Goodewrote: # HG changeset patch # User Durham Goode # Date 1474399441 25200 # Tue Sep 20 12:24:01 2016 -0700 # Node ID 561681e7a16fa33aa8a40e4c9a31ff395a115e4c # Parent 69b91c12d904f329eff6618ac43f5cfef631e8dc manifest: add shallow option to treemanifestctx.readdelta and readfast The old manifest had different functions for performing shallow reads, shallow readdeltas, and shallow readfasts. Since a lot of the code is duplicate (and since those functions don't make sense on a normal manifestctx), let's unify them into flags on the existing readdelta and readfast functions. A future diff will change consumers of these functions to use the manifestctx versions and will delete the old apis. diff --git a/mercurial/manifest.py b/mercurial/manifest.py --- a/mercurial/manifest.py +++ b/mercurial/manifest.py @@ -1109,7 +1109,7 @@ class manifestctx(object): self._data = manifestdict(text) return self._data -def readfast(self): +def readfast(self, shallow=False): rl = self._revlog r = rl.rev(self._node) deltaparent = rl.deltaparent(r) @@ -1117,7 +1117,7 @@ class manifestctx(object): return self.readdelta() return self.read() -def readdelta(self): +def readdelta(self, shallow=False): revlog = self._revlog if revlog._usemanifestv2: # Need to perform a slow delta @@ -1176,27 +1176,40 @@ class treemanifestctx(object): def node(self): return self._node -def readdelta(self): -# Need to perform a slow delta +def readdelta(self, shallow=False): revlog = self._revlog -r0 = revlog.deltaparent(revlog.rev(self._node)) -m0 = treemanifestctx(revlog, revlog.node(r0), dir=self._dir).read() -m1 = self.read() -md = treemanifest(dir=self._dir) -for f, ((n0, fl0), (n1, fl1)) in m0.diff(m1).iteritems(): -if n1: -md[f] = n1 -if fl1: -md.setflag(f, fl1) -return md +if shallow and revlog._treeondisk and not revlog._usemanifestv2: +if revlog._usemanifestv2: Looks like this cannot happen because the condition above checks that it's false. True. Will fix +raise error.Abort( +_("shallow readdelta() not implemented for manifestv2")) +r = revlog.rev(self._node) +d = mdiff.patchtext(revlog.revdiff(revlog.deltaparent(r), r)) +return manifestdict(d) +else: +# Need to perform a slow delta +r0 = revlog.deltaparent(revlog.rev(self._node)) +m0 = treemanifestctx(revlog, revlog.node(r0), dir=self._dir).read() +m1 = self.read() +md = treemanifest(dir=self._dir) +for f, ((n0, fl0), (n1, fl1)) in m0.diff(m1).iteritems(): +if n1: +md[f] = n1 +if fl1: +md.setflag(f, fl1) +return md -def readfast(self): +def readfast(self, shallow=False): rl = self._revlog r = rl.rev(self._node) deltaparent = rl.deltaparent(r) -if deltaparent != revlog.nullrev and deltaparent in rl.parentrevs(r): -return self.readdelta() -return self.read() +if (deltaparent != revlog.nullrev and +deltaparent in rl.parentrevs(r)): +return self.readdelta(shallow=shallow) + +if shallow: +return manifestdict(rl.revision(self._node)) +else: +return self.read() class manifest(manifestrevlog): def __init__(self, opener, dir='', dirlogcache=None): ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial-2Ddevel=DQIBaQ=5VD0RTtNlTh3ycd41b3MUw=nuarHzhP1wi1T9iURRCj1A=0loc3QxbV83HAhNXcOapFTjP_X7sVB5naGs61y32iO0=1cqzH8WNI5JzlNBsQtDTvCxgzKza4y1Cn1sFmfZvsvo= ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 6 of 9 V4] manifest: change manifestlog mancache to be directory based
On 9/21/16 1:31 PM, Martin von Zweigbergk wrote: On Tue, Sep 20, 2016 at 4:47 PM, Durham Goodewrote: # HG changeset patch # User Durham Goode # Date 1474415164 25200 # Tue Sep 20 16:46:04 2016 -0700 # Node ID 69b91c12d904f329eff6618ac43f5cfef631e8dc # Parent 52a206d772021194ab4356aeba2c73650851a624 manifest: change manifestlog mancache to be directory based In the last patch we added a get() function that allows fetching directory level treemanifestctxs. It didn't handle caching at directory level though, so we need to change our mancache to support multiple directories. diff --git a/mercurial/manifest.py b/mercurial/manifest.py --- a/mercurial/manifest.py +++ b/mercurial/manifest.py @@ -1021,9 +1021,16 @@ class manifestlog(object): usetreemanifest = opts.get('treemanifest', usetreemanifest) self._treeinmem = usetreemanifest +# A dictionary containing the cache for each directory nit: "dictionary" doesn't add much. I'd rather say what is cached ([tree]manifestctx instances, right?). Will fix +self._dirmancache = {} + # We'll separate this into it's own cache once oldmanifest is no longer # used -self._mancache = repo.manifest._mancache +self._dirmancache[''] = repo.manifest._mancache IIUC, the root manifest's cache will be shared, but subdirectory logs will not be? I think the cache is not used very frequently, so maybe it's not a big deal? Do you know a good test case for it? Rebase? We're looking for a case where both manifest._mancache and manifestlog._dirmancache will be used, right? Perhaps there are no such cases so it doesn't matter? So it's probably fine, just wanted to point it out in case you can think of problem that I did not see. It's a bit trickier to share the directory level mancache since the directory level revlog may not have even been constructed yet when we construct the ctx (since it's not constructed until we call ctx.read()). I intend to get the entire manifest refactor in asap once the we unfreeze, and by the end the manifest class and it's cache will all be gone, so this is a very temporary measure. ___ 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 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). ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 4 STABLE] manifest: make manifestlog a storecache
On 10/22/16 2:09 AM, Yuya Nishihara wrote: On Tue, 18 Oct 2016 17:50:15 -0700, Durham Goode wrote: # HG changeset patch # User Durham Goode# Date 1476837219 25200 # Tue Oct 18 17:33:39 2016 -0700 # Branch stable # Node ID ed607426a3ff4deda8c7f2de8b86d5b6ca976d67 # Parent f4e70498d617737c47371a86c2177146c7b789fe manifest: make manifestlog a storecache --- a/mercurial/localrepo.py +++ b/mercurial/localrepo.py @@ -504,9 +504,9 @@ class localrepository(object): c.readpending('00changelog.i.a') return c -@storecache('00manifest.i') +@property def manifest(self): -return self._constructmanifest() +return self.manifestlog._oldmanifest def _constructmanifest(self): # This is a temporary function while we migrate from manifest to @@ -514,7 +514,7 @@ class localrepository(object): # manifest creation. return manifest.manifest(self.svfs) -@property +@storecache('00manifest.i') def manifestlog(self): return manifest.manifestlog(self.svfs, self) Can we remove manifestlog._repo to cut reference cycle? Right now everything that attempts to access the manifest must do it through the repo object. So in order for ctx objects to read from the manifest, it has to have the repo object (which is why changectx has the repo object now). Once we get rid of repo.manifest entirely, we can probably move the 00manifest.i caching down a layer into the manifestlog, and we could break the need to store the repo in the manifestlog. I'll do that as part of the remainder of my manifest refactor series. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH remotefilelog-ext v2] fileserverclient: avoid ever requesting nullid nodes
Pushed (with minor fix up since ‘node’ is no longer imported in that file). Thanks! On 10/24/16, 5:35 PM, "Augie Fackler"wrote: ># HG changeset patch ># User Augie Fackler ># Date 1477347305 14400 ># Mon Oct 24 18:15:05 2016 -0400 ># Node ID 2dbede85d40dec875be2df0442aa74982e56995d ># Parent be571104d9f7292cd218dbb1aaebda9ac0b6315f >fileserverclient: avoid ever requesting nullid nodes > >I keep tripping over bugs where this angers some part of our >stack. It's dumb to even be fetching these, but it's harmless to skip >them, so issue a developer warning when we encounter one and refuse to >fetch it. > >diff --git a/remotefilelog/fileserverclient.py >b/remotefilelog/fileserverclient.py >--- a/remotefilelog/fileserverclient.py >+++ b/remotefilelog/fileserverclient.py >@@ -577,6 +577,15 @@ class fileserverclient(object): > if fetchhistory: > missingids.update(historystore.getmissing(idstocheck)) > >+# partition missing nodes into nullid and not-nullid so we can >+# warn about this filtering potentially shadowing bugs. >+nullids = len([None for unused, id in missingids if id == >node.nullid]) >+if nullids: >+missingids = [(f, id) for f, id in missingids if id != >node.nullid] >+repo.ui.develwarn( >+('remotefilelog not fetching %d null revs' >+ ' - this is likely hiding bugs' % nullids), >+config='remotefilelog-ext') > if missingids: > global fetches, fetched, fetchcost > fetches += 1 ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH stable] revset: don't cache abstractsmartset min/max invocations infinitely
# 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. util.cachefunc seems dangerous as method decorator and is barely used elsewhere in the code base. Instead, just open code caching by having the min/max methods replace themselves with a plain lambda returning the result. diff --git a/mercurial/revset.py b/mercurial/revset.py --- a/mercurial/revset.py +++ b/mercurial/revset.py @@ -2924,23 +2924,29 @@ class abstractsmartset(object): """True if the set will iterate in topographical order""" raise NotImplementedError() -@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 + def max(self): """return the maximum element in the set""" -if self.fastdesc is not None: -for r in self.fastdesc(): -return r -raise ValueError('arg is an empty sequence') -return max(self) +if self.fastdesc is None: +return max(self) +else: +for v in self.fastdesc(): +break +else: +raise ValueError('arg is an empty sequence') +self.max = lambda: v +return v def first(self): """return the first element in the set (user iteration perspective) ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2] changectx: do not include hidden revisions on short node lookup (issue4964)
Excerpts from Yuya Nishihara's message of 2016-10-25 23:11:02 +0900: > On Tue, 25 Oct 2016 14:12:08 +0100, Jun Wu wrote: > > Excerpts from Yuya Nishihara's message of 2016-10-23 15:35:21 +0900: > > > # HG changeset patch > > > # User Yuya Nishihara> > > # Date 1477199774 -32400 > > > # Sun Oct 23 14:16:14 2016 +0900 > > > # Branch stable > > > # Node ID abbc5e382e1cb550f6d2ac886dfdb16bd95475ab > > > # Parent f180a39d749aeacb72936e629a372623b1f88b8c > > > changectx: do not include hidden revisions on short node lookup > > > (issue4964) > > > > > > It was changed at dc25ed84bee8, but which seems wrong since we explicitly > > > filter out hidden nodes by _partialmatch(). This patch makes changectx() > > > be consistent with the changelog, and detect a hidden short node only if > > > it has no unique match in filtered changelog. > > > > > > 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) > > > > Currently _partialmatch on unfiltered repo can be much faster than filtered > > repo. See d0ae5b8f80dc, and fd1bb7c1be78. > > > > I'd suggest get the nodeid from unfiltered repo first, and then test if it > > is hidden. Alternatively, it may be worthwhile to change _partialmatch to do > > the test so it's fast for filtered repo as well. > > Do we care the cost to handle ambiguous ids (i.e. failure case) here? > > We could try unfiltered repo first, but we would need to do _partialmatch() > again if the given changeid is not unique in unfiltered repo, but unique in > filtered repo. This is a success case and I think success cases are important. I realized this problem after sending the mail. I'd choose performance for now (seems martin has similar opinion). The correct fix would be changing the C radix tree code, which I do want to touch at some time to support serializing to disk. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 1 of 3 STABLE V2] templater: do not use index.partialmatch() directly to calculate shortest()
# HG changeset patch # User Yuya Nishihara# Date 1477199123 -32400 # Sun Oct 23 14:05:23 2016 +0900 # Branch stable # Node ID 869574e70105ec60b88b1bb85a12369e5e560279 # Parent 76c57e1fe79b0980b377b4f305635dea393d6315 templater: do not use index.partialmatch() directly to calculate shortest() cl.index.partialmatch() isn't a drop-in replacement for cl._partialmatch(). It has no knowledge about hidden revisions, and it raises ValueError if a node shorter than 4 chars is given. Instead, use index.partialmatch() through cl._partialmatch(), which has no such problems and gives the identical result with/without --pure. The test output was sampled with --pure without this patch, which shows the most correct result. However, we'll need to switch to using an unfiltered changelog because _partialmatch() of a filtered changelog can be an order of magnitude slower. (with hidden revisions) % hg log -R hg-committed -r0:2 -T '{node|shortest}\n' --time > /dev/null (.^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000) (.) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000) diff --git a/mercurial/templater.py b/mercurial/templater.py --- a/mercurial/templater.py +++ b/mercurial/templater.py @@ -840,13 +840,8 @@ def shortest(context, mapping, args): cl = mapping['ctx']._repo.changelog def isvalid(test): try: -try: -cl.index.partialmatch(test) -except AttributeError: -# Pure mercurial doesn't support partialmatch on the index. -# Fallback to the slow way. -if cl._partialmatch(test) is None: -return False +if cl._partialmatch(test) is None: +return False try: i = int(test) diff --git a/tests/test-command-template.t b/tests/test-command-template.t --- a/tests/test-command-template.t +++ b/tests/test-command-template.t @@ -3413,8 +3413,76 @@ Test shortest(node) function: hg: parse error: shortest() expects an integer minlength [255] + $ cd .. + +Test shortest(node) with the repo having short hash collision: + + $ hg init hashcollision + $ cd hashcollision + $ cat <> .hg/hgrc + > [experimental] + > evolution = createmarkers + > EOF + $ echo 0 > a + $ hg ci -qAm 0 + $ for i in 17 129 248 242 480 580 617 1057 2857 4025; do + > hg up -q 0 + > echo $i > a + > hg ci -qm $i + > done + $ hg up -q null + $ hg log -r0: -T '{rev}:{node}\n' + 0:b4e73ffab476aa0ee32ed81ca51e07169844bc6a + 1:11424df6dc1dd4ea255eae2b58eaca7831973bbc + 2:11407b3f1b9c3e76a79c1ec5373924df096f0499 + 3:11dd92fe0f39dfdaacdaa5f3997edc533875cfc4 + 4:10776689e627b465361ad5c296a20a487e153ca4 + 5:a00be79088084cb3aff086ab799f8790e01a976b + 6:a0b0acd79b4498d0052993d35a6a748dd51d13e6 + 7:a0457b3450b8e1b778f1163b31a435802987fe5d + 8:c56256a09cd28e5764f32e8e2810d0f01e2e357a + 9:c5623987d205cd6d9d8389bfc40fff9dbb670b48 + 10:c562ddd9c94164376c20b86b0b4991636a3bf84f + $ hg debugobsolete a00be79088084cb3aff086ab799f8790e01a976b + $ hg debugobsolete c5623987d205cd6d9d8389bfc40fff9dbb670b48 + $ hg debugobsolete c562ddd9c94164376c20b86b0b4991636a3bf84f + + nodes starting with '11' (we don't have the revision number '11' though) + + $ hg log -r 1:3 -T '{rev}:{shortest(node, 0)}\n' + 1:1142 + 2:1140 + 3:11d + + '5:a00' is hidden, but still we have two nodes starting with 'a0' + + $ hg log -r 6:7 -T '{rev}:{shortest(node, 0)}\n' + 6:a0b + 7:a04 + + node '10' conflicts with the revision number '10' even if it is hidden + (we could exclude hidden revision numbers, but currently we don't) + + $ hg log -r 4 -T '{rev}:{shortest(node, 0)}\n' + 4:107 + $ hg log -r 4 -T '{rev}:{shortest(node, 0)}\n' --hidden + 4:107 + + node 'c562' should be unique if the other 'c562' nodes are hidden + + $ hg log -r 8 -T '{rev}:{node|shortest}\n' + 8:c562 + $ hg log -r 8:10 -T '{rev}:{node|shortest}\n' --hidden + 8:c5625 + 9:c5623 + 10:c562d + + $ cd .. + Test pad function + $ cd r + $ hg log --template '{pad(rev, 20)} {author|user}\n' 2test 1{node|short} ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2] changectx: do not include hidden revisions on short node lookup (issue4964)
On Tue, 25 Oct 2016 14:12:08 +0100, Jun Wu wrote: > Excerpts from Yuya Nishihara's message of 2016-10-23 15:35:21 +0900: > > # HG changeset patch > > # User Yuya Nishihara> > # Date 1477199774 -32400 > > # Sun Oct 23 14:16:14 2016 +0900 > > # Branch stable > > # Node ID abbc5e382e1cb550f6d2ac886dfdb16bd95475ab > > # Parent f180a39d749aeacb72936e629a372623b1f88b8c > > changectx: do not include hidden revisions on short node lookup (issue4964) > > > > It was changed at dc25ed84bee8, but which seems wrong since we explicitly > > filter out hidden nodes by _partialmatch(). This patch makes changectx() > > be consistent with the changelog, and detect a hidden short node only if > > it has no unique match in filtered changelog. > > > > 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) > > Currently _partialmatch on unfiltered repo can be much faster than filtered > repo. See d0ae5b8f80dc, and fd1bb7c1be78. > > I'd suggest get the nodeid from unfiltered repo first, and then test if it > is hidden. Alternatively, it may be worthwhile to change _partialmatch to do > the test so it's fast for filtered repo as well. Do we care the cost to handle ambiguous ids (i.e. failure case) here? We could try unfiltered repo first, but we would need to do _partialmatch() again if the given changeid is not unique in unfiltered repo, but unique in filtered repo. This is a success case and I think success cases are important. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 2 of 3 STABLE V2] templater: use unfiltered changelog to calculate shortest() at O(log(N))
# 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)) cl._partialmatch() can be pretty slow if hidden revisions are involved. This patch cancels the slowdown introduced by the previous patch by using an unfiltered changelog, which means shortest(node) isn't always the shortest. The result isn't perfect, but seems okay as long as shortest(node) is short enough to type and can be used as an identifier. (with hidden revisions) % hg log -R hg-committed -r0:2 -T '{node|shortest}\n' --time > /dev/null (.^^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000) (.^) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000) (.) time: real 1.680 secs (user 1.650+0.000 sys 0.020+0.000) diff --git a/mercurial/templater.py b/mercurial/templater.py --- a/mercurial/templater.py +++ b/mercurial/templater.py @@ -837,7 +837,10 @@ def shortest(context, mapping, args): # i18n: "shortest" is a keyword _("shortest() expects an integer minlength")) -cl = mapping['ctx']._repo.changelog +# _partialmatch() of filtered changelog could take O(len(repo)) time, +# which would be unacceptably slow. so we look for hash collision in +# unfiltered space, which means some hashes may be slightly longer. +cl = mapping['ctx']._repo.unfiltered().changelog def isvalid(test): try: if cl._partialmatch(test) is None: diff --git a/tests/test-command-template.t b/tests/test-command-template.t --- a/tests/test-command-template.t +++ b/tests/test-command-template.t @@ -3469,9 +3469,10 @@ Test shortest(node) with the repo having 4:107 node 'c562' should be unique if the other 'c562' nodes are hidden + (but we don't try the slow path to filter out hidden nodes for now) $ hg log -r 8 -T '{rev}:{node|shortest}\n' - 8:c562 + 8:c5625 $ hg log -r 8:10 -T '{rev}:{node|shortest}\n' --hidden 8:c5625 9:c5623 ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 3 of 3 STABLE V2] changectx: do not include hidden revisions on short node lookup (issue4964)
# 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 + # lookup failed # check if it might have come from damaged dirstate # diff --git a/tests/test-command-template.t b/tests/test-command-template.t --- a/tests/test-command-template.t +++ b/tests/test-command-template.t @@ -3478,6 +3478,15 @@ Test shortest(node) with the repo having 9:c5623 10:c562d + since 'c562' is unique, it should be usable as an revision identifier + if the other 'c562' nodes are hidden + + $ hg log -r c562 -T '{rev}:{node}\n' + 8:c56256a09cd28e5764f32e8e2810d0f01e2e357a + $ hg log -r c562 -T '{rev}:{node}\n' --hidden + abort: 00changelog.i@c562: ambiguous identifier! + [255] + $ cd .. Test pad function ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output
On Mon, 24 Oct 2016 15:57:30 +0100, Barry Scott wrote: > On Monday, 24 October 2016 22:30:08 BST Yuya Nishihara wrote: > > On Mon, 24 Oct 2016 11:04:39 +0100, Barry Scott wrote: > > > >> +def setcbprompt(self, cbprompt): > > > >> +""" > > > >> +cbprompt is used to reply to prompts by the server > > > >> + It receives the max number of bytes to return and the > > > >> + contents of stdout received so far. > > > >> + > > > >> +Call with None to stop getting call backs. > > > >> + > > > >> +cbprompt is never called from merge() or import_() > > > >> +which already handle the prompt. > > > >> +""" > > > >> +self._cbprompt = cbprompt > > > > > > > > Nit: The "cb" prefix doesn't make sense here because there's little > > > > possibility of name conflicts. > > > > > > True but it is descriptive. > > > > Hmm, but it introduces new naming style, right? I have no strong opinion > > about this, but "prompt" seems just fine because we already have one. > > prompt is not part of the public API. rawcommand() is a public API. hgclient() exposes APIs from two different levels. > > > > And I think your setprotocoltrace() covers setcbout/err. Do we still > > > > need them?> > > > They solve two distinct problems. > > > > > > protocol tracing provides a way to see the low level, almost unprocessed > > > messages between client and server. Its purpose is to allow inspection > > > and debugging of the protocol. > > > > > > cbout and cderr provide a user of hglib with the post processed output and > > > error information. > > > > > > In production my GUI will use cdout and cderr often, but never protocol > > > trace. But when I cannot figure out what is happening I turn on protocol > > > trace to get an insight into how hglib works. That is, for example, how I > > > found that password: is sent on the ‘e’ channel. > > > > > > Conclusion yes we need both. > > > > Okay, I don't think they are required, but I agree they are semantically > > different from setprotocoltrace(). > > > > Another option is to provide an interface to set a single callback object > > that handles o/e/I/L channels altogether, so we could provide a helper class > > to translate o+L and e+L sequences to .prompt() and .password() > > respectively. > > I've assumed that its better to leave the hglib patch simple. > > As we talked about before a getcredentials call back would be great. > But That needs hg itself to change. I sugest that we stay with this API > until that is possible. Yeah, that's why I suggested you to extend prompt() to take err output. That wouldn't be neat, but was the simplest change I could think of. Since we're introducing more functions, it might be worth thinking a better interface. > > > > Also, dest may be a remote (ssh) path. > > > > > > I do not see how my patch breaks things in that case. I do not assume the > > > dest is a local path. > > > > If dest isn't a local path, open() with ['-R', dest] would fail. > > I'll drop the reopen code. Sounds fine. > > > I choose to leave the hglib.init and hglib.clone code untouched for as its > > > uses of it cannot care about call backs. > > > > Maybe they could take a callback as an argument? > > You will recall that where I started and you pointed out that it should be > set > once as state of hgclient(). Yes, that's because hgclient has many commands which can potentially need a callback. I think that's okay to pass a callback which will be set to new hgclient object created by open()/init()/clone(). Anyway, as you don't use hglib.init() and .clone(), we don't need to discuss that further. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 2] templater: do not use index.partialmatch() directly to calculate shortest()
On Mon, 24 Oct 2016 22:00:22 -0700, Martin von Zweigbergk wrote: > On Mon, Oct 24, 2016 at 5:24 AM, Yuya Nishiharawrote: > > On Sun, 23 Oct 2016 12:52:34 -0700, Martin von Zweigbergk wrote: > >> On Sat, Oct 22, 2016 at 11:35 PM, Yuya Nishihara wrote: > >> > # HG changeset patch > >> > # User Yuya Nishihara > >> > # Date 1477199123 -32400 > >> > # Sun Oct 23 14:05:23 2016 +0900 > >> > # Branch stable > >> > # Node ID f180a39d749aeacb72936e629a372623b1f88b8c > >> > # Parent 76c57e1fe79b0980b377b4f305635dea393d6315 > >> > templater: do not use index.partialmatch() directly to calculate > >> > shortest() > >> > > >> > cl.index.partialmatch() isn't a drop-in replacement for > >> > cl._partialmatch(). > >> > It has no knowledge about hidden revisions, and it can't accept a node > >> > shorter > >> > than the length 4. Instead, let cl._partialmatch() use > >> > index.partialmatch() > >> > if available. > >> > > >> > The test result is sampled with --pure. > >> > > >> > diff --git a/mercurial/templater.py b/mercurial/templater.py > >> > --- a/mercurial/templater.py > >> > +++ b/mercurial/templater.py > >> > @@ -840,13 +840,8 @@ def shortest(context, mapping, args): > >> > cl = mapping['ctx']._repo.changelog > >> > def isvalid(test): > >> > try: > >> > -try: > >> > -cl.index.partialmatch(test) > >> > >> Are there other callers of this method (index.partialmatch) or can we > >> remove it now? > > > > It's the low-level function behind cl._partialmatch(), so can't be removed. > > > >> > -except AttributeError: > >> > -# Pure mercurial doesn't support partialmatch on the > >> > index. > >> > -# Fallback to the slow way. > >> > -if cl._partialmatch(test) is None: > >> > -return False > >> > +if cl._partialmatch(test) is None: > >> > +return False > >> > >> How much slower is it? Correctness is almost always more important, > >> but it would be good to know how much slower we're making it. > > > > Here's some numbers. The performance characteristics is identical if no > > hidden > > revision is involved. If there are hidden revisions, _partialmatch() can > > fall > > back to O(len(repo)) path, which means shortest() becomes way slower if > > len(shortest(node)) > minlength. > > > > (with no hidden revision) > > % hg log -R mozilla-central -r0:2 -T '{node|shortest}\n' --time > > > /dev/null > > (before) time: real 1.310 secs (user 1.290+0.000 sys 0.010+0.000) > > (after) time: real 1.540 secs (user 1.520+0.000 sys 0.020+0.000) > > > > (with hidden revisions) > > % hg log -R hg-committed -r0:2 -T '{node|shortest}\n' --time > /dev/null > > (before) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000) > > (after) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000) > > > > If we want to choose the speed over the correctness, we can switch to use > > the > > unfiltered changelog, which will give the same results on both pure and CPy > > environments. > > That slowdown is pretty considerable, yes, it's probably not worth it. > I don't really care if the displayed hash is the shortest among the > visible; it's more important that whatever we display can be copied > into "hg co $hash". So if both shortest() and lookup is done on the > unfiltered index, that sounds fine to me. I'll send V2, in which the slowdown will be fixed by a separate patch to show the correct (and not 100%-correct but acceptable) results. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2] changectx: do not include hidden revisions on short node lookup (issue4964)
Excerpts from Yuya Nishihara's message of 2016-10-23 15:35:21 +0900: > # HG changeset patch > # User Yuya Nishihara> # Date 1477199774 -32400 > # Sun Oct 23 14:16:14 2016 +0900 > # Branch stable > # Node ID abbc5e382e1cb550f6d2ac886dfdb16bd95475ab > # Parent f180a39d749aeacb72936e629a372623b1f88b8c > changectx: do not include hidden revisions on short node lookup (issue4964) > > It was changed at dc25ed84bee8, but which seems wrong since we explicitly > filter out hidden nodes by _partialmatch(). This patch makes changectx() > be consistent with the changelog, and detect a hidden short node only if > it has no unique match in filtered changelog. > > 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) Currently _partialmatch on unfiltered repo can be much faster than filtered repo. See d0ae5b8f80dc, and fd1bb7c1be78. I'd suggest get the nodeid from unfiltered repo first, and then test if it is hidden. Alternatively, it may be worthwhile to change _partialmatch to do the test so it's fast for filtered repo as well. > 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 > + > # lookup failed > # check if it might have come from damaged dirstate > # > diff --git a/tests/test-command-template.t b/tests/test-command-template.t > --- a/tests/test-command-template.t > +++ b/tests/test-command-template.t > @@ -3477,6 +3477,15 @@ Test shortest(node) with the repo having >9:c5623 >10:c562d > > + since 'c562' is unique, it should be usable as an revision identifier > + if the other 'c562' nodes are hidden > + > + $ hg log -r c562 -T '{rev}:{node}\n' > + 8:c56256a09cd28e5764f32e8e2810d0f01e2e357a > + $ hg log -r c562 -T '{rev}:{node}\n' --hidden > + abort: 00changelog.i@c562: ambiguous identifier! > + [255] > + >$ cd .. > > Test pad function ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve] tests: use curl instead of wget
It sounds like the case that an additional abstraction could solve. I think it may be worthwhile to add a thin shell script choosing whatever available to use under "tests/". It could define a shell function (could be just "wget" and implement it using curl), and tests can source it. Excerpts from Simon Farnsworth's message of 2016-10-24 14:37:27 +0100: > On 24/10/2016 14:32, Pierre-Yves David wrote: > > > > > > On 10/24/2016 03:26 PM, Simon Farnsworth wrote: > >> # HG changeset patch > >> # User Simon Farnsworth> >> # Date 1477315431 25200 > >> # Mon Oct 24 06:23:51 2016 -0700 > >> # Branch stable > >> # Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e > >> # Parent 970a4c13ebc320a034bc0aff21e0ef0a84157a92 > >> tests: use curl instead of wget > >> > >> curl is supplied by default on macOS 10.12, but wget isn't. As curl is > >> easy > >> to install on other OSes, just switch the tests over. > > > > Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year > > ago. Can you have a look at them and come back with a plan that fits > > both need? > > > > I've looked at the commits you referenced, and there's not enough > context for me to understand why Matt switched from cURL (works on Linux > and macOS by default, needs a package installed on Windows as far as I > understand it), to wget (needs a package installed on Windows and macOS > as far as I understand it). > > Can you give me context for why you took these two commits? > > > > >> diff --git a/tests/test-simple4server-bundle2.t > >> b/tests/test-simple4server-bundle2.t > >> --- a/tests/test-simple4server-bundle2.t > >> +++ b/tests/test-simple4server-bundle2.t > >> @@ -71,12 +71,12 @@ > >> Capacity testing > >> === > >> > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=hello > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=hello > >>capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=capabilities > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=capabilities > >>* _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon > >> (no-eol) (glob) > >> > >> - $ wget -q -O - > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >> + $ curl -s > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >>bookmarks > >>namespaces > >>obsolete > >> @@ -128,14 +128,14 @@ > >> === > >> (used by bitbucket to select which repo use evolve) > >> > >> - $ wget -q -O - > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >> + $ curl -s > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >>bookmarks > >>namespaces > >>obsolete > >>phases > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=hello > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=hello > >>capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=capabilities > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=capabilities > >>* _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon > >> (no-eol) (glob) > >> > >>$ echo '[__temporary__]' >> server/.hg/hgrc > >> @@ -144,7 +144,7 @@ > >>$ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A > >> access.log -E errors.log > >>$ cat hg.pid >> $DAEMON_PIDS > >> > >> - $ wget -q -O - > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >> + $ curl -s > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >>bookmarks > >>namespaces > >>phases > >> @@ -154,13 +154,13 @@ > >>$ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A > >> access.log -E errors.log > >>$ cat hg.pid >> $DAEMON_PIDS > >> > >> - $ wget -q -O - > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >> + $ curl -s > >> "http://localhost:$HGPORT/?cmd=listkeys=namespaces > >> " | sort > >>bookmarks > >>namespaces > >>obsolete > >>phases > >> > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=hello > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=hello > >>capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) > >> - $ wget -q -O - > >> http://localhost:$HGPORT/?cmd=capabilities > >> + $ curl -s > >> http://localhost:$HGPORT/?cmd=capabilities > >>* _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 > >> _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon > >> (no-eol) (glob) > >> diff --git
Re: [PATCH evolve v2] tests: use curl instead of wget
As well as the extended commit message, I've also edited https://www.mercurial-scm.org/wiki/HackableMercurial which was the only wiki page I found mentioning msys. I don't know Windows well enough to actually get it right, though (things appear to have changed a bit since NT 3.51). Simon On 25/10/2016 13:23, Simon Farnsworth wrote: # HG changeset patch # User Simon Farnsworth# Date 1477397752 25200 # Tue Oct 25 05:15:52 2016 -0700 # Branch stable # Node ID f65f9acac6c69e6f2eb90b2ed9b51d818a046f67 # Parent 970a4c13ebc320a034bc0aff21e0ef0a84157a92 tests: use curl instead of wget curl is supplied by default on macOS 10.12, but wget isn't. As curl is easy to install on other OSes, just switch the tests over. For Windows systems, you can obtain cURL from https://urldefense.proofpoint.com/v2/url?u=https-3A__curl.haxx.se_download.html=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=RNJmt18FdGmAqHoKFoP0YdwtpdWeV9vll-MZwSCIk24= - for other systems, please use your native package manager. This undoes 4e7da688a066 and 3ffa12edc05a, as they don't make things much simpler on Windows (you have to install extra packages either way round), but they do make things harder on macOS (as curl is supplied by default, whereas wget isn't). diff --git a/tests/test-simple4server-bundle2.t b/tests/test-simple4server-bundle2.t --- a/tests/test-simple4server-bundle2.t +++ b/tests/test-simple4server-bundle2.t @@ -71,12 +71,12 @@ Capacity testing === - $ wget -q -O - https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=8iUVs0V0ElXtCkjkG1Z7w2c3t4YljF--qG-P8hSAQSo= + $ curl -s https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=8iUVs0V0ElXtCkjkG1Z7w2c3t4YljF--qG-P8hSAQSo= capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O - https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dcapabilities=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=S7W0pW9SHkDd5RGx6ImgpzkDEgimNJVZYEN6RQQXllw= + $ curl -s https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dcapabilities=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=S7W0pW9SHkDd5RGx6ImgpzkDEgimNJVZYEN6RQQXllw= * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob) - $ wget -q -O - "https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=x4s8JJyZEPf1dxyp2EdY-aVjRGZ1mxwgKOD40Uc3VhM= " | sort + $ curl -s "https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=x4s8JJyZEPf1dxyp2EdY-aVjRGZ1mxwgKOD40Uc3VhM= " | sort bookmarks namespaces obsolete @@ -128,14 +128,14 @@ === (used by bitbucket to select which repo use evolve) - $ wget -q -O - "https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=x4s8JJyZEPf1dxyp2EdY-aVjRGZ1mxwgKOD40Uc3VhM= " | sort + $ curl -s "https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=x4s8JJyZEPf1dxyp2EdY-aVjRGZ1mxwgKOD40Uc3VhM= " | sort bookmarks namespaces obsolete phases - $ wget -q -O - https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=8iUVs0V0ElXtCkjkG1Z7w2c3t4YljF--qG-P8hSAQSo= + $ curl -s https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQIGaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=xpCZbhnEotl-MEx3cSrK8Bq-4nzxq9NGPFZsnbO9v2s=8iUVs0V0ElXtCkjkG1Z7w2c3t4YljF--qG-P8hSAQSo= capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O -
[PATCH evolve v2] tests: use curl instead of wget
# HG changeset patch # User Simon Farnsworth# Date 1477397752 25200 # Tue Oct 25 05:15:52 2016 -0700 # Branch stable # Node ID f65f9acac6c69e6f2eb90b2ed9b51d818a046f67 # Parent 970a4c13ebc320a034bc0aff21e0ef0a84157a92 tests: use curl instead of wget curl is supplied by default on macOS 10.12, but wget isn't. As curl is easy to install on other OSes, just switch the tests over. For Windows systems, you can obtain cURL from https://curl.haxx.se/download.html - for other systems, please use your native package manager. This undoes 4e7da688a066 and 3ffa12edc05a, as they don't make things much simpler on Windows (you have to install extra packages either way round), but they do make things harder on macOS (as curl is supplied by default, whereas wget isn't). diff --git a/tests/test-simple4server-bundle2.t b/tests/test-simple4server-bundle2.t --- a/tests/test-simple4server-bundle2.t +++ b/tests/test-simple4server-bundle2.t @@ -71,12 +71,12 @@ Capacity testing === - $ wget -q -O - http://localhost:$HGPORT/?cmd=hello + $ curl -s http://localhost:$HGPORT/?cmd=hello capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities + $ curl -s http://localhost:$HGPORT/?cmd=capabilities * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob) - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort bookmarks namespaces obsolete @@ -128,14 +128,14 @@ === (used by bitbucket to select which repo use evolve) - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort bookmarks namespaces obsolete phases - $ wget -q -O - http://localhost:$HGPORT/?cmd=hello + $ curl -s http://localhost:$HGPORT/?cmd=hello capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities + $ curl -s http://localhost:$HGPORT/?cmd=capabilities * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob) $ echo '[__temporary__]' >> server/.hg/hgrc @@ -144,7 +144,7 @@ $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log $ cat hg.pid >> $DAEMON_PIDS - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort bookmarks namespaces phases @@ -154,13 +154,13 @@ $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log $ cat hg.pid >> $DAEMON_PIDS - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort bookmarks namespaces obsolete phases - $ wget -q -O - http://localhost:$HGPORT/?cmd=hello + $ curl -s http://localhost:$HGPORT/?cmd=hello capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities + $ curl -s http://localhost:$HGPORT/?cmd=capabilities * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob) diff --git a/tests/test-simple4server.t b/tests/test-simple4server.t --- a/tests/test-simple4server.t +++ b/tests/test-simple4server.t @@ -73,12 +73,12 @@ Capacity testing === - $ wget -q -O - http://localhost:$HGPORT/?cmd=hello + $ curl -s http://localhost:$HGPORT/?cmd=hello capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob) - $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities + $ curl -s http://localhost:$HGPORT/?cmd=capabilities * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob) - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort bookmarks namespaces obsolete @@ -131,14 +131,14 @@ === (used by bitbucket to select which repo use evolve) - $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort + $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | sort
Re: [PATCH evolve] tests: use curl instead of wget
On 25/10/2016 12:57, Matt Harbison wrote: OT: is there a blog or something somewhere that describes how you guys (or any other enterprises) get the developer's system setup and configured? Things like .hgrc settings, installing and configuring toolchains, staging build scripts, etc. I think I've read some of Greg's about how Mozilla does it, and we're basically trying to solve the same problems. There's nothing detailed out in the public domain; however, it's not a secret that we use chef for all our system configuration, including deciding which packages to install, and putting /etc/mercurial in place on developer systems. In turn, we build an in-house Mercurial package that bundles up all our extensions and Mercurial itself into a nice atomic lump for chef to play with. -- Simon Farnsworth ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve] tests: use curl instead of wget
> On Oct 25, 2016, at 4:30 AM, Simon Farnsworthwrote: > >> On 25/10/2016 02:34, Matt Harbison wrote: >> On Mon, 24 Oct 2016 09:37:27 -0400, Simon Farnsworth >> wrote: >> On 24/10/2016 14:32, Pierre-Yves David wrote: > On 10/24/2016 03:26 PM, Simon Farnsworth wrote: > # HG changeset patch > # User Simon Farnsworth > # Date 1477315431 25200 > # Mon Oct 24 06:23:51 2016 -0700 > # Branch stable > # Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e > # Parent 970a4c13ebc320a034bc0aff21e0ef0a84157a92 > tests: use curl instead of wget > > curl is supplied by default on macOS 10.12, but wget isn't. As curl is > easy > to install on other OSes, just switch the tests over. Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year ago. Can you have a look at them and come back with a plan that fits both need? >>> >>> I've looked at the commits you referenced, and there's not enough >>> context for me to understand why Matt switched from cURL (works on >>> Linux and macOS by default, needs a package installed on Windows as >>> far as I understand it), to wget (needs a package installed on Windows >>> and macOS as far as I understand it). >>> >>> Can you give me context for why you took these two commits? >> >> I didn't get a chance to see if wget was installed on previous versions >> of OS X before leaving work today, but I don't recall ever having >> installed it on 10.6 or 10.10. So maybe that's something new with 10.12? > > I've just checked a 10.10 VM and a 10.11 system, and those did not have wget > installed, either (but they did have curl). I can't go back further easily. > > Google tells me that wget is not preinstalled on 10.6 Snow Leopard, either > (http://apple.stackexchange.com/questions/12665/how-do-i-get-wget-for-snow-leopard > for example); I suspect that you had manually installed wget on your Macs. > >> The reason I switched was because wget is available with msys, but curl >> isn't. I dug up some Windows build of curl a few months ago, but don't >> recall where. Maybe it's still in my browser history at work. I seem >> to have a /mingw/bin/curl on my home system, and vaguely remember >> building that from source a long time ago. > It looks like msys doesn't provide curl, but the download "wizard" at > https://curl.haxx.se/download.html has current Windows builds listed next to > Cygwin builds. I can't try it at the moment, but that seems easy enough. > Would you like me to do a v2 of the patch summarizing this discussion and > linking to that page in the commit message? Yes, please. It's probably worth putting on the wiki page too (I don't have time to find it now, but I vaguely remember one on how to install msys to run the tests on Windows). I wouldn't necessarily look in the history if I see a command is missing, but if it's on that page when setting up a new system, the problem is avoided entirely. >> Since I doubt many (any?) people run the tests on Windows, I don't have >> a problem with switching back, if how to install curl is documented on >> the page describing how to run tests on Windows. I forget if I made >> similar changes in core Mercurial. > > This is the only test suite I run on macOS that uses wget - I run most of the > core test suite, so I'd notice if it needed wget. The reason this has become > an issue is that I'm shifting from manual builds to automatic builds of the > Facebook internal package (which bundles up Mercurial, some extensions, and > our configs for our users), and I want to minimise the work we have to do to > keep the automatic builds working. OT: is there a blog or something somewhere that describes how you guys (or any other enterprises) get the developer's system setup and configured? Things like .hgrc settings, installing and configuring toolchains, staging build scripts, etc. I think I've read some of Greg's about how Mozilla does it, and we're basically trying to solve the same problems. > -- > Simon Farnsworth ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve] tests: use curl instead of wget
On 25/10/2016 02:34, Matt Harbison wrote: On Mon, 24 Oct 2016 09:37:27 -0400, Simon Farnsworthwrote: On 24/10/2016 14:32, Pierre-Yves David wrote: On 10/24/2016 03:26 PM, Simon Farnsworth wrote: # HG changeset patch # User Simon Farnsworth # Date 1477315431 25200 # Mon Oct 24 06:23:51 2016 -0700 # Branch stable # Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e # Parent 970a4c13ebc320a034bc0aff21e0ef0a84157a92 tests: use curl instead of wget curl is supplied by default on macOS 10.12, but wget isn't. As curl is easy to install on other OSes, just switch the tests over. Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year ago. Can you have a look at them and come back with a plan that fits both need? I've looked at the commits you referenced, and there's not enough context for me to understand why Matt switched from cURL (works on Linux and macOS by default, needs a package installed on Windows as far as I understand it), to wget (needs a package installed on Windows and macOS as far as I understand it). Can you give me context for why you took these two commits? I didn't get a chance to see if wget was installed on previous versions of OS X before leaving work today, but I don't recall ever having installed it on 10.6 or 10.10. So maybe that's something new with 10.12? I've just checked a 10.10 VM and a 10.11 system, and those did not have wget installed, either (but they did have curl). I can't go back further easily. Google tells me that wget is not preinstalled on 10.6 Snow Leopard, either (http://apple.stackexchange.com/questions/12665/how-do-i-get-wget-for-snow-leopard for example); I suspect that you had manually installed wget on your Macs. The reason I switched was because wget is available with msys, but curl isn't. I dug up some Windows build of curl a few months ago, but don't recall where. Maybe it's still in my browser history at work. I seem to have a /mingw/bin/curl on my home system, and vaguely remember building that from source a long time ago. It looks like msys doesn't provide curl, but the download "wizard" at https://curl.haxx.se/download.html has current Windows builds listed next to Cygwin builds. Would you like me to do a v2 of the patch summarizing this discussion and linking to that page in the commit message? Since I doubt many (any?) people run the tests on Windows, I don't have a problem with switching back, if how to install curl is documented on the page describing how to run tests on Windows. I forget if I made similar changes in core Mercurial. This is the only test suite I run on macOS that uses wget - I run most of the core test suite, so I'd notice if it needed wget. The reason this has become an issue is that I'm shifting from manual builds to automatic builds of the Facebook internal package (which bundles up Mercurial, some extensions, and our configs for our users), and I want to minimise the work we have to do to keep the automatic builds working. -- Simon Farnsworth ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] match: adding non-recursive directory matching
Sending updated patch via pushgate (description changed). On Mon, Oct 24, 2016 at 10:34 AM, Rodrigo Damaziowrote: > It sounds like we'd like to do 3 somewhat orthogonal things: > - allow user to specify the directory the pattern is relative to > (root/cwd/any) > - allow the user to specify recursiveness/non-recursiveness consistently > (not covered by the *path patterns, but could be the defined behavior for > the globs) > - clean up the matcher API (discussed during Sprint) > > Doing all 3 together would probably take some time and a lot of > back-and-forth, so I'm wondering if it'd be ok to start by updating this > patch to implement "rootglob" with consistent recursiveness behavior, and > we can then more slowly add the other patterns and converge on a cleaner > API? > > Also, for discussion: I assume the *path patterns will be recursive when > they reference a directory. Do we also want a non-recursive equivalent > (rootexact, rootfiles, rootnonrecursive or something like that)? > > Thanks > Rodrigo > > > > On Mon, Oct 24, 2016 at 6:21 AM, Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >> >> >> On 10/21/2016 05:13 PM, FUJIWARA Katsunori wrote: >> >>> At Tue, 18 Oct 2016 10:12:07 -0400, >>> Augie Fackler wrote: >>> On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara wrote: > On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote: > >> On Oct 18, 2016, at 09:38, Yuya Nishihara wrote: >>> After coordinating on irc to figure out what this proposal actually is, I've noticed that the semantics of this "exact" proposal are exactly what "glob" does today, which means (I think) that "files:foo/bar" should be representable as "glob:foo/bar/*" - what am I missing? >>> >>> Maybe we want a "glob" relative to the repo root? >>> >> >> As far as I can tell, it already is. "relglob:" is relative to your >> location in the repo according to the docs. >> > > Unfortunately that isn't. > > 'glob:' - a glob relative to cwd > 'relglob:' - an unrooted glob (*.c matches C files in > all dirs) > > Don't ask me why. ;-) > Oh wat. It looks like narrowhg might change this behavior in narrowed repositories, thus my additional confusion. Maybe we should add "absglob" that is always repo-root-absolute. How do we feel about that overall? >>> >>> FYI, current pattern matching is implemented as below. This was >>> chatted in "non-recursive directory matching" session of 4.0 sprint, >>> and sorry for my late posting of this translation from >>> http://d.hatena.ne.jp/flying-foozy/20140107/1389087728 in Japanese, as >>> my backlog of the last sprint. >>> >>> === === === >>> pattern type root-ed cwd-ed any-of-path >>> === === === >>> wildcard --- globrelglob >>> regexp re --- relre >>> raw string pathrelpath --- >>> === === === >>> >>> If rule is read in from file (e.g. .hgignore): >>> >>> * "glob" is treated as "relglob" >>> * "re" is treated as "relre" >>> >>> This is mentioned in "hg help patterns" and "hg help hgignore", but >>> syntax name "relglob" and "relre" themselves aren't explained. >>> >>> "end of name" matching is required: >>> >>> * for glob/relglob as PATTERN (e.g. argument in command line), but >>> * not for glob/relglob as INCLUDES/EXCLUDES, or other pattern >>> syntaxes >>> >>> For example, file "foo/bar/baz" is: >>> >>> * not matched at "hg files glob:foo/bar" >>> * but matched at "hg file -I glob:foo/bar" >>> >>> This isn't mentioned in any help document :-<, and the latter seems >>> to cause the issue mentioned in this patch series. >>> >>> How about introducing new systematic names like below to re-organize >>> current complicated mapping between names and matching ? (and enable >>> "end of name" matching by "-eon" suffix or so) >>> >>> === === >>> pattern type root-ed cwd-ed any-of-path >>> === === >>> wildcard rootglob cwdglob anyglob >>> regexp rootre cwdre anyre >>> raw string rootpath cwdpath anypath >>> === === >>> >> >> Moving toward a more regular and clear feature set and naming seems a >> win. I'm +1 for moving in that direction. >> >> Cheers, >> >> -- >> Pierre-Yves David >> > > ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel