cHg Porting Plan

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

Contents

How to Merge
Source Layout
Coding Style
Future Improvements
1. Server Life-cycle
2. Random Thoughts

1. How to Merge

Perhaps (B).

single big commit
- hard to review
- useless history for digging
reorganize as a few patches (base implementation, pager, setenv, sendfds, ...)
- can improve the code incrementally
- less useful history for digging
pull, rename and merge
- having more than one roots
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?

hook ui.readconfig -> config.parse to know all involved files
keep full text or hash of these files
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

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

-  ⇤ ← Revision 3 as of 2015-11-02 14:28:56 → 
  Size: 2014
  Editor: YuyaNishihara
  Comment:
+   ← Revision 5 as of 2015-12-09 13:58:29 → ⇥
  Size: 3543
  Editor: YuyaNishihara
  Comment: about server lifecycle
-Deletions are marked like this.
+Additions are marked like this.
 Line 6:
-Steps to merge [[https://bitbucket.org/yuja/chg/|cHg]] into the Mercurial tree.
+Steps to merge [[https://bitbucket.org/yuja/chg/|cHg]] into the Mercurial tree,
plus possible future improvements.
-Line 12:
+Line 13:
-Perhaps (B) is the best.
+Perhaps (B).
-Line 16:
+Line 17:
- A. reorganize as 10+ patches (base implementation, pager, setenv, sendfds, ...)
+  * {o} useless history for digging
 A. reorganize as a few patches (base implementation, pager, setenv, sendfds, ...)
-Line 18:
+Line 20:
+  * {o} less useful history for digging
-Line 19:
+Line 22:
-  * {o} messy
+  * {o} having more than one roots
-Line 21:
+Line 24:
-  * {o} messy
+  * {*} full history is useful when digging into bugs
  * {o} 300+ uninteresting revisions
-Line 25:
+Line 29:
-Perhaps (A) is better because we don't have to worry about the extension path.
+Perhaps (A) or (B) because we don't have to worry about the extension path.
-Line 39:
+Line 43:
-A. Merge extension part:
+A. Merge extension part into hgext:
-Line 51:
+Line 55:
-B. Put everything under contrib/chg:
+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:
-Line 75:
+Line 91:
-== Random Thoughts ==
+== Future Improvements ==

=== Server Life-cycle ===

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

==== 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

==== 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

==== 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

=== Random Thoughts ===
-Line 90:
+Line 139:
- * restart server process if `config` or `__version__` changed

Diff for "ChgPortingPlan"