About an IRC discussion on using pull requests for hg development

[Pierre-Yves David]

The discussion have spreads like an octopus. I'll reply to various topic in a
single email for simplicity shake.


About review process of mercurial
------------------------------------------

+ I'm pretty ok with the current review workflow,

- But I suffered from "push Latency" too.

- being in Europe, also suffered from review latency.

+ I really like review by email. It is clear simple and efficient. We have a
  review application at logilab and it's much more painful.

- But review application are much better than email to keep track of various
  version and review comment and status. If we can get an application that read
  email to keep track of everything it would me very good imho.

About rewriting history 
------------------------------------------

Here is a quick version of my view. I intend to discuss those matter at the sprint.

About evolve
...............

Here is lastest version of documentation about my experiments toward mutable
history in mercurial:

  http://hg-lab.logilab.org/doc/mutable-history/html/

(Yes, This doc still suffer consistenty issues and a several broken of missing
schema. I accept patches^Wpull request)

Obsoletes marker are now used by an handful of people at Logilab. Those people
are very happy about it. I want to take advantage of this sprint to finalise
the design of the core concept (Obsolete marker) and discuss implementation is
core.

I recommend this section for people who think obsolete marker are overkill

  http://hg-lab.logilab.org/doc/mutable-history/html/unstability.html


About grouping changeset
.........................

I see the group approach is inferior to the obsolete changeset one.

  (1) It use strong dependency between changeset. This means keeping them forever in the repo.

      * Nobody should care about trashy intermediate changeset after a few month.

      * bisect, annotate, log viewer and user are confused about them.

  (2) It deny creation of fine grained history. One change == one branch == one final group.

  (3) Even if it supported fine grained history (pbranch approach) it does not
      support reordering independant changes.


About mq
.........................

mq is hard to use for beginners, fragile and limited. MQ served us well in the
early days but we should aims to better alternative. MQ will always be useful
for people who really need quilt guard feature.

About what slow down code review with mercurial
.................................................

For me the main show stopper for using mercurial changeset during review is not
the lack of history rewriting solution. The main issue is the inability to
delete remote changeset that prevent use to share "draft" changeset.

http://hg-lab.logilab.org/doc/mutable-history/html/obs-concept.html

Improving existing solution does not hurt.


I hope discussion on those topic at the sprint will be fruitful.


-- 
Pierre-Yves David

http://www.logilab.fr