[PATCH 1 of 9] chgserver: copy to mercurial

Jun Wu quark at fb.com
Fri Nov 18 15:44:18 EST 2016


Actually I'm not sure trading performance for correctness is the most
correct way to go. I'd like to preserve the flexibility so that if we do
want to eventually preload the repo object (and thus the index object /
radix tree etc), we are still able to do so.

Another approach to do that is to implement a "remote" "changelog" object -
and a dedicated "changelog" server dealing with what "changelog" and
"changelog.index" could do, namely "partialmatch" and "isancestor". IPC cost
could be a concern but it does not sound like a bad idea for big repos with
long changelog.

Excerpts from Jun Wu's message of 2016-11-13 21:55:45 +0000:
> # HG changeset patch
> # User Jun Wu <quark at fb.com>
> # Date 1479070808 0
> #      Sun Nov 13 21:00:08 2016 +0000
> # Node ID c04847bc1bf1804cc7d8f5e74444c50a653a9526
> # Parent  e1d6aa0e4c3aed73e0dc523b8a8fd5f9fe23510a
> chgserver: copy to mercurial
> 
> The patch moves chgserver.py to mercurial and the chg refactoring (mainly to
> avoid calling uisetup) starts here. The movement to core was decided at the
> 4.0 sprint.
> 
> It's inconvenient to change hgext.chgserver directly and then move it to
> mercurial because this is a relatively large refactoring and until we have
> all the patches, the "mercurial/" version would be incomplete or
> incompatible to the current chg client. Maintaining compatibility while
> doing the refactoring is hard.
> 
> Therefore, in the mean time, the chg client will still use hgext.chgserver.
> Once the refactoring is in a good shape, we will make the switch and remove
> hgext.chgserver.
> 
> "mercurial" was replaced to "." to make the import checker happy.
> 
> The motivation behind the refactoring was mainly discussed at:
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-July/085965.html 
> 
> The goals of the current planned refactoring are:
> 
>   a. do not run uisetup - much better compatibility
>   b. long socket path support
>   c. better integration with the pager extension
>   d. lock-free server start
>   e. fix remaining tests
> 
> Note that a downside of "a." is things can be slower - With ~50 extensions
> enabled, "chg version" may need 0.10 seconds, increased from 0.05 seconds.
> However, "a." provides "correctness" that solves some hard issues like
> infinite redirection with bundle or the share extension. So the performance
> price looks worthwhile. If we do want that 0.05 seconds, we can optimize
> later - like by making it possible to pre-run uisetups for part of the
> extensions manually.
> 
> diff --git a/hgext/chgserver.py b/mercurial/chgserver.py
> copy from hgext/chgserver.py
> copy to mercurial/chgserver.py
> --- a/hgext/chgserver.py
> +++ b/mercurial/chgserver.py
> @@ -51,7 +51,7 @@ import sys
>  import time
>  
> -from mercurial.i18n import _
> +from .i18n import _
>  
> -from mercurial import (
> +from . import (
>      cmdutil,
>      commands,
> @@ -125,5 +125,5 @@ def _getmtimepaths(ui):
>      modules = [m for n, m in extensions.extensions(ui)]
>      try:
> -        from mercurial import __version__
> +        from . import __version__
>          modules.append(__version__)
>      except ImportError:


More information about the Mercurial-devel mailing list