[PATCH 3 of 6] phases: add basic pushkey support

Matt Mackall mpm at selenic.com
Thu Dec 15 11:54:43 CST 2011


On Wed, 2011-12-14 at 16:43 -0600, Matt Mackall wrote:

> Meta:
> 
> Complex problems like this with many use cases -demand- exhaustive
> analysis. Please MAINTAIN A TABLE to demonstrate that you've done the
> exhaustive analysis, to allow other people to AUDIT your analysis and
> respond to it, and to document the behavior for posterity (ie in a
> comment or commit description). I'm super-frustrated every time I go to
> the effort of creating a table of use cases and then the discussion
> regresses to sloppy informality again.

For people following along and wondering what such a table could
possibly look like, here is what we eventually agreed upon, a compact
summary of 49 different use cases:

                        server
               old     publish      non-publish
              N   X    N   D   P    N   D   P
old client
 pull
  N           -   X/X  -   X/D X/P  -   X/D X/P
  X           -   X/X  -   X/D X/P  -   X/D X/P
 push
  X           X/X X/X  X/P X/P X/P  X/D X/D X/P
new client
 pull
  N           -   P/X  -   P/D P/P  -   D/D P/P
  D           -   P/X  -   P/D P/P  -   D/D P/P
  P           -   P/X  -   P/D P/P  -   P/D P/P
 push
  D           P/X P/X  P/P P/P P/P  D/D D/D P/P
  P           P/X P/X  P/P P/P P/P  P/P P/P P/P

 N = new/not present, P = public, D = draft, X = not tracked
 A/B = final state on client / state on server
 local commits are draft by default
 passive = only pushes

A cell here can be read like this:

"When a new client pushes a draft changeset (D) to a publishing server
where it's not present (N), it's marked public on both sides (P/P)."

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list