[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