Re: Adding a cache for dirstate

[Raphaël Gomès]

Bikeshedding update:

How about naming it "DirsTraversalCache" instead? "DirsCache" was a bit 
of a placeholder and not clear enough for my taste (and others as well 
I've been told). It would go in `.hg/wcache/dirs_traversal_cache`.


On 5/14/20 7:47 PM, Raphaël Gomès wrote:

Hi all,

I have made a new plan page explaining a new cache for 
`dirstate.status` in detail:


https://www.mercurial-scm.org/wiki/DirsCachePlan

Maybe this email can be the discussion thread around this. I'm not 
sure how other plans have worked in this regard.


Thanks,
Raphaël

___
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

D8573: fsmonitor: coerce `clock` variable to byte-string (issue6321)

[sheehan (Connor Sheehan)]

sheehan created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Callers of `fsmonitor.state.setlastclock` pass their arguments
  wrapped in `pycompat.sysbytes` to ensure the value is a `bytes`
  on Python 3. However in `fsmonitor.poststatus.__call__`, if the
  return value of `getlastclock()` is `None`, we use the value of
  `fsmonitor.poststatus._startclock` instead, which is not converted
  to a byte string in the same manner. This commit converts the
  value of `startclock` to a byte string using `pycompat.sysbytes`
  in the constructor for `poststatus`, to avoid the "`str` + `bytes`"
  error from issue 6321.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8573

AFFECTED FILES
  hgext/fsmonitor/__init__.py

CHANGE DETAILS

diff --git a/hgext/fsmonitor/__init__.py b/hgext/fsmonitor/__init__.py
--- a/hgext/fsmonitor/__init__.py
+++ b/hgext/fsmonitor/__init__.py
@@ -667,7 +667,7 @@
 
 class poststatus(object):
 def __init__(self, startclock):
-self._startclock = startclock
+self._startclock = pycompat.sysbytes(startclock)
 
 def __call__(self, wctx, status):
 clock = wctx.repo()._fsmonitorstate.getlastclock() or self._startclock



To: sheehan, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Raise minimum Python version?

[Gregory Szorc]

On Tue, May 19, 2020 at 6:24 AM Manuel Jacob  wrote:

> Hi,
>
> The issue came up in a reply to a patch I've sent a few days ago. I'm
> sending a new mail to discuss this topic more generally.
>
> Mercurial is not usable on Python versions prior to 2.7.4. The issue was
> raised in
> https://www.mercurial-scm.org/pipermail/mercurial/2020-May/051937.html.
> I've sent a patch fixing it (that I didn't really propose for inclusion,
> for reasons described in the patch):
>
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2020-May/141666.html.
>
> Instead of committing the patch, I propose that the minimum Python
> version should be raised to Python 2.7.4 in the stable branch.
>

I think this is reasonable, given how old Python 2.7.3/2.7.4 are. Python
2.7 support in Mercurial is effectively end-of-life anyway.


>
> Some security features of Python 3.x were backported to Python 2.7.9
> (see PEP 466). If we require at least Python 2.7.9, we can make raise
> the minimum security standard of Mercurial (quote from
> mercurial.sslutil: "Depending on the version of Python being used,
> SSL/TLS support is either modern/secure or legacy/insecure. Many
> operations in this module have separate code paths depending on support
> in Python."). Therefore, I propose to raise the minimum Python version
> to 2.7.9 in the default branch.
>

As the author of the code in mercurial.sslutil, I'm in favor of dropping
support for Python versions that don't support `ssl.SSLContext`. This is
because we simply don't have the control over connection security that we
need to ensure security without those APIs. I worded that qualification
specifically because some Linux distributions backported Python 2.7.9's
modern `ssl` features to older Python versions. IIRC RHEL/CentOS 7 ship a
Python 2.7.5 that has these features.

I think a reasonable course of action is to require 2.7.4+ and
`ssl.SSLContext`.


>
> Alternatively, we could drop Python 2 support completely.
>

I'd love to do this too. But Python 3 on Windows is still a bit shaky and
we probably need another release before we can drop Python 2 completely. I
really, really, really wish this weren't the case.

I'll try to find time in the next week to work on patches to the stable
branch so we can publish working Python 3 Windows installers. Hopefully if
we get 5.4.1 working on Windows on Python 3 we can drop support for Python
2 after the 5.5 release (making 5.6 the first Python 3 only release).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel