Re: [PATCH 2 of 2 V2] streamclone: abort when client needs to handle obsmarkers, but doesn't
On Wed, 31 Oct 2018 12:48:49 -0700 Gregory Szorc wrote: > On Thu, Oct 18, 2018 at 6:53 AM Anton Shestakov wrote: > > > # HG changeset patch > > # User Anton Shestakov > > # Date 1538754012 -28800 > > # Fri Oct 05 23:40:12 2018 +0800 > > # Node ID 7827e8870afe4a1505767a748dd07e94569196ac > > # Parent 212b1f69138c7d1fa166356448305219259f34f9 > > # EXP-Topic stream-obsmarkers > > streamclone: abort when client needs to handle obsmarkers, but doesn't > > > > When client doesn't have any of obsolescence markers exchange capabilities, > > then it's safe to say it can't handle obsmarkers. However, if it > > understands > > even one format version, then stream clones are fine -- client can use > > "obsmarkers" bundle2 part. > > > > I'm tempted to say we should try to get this into 4.8. Looks like it was quietly pushed before 4.8rc0 was cut, so it's in. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] lfs: register the flag processors per repository
> On Oct 31, 2018, at 3:20 PM, Gregory Szorc wrote:
>
>> On Thu, Oct 4, 2018 at 9:48 PM Matt Harbison wrote:
>> On Thu, 04 Oct 2018 14:35:49 -0400, Gregory Szorc
>> wrote:
>>
>> > On Thu, Oct 4, 2018 at 6:09 AM Yuya Nishihara wrote:
>> >
>> >> On Thu, 04 Oct 2018 00:39:12 -0400, Matt Harbison wrote:
>> >> > # HG changeset patch
>> >> > # User Matt Harbison
>> >> > # Date 1538626646 14400
>> >> > # Thu Oct 04 00:17:26 2018 -0400
>> >> > # Node ID e010a7be6dc96ea7d48be81a7c5e8a8ed8bf6c31
>> >> > # Parent 7a347d362a455d84bccf34347171d89724b9c9df
>> >> > lfs: register the flag processors per repository
>> >>
>> >> > +if b'lfs' in requirements:
>> >> > +options[b'enableextstored'] = True
>> >> > +
>> >> > if repository.NARROW_REQUIREMENT in requirements:
>> >> > options[b'enableellipsis'] = True
>> >> >
>> >> > diff --git a/mercurial/revlog.py b/mercurial/revlog.py
>> >> > --- a/mercurial/revlog.py
>> >> > +++ b/mercurial/revlog.py
>> >> > @@ -110,6 +110,26 @@ parsers = policy.importmod(r'parsers')
>> >> > REVIDX_ISCENSORED: None,
>> >> > }
>> >> >
>> >> > +# Flag processors for REVIDX_EXTSTORED.
>> >> > +def extstoredreadprocessor(rl, text):
>> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
>> >> without'
>> >> > + b' wrapping processor function')
>> >> > +
>> >> > +def extstoredwriteprocessor(rl, text):
>> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
>> >> without'
>> >> > + b' wrapping processor function')
>> >> > +
>> >> > +def extstoredrawprocessor(rl, text):
>> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
>> >> without'
>> >> > + b' wrapping processor function')
>> >> > +
>> >> > +# Lambdas are needed here so that these methods can be wrapped by
>> >> lfs.
>> >> > +extstoredprocessor = (
>> >> > +lambda rl, text: extstoredreadprocessor(rl, text),
>> >> > +lambda rl, text: extstoredwriteprocessor(rl, text),
>> >> > +lambda rl, text: extstoredrawprocessor(rl, text),
>> >> > +)
>> >> > +
>> >> > # Flag processors for REVIDX_ELLIPSIS.
>> >> > def ellipsisreadprocessor(rl, text):
>> >> > return text, False
>> >> > @@ -405,6 +425,8 @@ class revlog(object):
>> >> > self._srdensitythreshold =
>> >> opts['sparse-read-density-threshold']
>> >> > if 'sparse-read-min-gap-size' in opts:
>> >> > self._srmingapsize = opts['sparse-read-min-gap-size']
>> >> > +if opts.get('enableextstored'):
>> >> > +self._flagprocessors[REVIDX_EXTSTORED] =
>> >> extstoredprocessor
>> >>
>> >> I feel it's awkward that we have to wrap the stub extstoredprocessor and
>> >> pass in enableextstored=True.
>> >>
>> >> I don't have a concrete idea, but maybe we can provide an API to
>> >> register
>> >> a stock flagprocessor which won't be copied to the revlog instance by
>> >> default.
>> >>
>> >
>> > I also found this a bit awkward.
>> >
>> > I wrote up a patch a few weeks ago that added an "extraflagprocessors"
>> > argument or some such to revlog.__init__ that would allow extra flag
>> > processors to be passed in. I never submitted it because I had originally
>> > wrote it for censoring and I solved that problem by moving the censor
>> > flag
>> > processor into revlog.py and introduced the "censorable=False" argument
>> > instead.
>> >
>> > But the flag processor for LFS is in the same boat and we may want to do
>> > something similar. But since LFS's flag processors require code in the
>> > LFS
>> > extension, we can't simply move the flag processors code to revlog.py.
>> >
>> > I think our best bet is to pass a flag processor into revlog.__init__ -
>> > either via an argument or as a key in the store/opener options. Store
>> > options is simpler, as we'd only need to teach revlog.py to add extra
>> > flag
>> > processors defined in a store options key and the LFS extension would
>> > only
>> > need to monkeypatch localrepo.resolverevlogstorevfsoptions(). Adding an
>> > argument to revlog.__init__ requires a bit more work to thread through
>> > everything. If the LFS flag processor code were in core, I'd be fine with
>> > introducing that argument. But since it isn't, I think going through the
>> > store options is the way to go.
>>
>> Should the revlog.addflagprocessor() method be copied to localrepo so that
>> it still does the validation, and can also hide the fact that it's being
>> tacked on to the store options?
>
> Found this email when triaging my inbox.
>
> I know some other flag processor changes landed after this. Are you satisfied
> with the current state of things or do you think we should do more?
I think what we have is sufficient for now anyway.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
mercurial@40446: 3 new changesets (3 on stable)
3 new changesets (3 on stable) in mercurial: https://www.mercurial-scm.org/repo/hg/rev/256b1f0c24e8 changeset: 40444:256b1f0c24e8 branch: stable parent: 40431:8ebb05f747e5 user:Boris Feld date:Mon Oct 29 17:26:25 2018 +0100 summary: changegroup: introduce an explicit linear sorting https://www.mercurial-scm.org/repo/hg/rev/634b45317459 changeset: 40445:634b45317459 branch: stable user:Boris Feld date:Wed Oct 31 12:08:37 2018 -0700 summary: changegroup: restore default node ordering (issue6001) https://www.mercurial-scm.org/repo/hg/rev/b6bc2293cdf3 changeset: 40446:b6bc2293cdf3 branch: stable tag: tip user:"Paul Morelle https://www.mercurial-scm.org/repo/hg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] setup: explain to distutils how we write rc versions
On Wed, Oct 31, 2018 at 1:14 PM Paul Morelle wrote: > # HG changeset patch > # User "Paul Morelle # Date 1541014362 -3600 > # Wed Oct 31 20:32:42 2018 +0100 > # Node ID 5f86fca43d2ac438aeb3e482fc713906947f2abd > # Parent 5e5c8f2a1eb5f050a7d13b6f1b6a21fbc2fd1b65 > # EXP-Topic rc-versions > # Available At https://bitbucket.org/octobus/mercurial-devel/ > # hg pull https://bitbucket.org/octobus/mercurial-devel/ -r > 5f86fca43d2a > setup: explain to distutils how we write rc versions > Queued for stable. > > When we use a rc version number (e.g. 4.8rc0), bdist_msi is using > distutils.StrictVersion to parse it into a tuple of numbers. > By default, StrictVersion.version_re only recognizes [ab] for alpha/beta, > where mercurial may use '-rc' or 'rc'. > This change makes StrictVersion parse correctly our version numbers, so > that > bdist_msi doesn't fail on rc versions. > > diff -r 5e5c8f2a1eb5 -r 5f86fca43d2a setup.py > --- a/setup.py Tue Oct 23 21:11:13 2018 +0900 > +++ b/setup.py Wed Oct 31 20:32:42 2018 +0100 > @@ -168,6 +168,9 @@ > from distutils.sysconfig import get_python_inc, get_config_var > from distutils.version import StrictVersion > > +# Explain to distutils.StrictVersion how our release candidates are > versionned > +StrictVersion.version_re = > re.compile(r'^(\d+)\.(\d+)(\.(\d+))?-?(rc(\d+))?$') > + > def write_if_changed(path, content): > """Write content to a file iff the content hasn't changed.""" > if os.path.exists(path): > ___ > 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@40443: 2 new changesets
2 new changesets in mercurial: https://www.mercurial-scm.org/repo/hg/rev/d69cf134bd50 changeset: 40442:d69cf134bd50 user:Matt Harbison date:Thu Oct 25 21:04:47 2018 -0400 summary: tests: glob over a single quote vs double quote difference on Windows https://www.mercurial-scm.org/repo/hg/rev/909c31805f54 changeset: 40443:909c31805f54 bookmark:@ tag: tip user:Matt Harbison date:Thu Oct 25 22:13:22 2018 -0400 summary: py3: roll up threading.Thread constructor args into **kwargs -- Repository URL: https://www.mercurial-scm.org/repo/hg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] setup: explain to distutils how we write rc versions
# HG changeset patch # User "Paul Morelle https://bitbucket.org/octobus/mercurial-devel/ # hg pull https://bitbucket.org/octobus/mercurial-devel/ -r 5f86fca43d2a setup: explain to distutils how we write rc versions When we use a rc version number (e.g. 4.8rc0), bdist_msi is using distutils.StrictVersion to parse it into a tuple of numbers. By default, StrictVersion.version_re only recognizes [ab] for alpha/beta, where mercurial may use '-rc' or 'rc'. This change makes StrictVersion parse correctly our version numbers, so that bdist_msi doesn't fail on rc versions. diff -r 5e5c8f2a1eb5 -r 5f86fca43d2a setup.py --- a/setup.py Tue Oct 23 21:11:13 2018 +0900 +++ b/setup.py Wed Oct 31 20:32:42 2018 +0100 @@ -168,6 +168,9 @@ from distutils.sysconfig import get_python_inc, get_config_var from distutils.version import StrictVersion +# Explain to distutils.StrictVersion how our release candidates are versionned +StrictVersion.version_re = re.compile(r'^(\d+)\.(\d+)(\.(\d+))?-?(rc(\d+))?$') + def write_if_changed(path, content): """Write content to a file iff the content hasn't changed.""" if os.path.exists(path): ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5163: filelog: add a hasnode() method (API)
indygreg added inline comments. INLINE COMMENTS > martinvonz wrote in filelog.py:41 > node can be nullrev? That was me possibly being a bit overzealous. We should consider removing it. I may have added it because `revlog.rev()` seems to always support `nullid` and `nullrev`, so you need to check for both explicitly at higher levels. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5163 To: indygreg, #hg-reviewers Cc: martinvonz, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Mercurial match the options?
On Thu, Oct 18, 2018 at 7:07 AM bo0od wrote: > Hi There, > > i have sent this request before through the mailing list using susimail > before, but it seems that im not receiving the replies back. Thus im > using this email instead. I hope i did not disturb the mailing list. > sorry for inconvenient: > > " > Im from I2P community and our developers using Monotone to develop the > famous anonymous protocol I2P (or the invisible internet project). > > Sadly monotone project died since 4 years ago, so we want to have > alternative. > > our conditions to make the development software to work well (specially > with I2P) , to have these criteria: > > - supports resume > Supporting resume is difficult in the existing Mercurial wire protocol. The good news is we are actively rewriting the wire protocol from scratch and the new design is intrinsically much more compatible with resume. I anticipate that resume will be implemented shortly after the new wire protocol is stabilized, which hopefully is some time in 2019. > - key signed checkins > - revocation of keys/trust function implementation > This is a hard problem. And Monotone arguably has one of the better solutions of any VCS. We have some notes at https://www.mercurial-scm.org/wiki/CommitSigningPlan for where we could potentially go here. But we haven't made any firm decisions. Nor have we prioritized the work. The feature will likely come into existence when someone is willing to spend the time to implement a feature. Until someone is lined up to do the work, I'm not convinced it is worthwhile to spend the (considerable) time to design a solution. > - easy migration of mtn history into new system > `hg convert` supports ingesting data from a number of VCS systems. It has a source for Monotone. How well it works, I'm not sure. Given Monotone's relative age and popularity, I'm guessing it may be a bit slow and buggy. Patches to improve it will be welcomed. > > does Mercurial support these options? if no, is it on the road map? if no, > then why not? > > Thank You!" > > feel free to reply on this email > ___ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel > ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2 V2] streamclone: abort when client needs to handle obsmarkers, but doesn't
On Thu, Oct 18, 2018 at 6:53 AM Anton Shestakov wrote:
> # HG changeset patch
> # User Anton Shestakov
> # Date 1538754012 -28800
> # Fri Oct 05 23:40:12 2018 +0800
> # Node ID 7827e8870afe4a1505767a748dd07e94569196ac
> # Parent 212b1f69138c7d1fa166356448305219259f34f9
> # EXP-Topic stream-obsmarkers
> streamclone: abort when client needs to handle obsmarkers, but doesn't
>
> When client doesn't have any of obsolescence markers exchange capabilities,
> then it's safe to say it can't handle obsmarkers. However, if it
> understands
> even one format version, then stream clones are fine -- client can use
> "obsmarkers" bundle2 part.
>
I'm tempted to say we should try to get this into 4.8. But the patch won't
apply cleanly without part 1.
Also, if this does land, it represents a behavior different from stream
clone version 1. I think that is OK, as the new behavior of rejecting to
clone hidden changesets when they will become visible again seems correct.
>
> diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
> --- a/mercurial/bundle2.py
> +++ b/mercurial/bundle2.py
> @@ -1700,7 +1700,10 @@ def addpartbundlestream2(bundler, repo,
> includeobsmarkers = False
> if repo.obsstore:
> remoteversions = obsmarkersversion(bundler.capabilities)
> -if repo.obsstore._version in remoteversions:
> +if not remoteversions:
> +raise error.Abort(_('server has obsolescence markers, but
> client '
> +'cannot receive them via stream clone'))
> +elif repo.obsstore._version in remoteversions:
> includeobsmarkers = True
>
> filecount, bytecount, it = streamclone.generatev2(repo, includepats,
> diff --git a/tests/test-clone-uncompressed.t
> b/tests/test-clone-uncompressed.t
> --- a/tests/test-clone-uncompressed.t
> +++ b/tests/test-clone-uncompressed.t
> @@ -556,6 +556,12 @@ Clone non-publishing with obsolescence
>$ hg debugobsolete -R with-obsolescence
>50382b884f66690b7045cac93a540cba4d4c906f 0
> {c17445101a72edac06facd130d14808dfbd5c7c2} (Thu Jan 01 00:00:00 1970 +)
> {'user': 'test'}
>
> + $ hg clone -U --stream --config experimental.evolution=0
> http://localhost:$HGPORT with-obsolescence-no-evolution
> + streaming all changes
> + remote: abort: server has obsolescence markers, but client cannot
> receive them via stream clone
> + abort: pull failed on remote
> + [255]
> +
>$ killdaemons.py
>
> #endif
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 2 V2] streamclone: include obsstore file into stream bundle if client can read it
On Thu, Oct 18, 2018 at 6:51 AM Anton Shestakov wrote:
> # HG changeset patch
> # User Anton Shestakov
> # Date 1538753237 -28800
> # Fri Oct 05 23:27:17 2018 +0800
> # Node ID 212b1f69138c7d1fa166356448305219259f34f9
> # Parent 89cba88e95ed84b6e5e49ecc51ebf7119cfaa6b4
> # EXP-Topic stream-obsmarkers
> streamclone: include obsstore file into stream bundle if client can read it
>
I attempted to look at this patch but it didn't apply.
Could you please rebase?
>
> diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
> --- a/mercurial/bundle2.py
> +++ b/mercurial/bundle2.py
> @@ -1697,8 +1697,15 @@ def addpartbundlestream2(bundler, repo,
> if (includepats or excludepats) and not narrowstream:
> raise error.Abort(_('server does not support narrow stream
> clones'))
>
> +includeobsmarkers = False
> +if repo.obsstore:
> +remoteversions = obsmarkersversion(bundler.capabilities)
> +if repo.obsstore._version in remoteversions:
> +includeobsmarkers = True
> +
> filecount, bytecount, it = streamclone.generatev2(repo, includepats,
> - excludepats)
> + excludepats,
> + includeobsmarkers)
> requirements = _formatrequirementsspec(repo.requirements)
> part = bundler.newpart('stream2', data=it)
> part.addparam('bytecount', '%d' % bytecount, mandatory=True)
> diff --git a/mercurial/streamclone.py b/mercurial/streamclone.py
> --- a/mercurial/streamclone.py
> +++ b/mercurial/streamclone.py
> @@ -532,7 +532,7 @@ def _emit2(repo, entries, totalfilesize)
> finally:
> fp.close()
>
> -def generatev2(repo, includes, excludes):
> +def generatev2(repo, includes, excludes, includeobsmarkers):
> """Emit content for version 2 of a streaming clone.
>
> the data stream consists the following entries:
> @@ -567,6 +567,9 @@ def generatev2(repo, includes, excludes)
> if repo.svfs.exists(name):
> totalfilesize += repo.svfs.lstat(name).st_size
> entries.append((_srcstore, name, _filefull, None))
> +if includeobsmarkers and repo.svfs.exists('obsstore'):
> +totalfilesize += repo.svfs.lstat('obsstore').st_size
> +entries.append((_srcstore, 'obsstore', _filefull, None))
> for name in cacheutil.cachetocopy(repo):
> if repo.cachevfs.exists(name):
> totalfilesize += repo.cachevfs.lstat(name).st_size
> diff --git a/tests/test-clone-uncompressed.t
> b/tests/test-clone-uncompressed.t
> --- a/tests/test-clone-uncompressed.t
> +++ b/tests/test-clone-uncompressed.t
> @@ -514,3 +514,48 @@ stream v1 unsuitable for non-publishing
> #endif
>
>$ killdaemons.py
> +
> +#if stream-legacy
> +
> +With v1 of the stream protocol, changeset are always cloned as public.
> There's
> +no obsolescence markers exchange in stream v1.
> +
> +#endif
> +#if stream-bundle2
> +
> +Stream repository with obsolescence
> +---
> +
> +Clone non-publishing with obsolescence
> +
> + $ cat >> $HGRCPATH << EOF
> + > [experimental]
> + > evolution=all
> + > EOF
> +
> + $ cd server
> + $ echo foo > foo
> + $ hg -q commit -m 'about to be pruned'
> + $ hg debugobsolete `hg log -r . -T '{node}'` -d '0 0' -u test
> --record-parents
> + obsoleted 1 changesets
> + $ hg up null -q
> + $ hg log -T '{rev}: {phase}\n'
> + 1: draft
> + 0: draft
> + $ hg serve -p $HGPORT -d --pid-file=hg.pid
> + $ cat hg.pid > $DAEMON_PIDS
> + $ cd ..
> +
> + $ hg clone -U --stream http://localhost:$HGPORT with-obsolescence
> + streaming all changes
> + 1035 files to transfer, 97.1 KB of data
> + transferred 97.1 KB in * seconds (* */sec) (glob)
> + $ hg -R with-obsolescence log -T '{rev}: {phase}\n'
> + 1: draft
> + 0: draft
> + $ hg debugobsolete -R with-obsolescence
> + 50382b884f66690b7045cac93a540cba4d4c906f 0
> {c17445101a72edac06facd130d14808dfbd5c7c2} (Thu Jan 01 00:00:00 1970 +)
> {'user': 'test'}
> +
> + $ killdaemons.py
> +
> +#endif
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] lfs: register the flag processors per repository
On Thu, Oct 4, 2018 at 9:48 PM Matt Harbison wrote:
> On Thu, 04 Oct 2018 14:35:49 -0400, Gregory Szorc
> wrote:
>
> > On Thu, Oct 4, 2018 at 6:09 AM Yuya Nishihara wrote:
> >
> >> On Thu, 04 Oct 2018 00:39:12 -0400, Matt Harbison wrote:
> >> > # HG changeset patch
> >> > # User Matt Harbison
> >> > # Date 1538626646 14400
> >> > # Thu Oct 04 00:17:26 2018 -0400
> >> > # Node ID e010a7be6dc96ea7d48be81a7c5e8a8ed8bf6c31
> >> > # Parent 7a347d362a455d84bccf34347171d89724b9c9df
> >> > lfs: register the flag processors per repository
> >>
> >> > +if b'lfs' in requirements:
> >> > +options[b'enableextstored'] = True
> >> > +
> >> > if repository.NARROW_REQUIREMENT in requirements:
> >> > options[b'enableellipsis'] = True
> >> >
> >> > diff --git a/mercurial/revlog.py b/mercurial/revlog.py
> >> > --- a/mercurial/revlog.py
> >> > +++ b/mercurial/revlog.py
> >> > @@ -110,6 +110,26 @@ parsers = policy.importmod(r'parsers')
> >> > REVIDX_ISCENSORED: None,
> >> > }
> >> >
> >> > +# Flag processors for REVIDX_EXTSTORED.
> >> > +def extstoredreadprocessor(rl, text):
> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
> >> without'
> >> > + b' wrapping processor function')
> >> > +
> >> > +def extstoredwriteprocessor(rl, text):
> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
> >> without'
> >> > + b' wrapping processor function')
> >> > +
> >> > +def extstoredrawprocessor(rl, text):
> >> > +raise error.ProgrammingError(b'extstored flags processor enabled
> >> without'
> >> > + b' wrapping processor function')
> >> > +
> >> > +# Lambdas are needed here so that these methods can be wrapped by
> >> lfs.
> >> > +extstoredprocessor = (
> >> > +lambda rl, text: extstoredreadprocessor(rl, text),
> >> > +lambda rl, text: extstoredwriteprocessor(rl, text),
> >> > +lambda rl, text: extstoredrawprocessor(rl, text),
> >> > +)
> >> > +
> >> > # Flag processors for REVIDX_ELLIPSIS.
> >> > def ellipsisreadprocessor(rl, text):
> >> > return text, False
> >> > @@ -405,6 +425,8 @@ class revlog(object):
> >> > self._srdensitythreshold =
> >> opts['sparse-read-density-threshold']
> >> > if 'sparse-read-min-gap-size' in opts:
> >> > self._srmingapsize = opts['sparse-read-min-gap-size']
> >> > +if opts.get('enableextstored'):
> >> > +self._flagprocessors[REVIDX_EXTSTORED] =
> >> extstoredprocessor
> >>
> >> I feel it's awkward that we have to wrap the stub extstoredprocessor and
> >> pass in enableextstored=True.
> >>
> >> I don't have a concrete idea, but maybe we can provide an API to
> >> register
> >> a stock flagprocessor which won't be copied to the revlog instance by
> >> default.
> >>
> >
> > I also found this a bit awkward.
> >
> > I wrote up a patch a few weeks ago that added an "extraflagprocessors"
> > argument or some such to revlog.__init__ that would allow extra flag
> > processors to be passed in. I never submitted it because I had originally
> > wrote it for censoring and I solved that problem by moving the censor
> > flag
> > processor into revlog.py and introduced the "censorable=False" argument
> > instead.
> >
> > But the flag processor for LFS is in the same boat and we may want to do
> > something similar. But since LFS's flag processors require code in the
> > LFS
> > extension, we can't simply move the flag processors code to revlog.py.
> >
> > I think our best bet is to pass a flag processor into revlog.__init__ -
> > either via an argument or as a key in the store/opener options. Store
> > options is simpler, as we'd only need to teach revlog.py to add extra
> > flag
> > processors defined in a store options key and the LFS extension would
> > only
> > need to monkeypatch localrepo.resolverevlogstorevfsoptions(). Adding an
> > argument to revlog.__init__ requires a bit more work to thread through
> > everything. If the LFS flag processor code were in core, I'd be fine with
> > introducing that argument. But since it isn't, I think going through the
> > store options is the way to go.
>
> Should the revlog.addflagprocessor() method be copied to localrepo so
> that
> it still does the validation, and can also hide the fact that it's being
> tacked on to the store options?
>
Found this email when triaging my inbox.
I know some other flag processor changes landed after this. Are you
satisfied with the current state of things or do you think we should do
more?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D4750: filelog: stop proxying rawsize() (API)
indygreg added a subscriber: durin42. indygreg added a comment. In https://phab.mercurial-scm.org/D4750#73744, @mharbison72 wrote: > Apparently thg uses this to avoid loading the data into memory just to figure out the length like fctx.rawsize(). Any suggestions? > > https://groups.google.com/d/msg/thg-dev/6ekYID7ho_o/fbdd6rVDAwAJ Just found this comment when going through mail backlog. Do we want to do anything about this before the 4.8 release? We could restore the method/proxy easily enough. But I would prefer not to. I'd really like to know why thg wants to access the size of a revision without accessing the revision text... CC @durin42 REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D4750 To: indygreg, #hg-reviewers Cc: durin42, mharbison72, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
mercurial@40441: 11 new changesets (1 on stable)
11 new changesets (1 on stable) in mercurial: https://www.mercurial-scm.org/repo/hg/rev/8ebb05f747e5 changeset: 40431:8ebb05f747e5 branch: stable parent: 40429:14b6afc6cb28 user:Yuya Nishihara date:Wed Oct 31 21:16:54 2018 +0900 summary: fix: disable use of thread-based worker https://www.mercurial-scm.org/repo/hg/rev/968dd7e02ac5 changeset: 40432:968dd7e02ac5 parent: 40430:6a917075535a user:Boris Feld date:Wed Oct 10 00:21:02 2018 +0200 summary: changegroup: allow to force delta to be against p1 https://www.mercurial-scm.org/repo/hg/rev/808b762679cd changeset: 40433:808b762679cd user:Boris Feld date:Thu Oct 18 12:31:06 2018 +0200 summary: changegroup: add a option to create bundle with full snapshot only https://www.mercurial-scm.org/repo/hg/rev/3c0d5016b2be changeset: 40434:3c0d5016b2be user:Mads Kiilerich date:Sun Oct 14 17:08:18 2018 +0200 summary: graft: introduce --base option for using custom base revision while merging https://www.mercurial-scm.org/repo/hg/rev/d362a41ee5dd changeset: 40435:d362a41ee5dd user:Pulkit Goyal date:Tue Oct 23 14:26:17 2018 +0300 summary: tests: show that adding an already included path still calls narrow_widen() https://www.mercurial-scm.org/repo/hg/rev/30a7d3b6b281 changeset: 40436:30a7d3b6b281 user:Pulkit Goyal date:Tue Oct 23 16:24:04 2018 +0300 summary: narrow: rework logic to check whether we need to widen and narrow https://www.mercurial-scm.org/repo/hg/rev/a0e7fa019290 changeset: 40437:a0e7fa019290 user:Boris Feld date:Tue Oct 23 19:20:22 2018 +0200 summary: storage: update sqlitestore to use the new `deltamode` parameter https://www.mercurial-scm.org/repo/hg/rev/5d8f291405e5 changeset: 40438:5d8f291405e5 user:Martin von Zweigbergk date:Tue Oct 23 14:04:17 2018 -0700 summary: narrow: replace filtering in list comprehension by set operations https://www.mercurial-scm.org/repo/hg/rev/25f1c7bd649d changeset: 40439:25f1c7bd649d user:Matt DeVore date:Wed Oct 17 15:48:01 2018 -0700 summary: blackbox: add configitem for format of log timestamps https://www.mercurial-scm.org/repo/hg/rev/09a37a5d8f5d changeset: 40440:09a37a5d8f5d user:Augie Fackler date:Fri Oct 12 12:30:47 2018 -0400 summary: extensions: fix up many many debug logs that use %r https://www.mercurial-scm.org/repo/hg/rev/005bc856e919 changeset: 40441:005bc856e919 bookmark:@ tag: tip user:Augie Fackler date:Tue Oct 23 11:31:33 2018 -0400 summary: py3: port test-log-exthook.t to Python 3 -- Repository URL: https://www.mercurial-scm.org/repo/hg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5196: changegroup: restore default node ordering (issue6001)
This revision was automatically updated to reflect the committed changes. Closed by commit rHG634b45317459: changegroup: restore default node ordering (issue6001) (authored by lothiraldan, committed by ). CHANGED PRIOR TO COMMIT https://phab.mercurial-scm.org/D5196?vs=12346=12354#toc REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D5196?vs=12346=12354 REVISION DETAIL https://phab.mercurial-scm.org/D5196 AFFECTED FILES mercurial/utils/storageutil.py tests/test-generaldelta.t CHANGE DETAILS diff --git a/tests/test-generaldelta.t b/tests/test-generaldelta.t --- a/tests/test-generaldelta.t +++ b/tests/test-generaldelta.t @@ -279,61 +279,61 @@ 14 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R relax-chain debugdeltachain -m rev chain# chainlen prev delta sizerawsize chainsize ratio lindist extradist extraratio -0 11 -1base 47 46 47 1.0217447 00.0 -1 120 p1 58 92105 1.14130 105 00.0 -2 131 p1 58138163 1.18116 163 00.0 -3 142 p1 58184221 1.20109 221 00.0 -4 153 p1 58230279 1.21304 279 00.0 -5 164 p1 58276337 1.22101 337 00.0 -6 175 p1 58322395 1.22671 395 00.0 -7 186 p1 58368453 1.23098 453 00.0 -8 197 p1 58414511 1.23430 511 00.0 -9 1 108 p1 58460569 1.23696 569 00.0 - 10 1 119 p1 58506627 1.23913 627 00.0 - 11 1 12 10 p1 58552685 1.24094 685 00.0 - 12 1 13 11 p1 58598743 1.24247 743 00.0 - 13 1 14 12 p1 58644801 1.24379 801 00.0 - 14 1 15 13 p1 58690859 1.24493 859 00.0 - 15 1 16 14 p1 58736917 1.24592 917 00.0 - 16 1 17 15 p1 58782975 1.24680 975 00.0 - 17 1 18 16 p1 58828 1033 1.24758 1033 00.0 - 18 1 19 17 p1 58874 1091 1.24828 1091 00.0 - 19 1 20 18 p1 58920 1149 1.24891 1149 00.0 - 20 1 21 19 p1 58966 1207 1.24948 1207 00.0 - 21 1 22 20 p1 58 1012 1265 1.25000 1265 00.0 - 22 1 23 21 p1 58 1058 1323 1.25047 1323 00.0 - 23 1 24 22 p1 58 1104 1381 1.25091 1381 00.0 - 24 1 25 23 p1 58 1150 1439 1.25130 1439 00.0 - 25 1 26 24 p1 58 1196 1497 1.25167 1497 00.0 - 26 1 27 25 p1 58 1242 1555 1.25201 1555 00.0 - 27 1 28 26 p1 58 1288 1613 1.25233 1613 00.0 - 28 1 29 27 p1 58 1334 1671 1.25262 1671 00.0 - 29 1 30 28 p1 58 1380 1729 1.25290 1729 00.0 - 30 1 31 29 p1 58 1426 1787 1.25316 1787 00.0 - 31 21 -1base 46 45 46 1.046 00.0 - 32 22 31 p1 57 90103 1.1 103 00.0 - 33 23 32 p1 57135160 1.18519 160
D5195: changegroup: introduce an explicit linear sorting
This revision was automatically updated to reflect the committed changes.
Closed by commit rHG256b1f0c24e8: changegroup: introduce an explicit linear
sorting (authored by lothiraldan, committed by ).
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST UPDATE
https://phab.mercurial-scm.org/D5195?vs=12345=12353
REVISION DETAIL
https://phab.mercurial-scm.org/D5195
AFFECTED FILES
hgext/sqlitestore.py
mercurial/revlog.py
CHANGE DETAILS
diff --git a/mercurial/revlog.py b/mercurial/revlog.py
--- a/mercurial/revlog.py
+++ b/mercurial/revlog.py
@@ -2206,7 +2206,7 @@
def emitrevisions(self, nodes, nodesorder=None, revisiondata=False,
assumehaveparentrevisions=False, deltaprevious=False):
-if nodesorder not in ('nodes', 'storage', None):
+if nodesorder not in ('nodes', 'storage', 'linear', None):
raise error.ProgrammingError('unhandled value for nodesorder: %s' %
nodesorder)
diff --git a/hgext/sqlitestore.py b/hgext/sqlitestore.py
--- a/hgext/sqlitestore.py
+++ b/hgext/sqlitestore.py
@@ -559,7 +559,7 @@
def emitrevisions(self, nodes, nodesorder=None, revisiondata=False,
assumehaveparentrevisions=False, deltaprevious=False):
-if nodesorder not in ('nodes', 'storage', None):
+if nodesorder not in ('nodes', 'storage', 'linear', None):
raise error.ProgrammingError('unhandled value for nodesorder: %s' %
nodesorder)
To: lothiraldan, indygreg, #hg-reviewers
Cc: yuja, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5196: changegroup: restore default node ordering (issue6001)
indygreg accepted this revision. indygreg added a comment. This revision is now accepted and ready to land. https://phab.mercurial-scm.org/rHGdb5501d93bcf6ada3426a45e901094fd877e370f changed a test. I'm surprised this patch doesn't include that revert as well. I'll verify the test as part of landing and amend as necessary. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5196 To: lothiraldan, #hg-reviewers, indygreg Cc: indygreg, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5195: changegroup: introduce an explicit linear sorting
indygreg accepted this revision. indygreg added a comment. This revision is now accepted and ready to land. Yeah, I'm OK with this. There is tons of room to experiment with different ordering techniques - including making it end-user configurable. Having this code in place is a step in the right direction. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5195 To: lothiraldan, indygreg, #hg-reviewers Cc: yuja, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5103: beautifygraph: don't substitute anything for 'X' in rendered graphs
This revision was automatically updated to reflect the committed changes. Closed by commit rHGc2a0bc6412db: beautifygraph: dont substitute anything for X in rendered graphs (authored by hooper, committed by ). REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D5103?vs=12131=12352 REVISION DETAIL https://phab.mercurial-scm.org/D5103 AFFECTED FILES hgext/beautifygraph.py CHANGE DETAILS diff --git a/hgext/beautifygraph.py b/hgext/beautifygraph.py --- a/hgext/beautifygraph.py +++ b/hgext/beautifygraph.py @@ -31,8 +31,6 @@ def prettyedge(before, edge, after): if edge == '~': return '\xE2\x95\xA7' # U+2567 ╧ -if edge == 'X': -return '\xE2\x95\xB3' # U+2573 ╳ if edge == '/': return '\xE2\x95\xB1' # U+2571 ╱ if edge == '-': To: hooper, #hg-reviewers, martinvonz Cc: mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5199: test: fix self._testdir to use ues the right mercurial library during testing
sangeet259 created this revision. Herald added a subscriber: mercurial-devel. Herald added a reviewer: hg-reviewers. REVISION SUMMARY currently if you run tests from some other directory other than the ../tests/, you will get a warning stating warning: Testing with unexpected mercurial lib: mercurial (expected /tmp/hgtests.xx/install/lib/python/mercurial) This is because the the current directory being added to the 'PATH', if the self._testdir != runtestdir, owing to this line if self._testdir != runtestdir: path = [self._testdir] + path Also say you ran the tests from the hg base directory, because directory is being added in the PATH(see the above snippet, at that stage the `self._testdir` has the value as `cwd`, owing to a faulty initialisation). And since the current directory already has the 'hg', that is used in place of the hg that is installed for the testing purposes in `/tmp/hgtests.xx/...`. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5199 AFFECTED FILES tests/run-tests.py CHANGE DETAILS diff --git a/tests/run-tests.py b/tests/run-tests.py --- a/tests/run-tests.py +++ b/tests/run-tests.py @@ -2527,13 +2527,14 @@ os.umask(oldmask) def _run(self, testdescs): +testdir = getcwdb() self._testdir = osenvironb[b'TESTDIR'] = getcwdb() # assume all tests in same folder for now if testdescs: pathname = os.path.dirname(testdescs[0]['path']) if pathname: -osenvironb[b'TESTDIR'] = os.path.join(osenvironb[b'TESTDIR'], - pathname) +testdir = os.path.join(testdir,pathname) +self._testdir = osenvironb[b'TESTDIR'] = testdir if self.options.outputdir: self._outputdir = canonpath(_bytespath(self.options.outputdir)) else: To: sangeet259, #hg-reviewers Cc: mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
mercurial@40430: new changeset
New changeset in mercurial: https://www.mercurial-scm.org/repo/hg/rev/6a917075535a changeset: 40430:6a917075535a bookmark:@ tag: tip parent: 40427:59a870a4ad6e user:Boris Feld date:Tue Oct 09 23:26:35 2018 +0200 summary: storage: also use `deltamode argument` for ifiledata -- Repository URL: https://www.mercurial-scm.org/repo/hg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5194: wireprotov2: add an extension to cache wireproto v2 responses in S3
indygreg added a comment. In https://phab.mercurial-scm.org/D5194#77606, @martinvonz wrote: > Is this useful enough to others that it should live in the hg core repo? It doesn't seem like it to me, but maybe I'm wrong. I think having plug-and-play caching solutions in the official Mercurial distribution would be an extremely compelling product feature. We could tell people "just install Mercurial and add these config options to make your server scale nearly effortlessly." That's a killer feature IMO. S3 is pretty popular as a key-value store and I think there is a market for it. Obviously other cache backends would be useful too. And if we move forward with cache backends in core, we should be prepared to support GCP, Redis, other backends. Whether those are supported in the same extension or in separate extensions, I'm not sure. Time will tell. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5194 To: sheehan, #hg-reviewers Cc: martinvonz, indygreg, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
mercurial@40429: 4 new changesets (3 on stable)
4 new changesets (3 on stable) in mercurial: https://www.mercurial-scm.org/repo/hg/rev/588f1e9a4d16 changeset: 40426:588f1e9a4d16 branch: stable parent: 40422:7e4ffe2719e4 user:Augie Fackler date:Mon Oct 29 16:23:42 2018 -0400 summary: http: work around custom http client classes that refuse extra attrs https://www.mercurial-scm.org/repo/hg/rev/59a870a4ad6e changeset: 40427:59a870a4ad6e bookmark:@ parent: 40425:5e5c8f2a1eb5 user:Boris Feld date:Tue Oct 09 22:02:01 2018 +0200 summary: changegroup: refactor emitrevision to use a `deltamode` argument https://www.mercurial-scm.org/repo/hg/rev/bafa1c4bb7a8 changeset: 40428:bafa1c4bb7a8 branch: stable parent: 40426:588f1e9a4d16 user:Boris Feld date:Wed Oct 31 11:02:08 2018 +0100 summary: sparse-revlog: only refine delta candidates in the sparse case (issue6006) https://www.mercurial-scm.org/repo/hg/rev/14b6afc6cb28 changeset: 40429:14b6afc6cb28 branch: stable tag: tip user:Pulkit Goyal date:Wed Oct 31 15:27:06 2018 +0300 summary: configitems: rename the config to prevent adding an alias in future -- Repository URL: https://www.mercurial-scm.org/repo/hg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH STABLE] fix: disable use of thread-based worker
queued, thanks (worst case we revisit after the freeze if this is too conservative) > On Oct 31, 2018, at 08:34, Yuya Nishihara wrote: > > # HG changeset patch > # User Yuya Nishihara > # Date 1540988214 -32400 > # Wed Oct 31 21:16:54 2018 +0900 > # Branch stable > # Node ID 7dfbc7af72cb0c36717daee3313161a1edd79aa5 > # Parent bafa1c4bb7a8d397f62e0cd75b8064ef1375b753 > fix: disable use of thread-based worker > > getfixes() accesses to repo, changectx, filectx, etc., so I believe there > are code paths triggering data race. Mercurial API isn't thread safe in > general. > > diff --git a/hgext/fix.py b/hgext/fix.py > --- a/hgext/fix.py > +++ b/hgext/fix.py > @@ -157,7 +157,8 @@ def fix(ui, repo, *pats, **opts): > # Don't waste memory/time passing unchanged content back, but > # produce one result per item either way. > yield (rev, path, newdata if newdata != olddata else None) > -results = worker.worker(ui, 1.0, getfixes, tuple(), workqueue) > +results = worker.worker(ui, 1.0, getfixes, tuple(), workqueue, > +threadsafe=False) > > # We have to hold on to the data for each successor revision in memory > # until all its parents are committed. We ensure this by committing > and > ___ > 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
D5195: changegroup: introduce an explicit linear sorting
yuja added a comment. > > > We still need to linearize the revisions in some cases, introduce an explicit > > > `linear` sorting before changing back the default order. > > > > I'm a little confused about this. We do introduce `nodesorder='linear'`, but > > there seems no user of that option. Are there unsent patches? > > > The message should have said `We **may** still need to`. There is no user of that option yet so we can drop it. > > I think we should at least keep the option in `storageutil.emitrevision` so we can experiment around doing a DAG sort for various operations, @indygreg seems to have some perf improvements on the firefox repo with it Got it, thanks. The series looks good, but I leave it to indygreg as he might have a better idea. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5195 To: lothiraldan, indygreg, #hg-reviewers Cc: yuja, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: D5195: changegroup: introduce an explicit linear sorting
> > > We still need to linearize the revisions in some cases, introduce an > explicit > > > `linear` sorting before changing back the default order. > > > > I'm a little confused about this. We do introduce `nodesorder='linear'`, > but > > there seems no user of that option. Are there unsent patches? > > > The message should have said `We **may** still need to`. There is no user > of that option yet so we can drop it. > > I think we should at least keep the option in `storageutil.emitrevision` so > we can experiment around doing a DAG sort for various operations, @indygreg > seems to have some perf improvements on the firefox repo with it Got it, thanks. The series looks good, but I leave it to indygreg as he might have a better idea. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5198: configitems: rename the config to prevent adding an alias in future
This revision was automatically updated to reflect the committed changes.
Closed by commit rHG14b6afc6cb28: configitems: rename the config to prevent
adding an alias in future (authored by pulkit, committed by ).
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST UPDATE
https://phab.mercurial-scm.org/D5198?vs=12349=12350
REVISION DETAIL
https://phab.mercurial-scm.org/D5198
AFFECTED FILES
mercurial/bundle2.py
mercurial/configitems.py
CHANGE DETAILS
diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -610,7 +610,7 @@
coreconfigitem('experimental', 'server.manifestdata.recommended-batch-size',
default=10,
)
-coreconfigitem('experimental.server', 'stream-narrow-clones',
+coreconfigitem('experimental', 'server.stream-narrow-clones',
default=False,
)
coreconfigitem('experimental', 'single-head-per-branch',
diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
--- a/mercurial/bundle2.py
+++ b/mercurial/bundle2.py
@@ -1691,8 +1691,8 @@
includepats = kwargs.get(r'includepats')
excludepats = kwargs.get(r'excludepats')
-narrowstream = repo.ui.configbool('experimental.server',
- 'stream-narrow-clones')
+narrowstream = repo.ui.configbool('experimental',
+ 'server.stream-narrow-clones')
if (includepats or excludepats) and not narrowstream:
raise error.Abort(_('server does not support narrow stream clones'))
To: pulkit, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5195: changegroup: introduce an explicit linear sorting
lothiraldan added a comment. In https://phab.mercurial-scm.org/D5195#77638, @yuja wrote: > > We still need to linearize the revisions in some cases, introduce an explicit > > `linear` sorting before changing back the default order. > > I'm a little confused about this. We do introduce `nodesorder='linear'`, but > there seems no user of that option. Are there unsent patches? The message should have said `We **may** still need to`. There is no user of that option yet so we can drop it. I think we should at least keep the option in `storageutil.emitrevision` so we can experiment around doing a DAG sort for various operations, @indygreg seems to have some perf improvements on the firefox repo with it REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5195 To: lothiraldan, indygreg, #hg-reviewers Cc: yuja, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH STABLE] fix: disable use of thread-based worker
# HG changeset patch # User Yuya Nishihara # Date 1540988214 -32400 # Wed Oct 31 21:16:54 2018 +0900 # Branch stable # Node ID 7dfbc7af72cb0c36717daee3313161a1edd79aa5 # Parent bafa1c4bb7a8d397f62e0cd75b8064ef1375b753 fix: disable use of thread-based worker getfixes() accesses to repo, changectx, filectx, etc., so I believe there are code paths triggering data race. Mercurial API isn't thread safe in general. diff --git a/hgext/fix.py b/hgext/fix.py --- a/hgext/fix.py +++ b/hgext/fix.py @@ -157,7 +157,8 @@ def fix(ui, repo, *pats, **opts): # Don't waste memory/time passing unchanged content back, but # produce one result per item either way. yield (rev, path, newdata if newdata != olddata else None) -results = worker.worker(ui, 1.0, getfixes, tuple(), workqueue) +results = worker.worker(ui, 1.0, getfixes, tuple(), workqueue, +threadsafe=False) # We have to hold on to the data for each successor revision in memory # until all its parents are committed. We ensure this by committing and ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5198: configitems: rename the config to prevent adding an alias in future
pulkit created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.
REVISION SUMMARY
Right now the config option looks like:
[experimental.server]
stream-narrow-clones=
which does not match how config options are generally defined in core. So
let's
rename this to:
[experimental]
server.stream-narrow-clones=
before the new release so that we don't have to add an alias in future for
this.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D5198
AFFECTED FILES
mercurial/bundle2.py
mercurial/configitems.py
CHANGE DETAILS
diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -610,7 +610,7 @@
coreconfigitem('experimental', 'server.manifestdata.recommended-batch-size',
default=10,
)
-coreconfigitem('experimental.server', 'stream-narrow-clones',
+coreconfigitem('experimental', 'server.stream-narrow-clones',
default=False,
)
coreconfigitem('experimental', 'single-head-per-branch',
diff --git a/mercurial/bundle2.py b/mercurial/bundle2.py
--- a/mercurial/bundle2.py
+++ b/mercurial/bundle2.py
@@ -1691,8 +1691,8 @@
includepats = kwargs.get(r'includepats')
excludepats = kwargs.get(r'excludepats')
-narrowstream = repo.ui.configbool('experimental.server',
- 'stream-narrow-clones')
+narrowstream = repo.ui.configbool('experimental',
+ 'server.stream-narrow-clones')
if (includepats or excludepats) and not narrowstream:
raise error.Abort(_('server does not support narrow stream clones'))
To: pulkit, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5195: changegroup: introduce an explicit linear sorting
yuja added a comment. > We still need to linearize the revisions in some cases, introduce an explicit > `linear` sorting before changing back the default order. I'm a little confused about this. We do introduce `nodesorder='linear'`, but there seems no user of that option. Are there unsent patches? REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5195 To: lothiraldan, indygreg, #hg-reviewers Cc: yuja, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: D5195: changegroup: introduce an explicit linear sorting
> We still need to linearize the revisions in some cases, introduce an > explicit > `linear` sorting before changing back the default order. I'm a little confused about this. We do introduce `nodesorder='linear'`, but there seems no user of that option. Are there unsent patches? ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5197: sparse-revlog: only refine delta candidates in the sparse case (issue6006)
This revision was automatically updated to reflect the committed changes. Closed by commit rHGbafa1c4bb7a8: sparse-revlog: only refine delta candidates in the sparse case (issue6006) (authored by lothiraldan, committed by ). REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D5197?vs=12347=12348 REVISION DETAIL https://phab.mercurial-scm.org/D5197 AFFECTED FILES mercurial/revlogutils/deltas.py CHANGE DETAILS diff --git a/mercurial/revlogutils/deltas.py b/mercurial/revlogutils/deltas.py --- a/mercurial/revlogutils/deltas.py +++ b/mercurial/revlogutils/deltas.py @@ -646,6 +646,11 @@ if good is not None: break +# If sparse revlog is enabled, we can try to refine the available deltas +if not revlog._sparserevlog: +yield None +return + # if we have a refinable value, try to refine it if good is not None and good not in (p1, p2) and revlog.issnapshot(good): # refine snapshot down To: lothiraldan, #hg-reviewers Cc: mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D5197: sparse-revlog: only refine delta candidates in the sparse case (issue6006)
lothiraldan created this revision. Herald added a subscriber: mercurial-devel. Herald added a reviewer: hg-reviewers. REVISION SUMMARY Starting with https://phab.mercurial-scm.org/rHG5aef5afa8654d0f32423d2b6cb51a47f3ccbe6d3, a valid delta parent might be "refined". This allows repository using sparse-revlog to produce better delta chain by using better intermediate snapshot base. However, this refining step was performed in all cases, including for repository not using sparse-revlog. This could produce a strange chain in the general delta case and corrupted repository in the non-general delta case. We now skip this step unless sparse-revlog is in use. In issue 6006, Yuya Nishihara provided a test case using an external repository, so we did not include it. Finding "laboratory" condition to reproduce this case and implementing an efficient test reproducing it is a bit tricky. We do not foresee to have the time to provide one by the release date. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5197 AFFECTED FILES mercurial/revlogutils/deltas.py CHANGE DETAILS diff --git a/mercurial/revlogutils/deltas.py b/mercurial/revlogutils/deltas.py --- a/mercurial/revlogutils/deltas.py +++ b/mercurial/revlogutils/deltas.py @@ -646,6 +646,11 @@ if good is not None: break +# If sparse revlog is enabled, we can try to refine the available deltas +if not revlog._sparserevlog: +yield None +return + # if we have a refinable value, try to refine it if good is not None and good not in (p1, p2) and revlog.issnapshot(good): # refine snapshot down To: lothiraldan, #hg-reviewers Cc: mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
