cHg Porting Plan

Steps to merge cHg into the Mercurial tree.

1. How to Merge

Perhaps (B) or (D).

1. single big commit

   • hard to review

   • useless history for digging

2. reorganize as 10+ 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+ 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. 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.)

• restart server process if config or __version__ changed

CategoryDeveloper CategoryNewFeatures