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.

Environment variable are also a problem. The two things above change in a "global event" basis. At some point of time, the config/version changes and all running servers need to be restarted. However, Environement variable can change more often and can be different in two different shell, using Mercurial at the same time. We probably need multiple server based on environment here.

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. How to handle Environment Variables difference

(basic note)

some of them could be sent by the client and updated for each worker (eg: HGEDITOR).

Some other have global effect and requires dispatch to different server (eg: HGPLAIN, HGENCODING)

4.1.3. 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.4. 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