cHg Porting Plan

Steps to merge cHg into the Mercurial tree, plus possible future improvements.

1. How to Merge

Perhaps (B).

1. single big commit

   • hard to review

   • useless history for digging

2. reorganize as a few patches (base implementation, pager, setenv, sendfds, ...)

   • can improve the code incrementally

   • less useful history for digging

3. pull, rename and merge

   • having more than one roots

4. convert with filemap and rebase

   • full history is useful when digging into bugs

   • 300+ uninteresting revisions

2. Source Layout

Perhaps (A) or (B) because we don't have to worry about the extension path.

Original:

README
hgext/chgserver.py
      chgutil.c
src/Makefile
    chg.c
    hgclient.[ch]
    util.[ch]

A. Merge extension part into hgext:

contrib/chg/Makefile
            README
            chg.c
            hgclient.[ch]
            util.[ch]
hgext/chgserver.py
mercurial/osutil.c <- chgutil.c

B. Merge extension part into core:

contrib/chg/Makefile
            README
            chg.c
            hgclient.[ch]
            util.[ch]
mercurial/chgserver.py
mercurial/osutil.c <- chgutil.c

C. Put everything under contrib/chg:

contrib/chg/hgext/...
            src/...

3. Coding Style

Current state:

• .py mostly follows the Mercurial style

• .c is similar to the Mercurial style, but

  • uses 4 spaces instead of tab
  • uses C99 comment
  • uses C99 variable declaration

What to do:

• update import lines (easy)

• replace 4 spaces by tab (easy)
• replace C99 comments (easy)
• move variable declarations to top (really?)

4. Future Improvements

4.1. Server Life-cycle

Want to restart the server (or reload the config cleanly) if config or __version__ changed.

4.1.1. How to detect config change?

1. hook ui.readconfig -> config.parse to know all involved files

2. keep full text or hash of these files
3. read all config files and compare them with (2) per connection

https://bitbucket.org/yuja/chg/pull-requests/3/483b35203d92/diff#comment-8188548

4.1.2. Who restarts the server?

• not determined
• this would be deeply linked to the server model:

  • fork per connection, or pre-forked worker pool (for PyPy JIT)

  • round-robin on accept(), or more intelligent dispatcher (e.g. dispatch per repo.root for better caching of repo instance)

(from previous discussion)

• marmoute, lcharignon: server tells dirty and dies, client starts the server ?
• yuya: server tells dirty, client kills and restarts the server

4.1.3. See also

• https://bitbucket.org/yuja/chg/pull-requests/3/483b35203d92/diff#comment-8219394

• http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/81763/focus=82134

4.2. Random Thoughts

• eliminate copy-paste codes
  • pager

  • _requesthandler

  • util.system

• testing: ./run-tests.py --with-hg=chg ?

• environment variables

  • HGPLAIN, HGENCODING, LC_*, etc.

  • ui.environ ?

  • shell alias
• debian package
• better forking model for
  • JIT optimization provided by pypy

  • cached repo object (avoid parsing obsstore, etc.)

CategoryDeveloper CategoryNewFeatures