[PATCH 1 of 6] phases: add a phases.publish option

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
# Date 1323733335 -3600
# Node ID 8a939618b6c681b26b670cd7cb3890358d49abf2
# Parent  b888d1229c3985307a8edc7969a49d2817b049af
phases: add a phases.publish option

What is a "publishing repository"?
==================================

Setting a repository as "publishing" alter its behavior **when used as a
server**: all changesets are **seen** as public changesets by clients.

So, pushing to a "publishing" repository is the most common way to make
changesets public: pushed changesets are seen as public on the remote side and marked
as such on local side.

Note: the "publishing" property have few or no effects for local operations.
Details are covered in a later section.

Old repository are publishing
=============================

Phase is the first step of a series of features aiming at handling mutable
history within mercurial. Old client do not support such feature and are unable
to hold phase data. The safest solution is to consider as public any changeset
going through an old client.

Moreover, most hosting solution will not support phase from the beginning. Having old
clients seen as public repositories will not change their usage: public repositories
where you push *immutable* public changesets *shared* with others.

Why is "publishing" the default?
================================

We discussed above that any changeset from a non-phase aware repository should be seen as public.
This means that in the following scenario, X is pulled as public::

  ~/A$ old-hg init
  ~/A$ echo 'babar' > jungle
  ~/A$ old-hg commit -mA 'X'
  ~/A$ cd ../B
  ~/B$ new-hg pull ../A # let's pretend A is served by old-hg
  ~/B$ new-hg log -r tip
     summary:     X
     phase:       public

We want to keep this behavior while creating/serving the A repository with
``new-hg``. Although committing with any ``new-hg`` creates a draft changeset. To
stay backward compatible, the pull must see the new commit as public.
Non-publishing server will advertise them as draft. Having publishing repository
the default is thus necessary to ensure this backward compatibility.

This default value can also be expressed with the following sentence: "By default,
without any configuration, everything you exchange with the outside is
immutable.". This behaviour seems sane.

Why allow draft changeset in publishing repository
=====================================================

Note: The publish option is aimed at controlling the behavior of *server*.
Changeset in any state on a publishing server will **always*** be seen as public
by other client. "Passive" repository which are only used as server for pull
and push operation are not "affected" by this section.

As in the choice for default, the main reason to allow draft changeset in
publishing server is backward compatibility. With an old client, the following
scenario is valid::

  ~/A$ old-hg init
  ~/A$ echo 'babar' > jungle
  ~/A$ old-hg commit -mA 'X'
  ~/A$ old-hg qimport -r . # or any other mutable operation on X

If the default is publishing and new commits in such repository are "public" The
following operation will be denied as X will be an **immutable** public
changeset. However as other clients see X as public, any pull//push (or event
pull//pull) will mark X as public in repo A.

The following basic operations add changeset to a repository:

- commit: As explained before this must create a draft changeset in any case.

- push (from another repo): Pushed change will be become public for the pusher
  and should be marked as public locally (either automatically of by phase sync)

- pull: For shake of symmetry with push, I add them as public. Matt would add
  them in the original remote state. I don't have a strong opinion about it.

- unbundle: I'm adding them as public for consistency with push and pull. I have
  an even weaker opinion about it.

Allowing enforcement of public changeset only repository through config is
probably something to do. This could be done with another "strict" option or a
third value config for phase related option (mode=public, publishing(default),
mutable)

diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -1992,8 +1992,12 @@
                           url=url, pending=p)
 
             added = [cl.node(r) for r in xrange(clstart, clend)]
-            if srctype != 'strip':
-                phases.advanceboundary(self, 0, added)
+            if self.ui.configbool('phases', 'publish', True):
+                if srctype != 'strip':
+                    phases.advanceboundary(self, 0, added)
+            else:
+                phases.retractboundary(self, 1, added)
+
             # make changelog see real files again
             cl.finalize(trp)
 
diff --git a/tests/test-phases-exchange.t b/tests/test-phases-exchange.t
--- a/tests/test-phases-exchange.t
+++ b/tests/test-phases-exchange.t
@@ -109,4 +109,30 @@
   1 0 a-B
   0 0 a-A
 
+Publish configuration option
+----------------------------
 
+changegroup are added without phase movement
+
+  $ hg bundle -a ../base.bundle
+  5 changesets found
+  $ cd ..
+  $ hg init mu
+  $ cd mu
+  $ cat > .hg/hgrc << EOF
+  > [phases]
+  > publish=0
+  > EOF
+  $ hg unbundle ../base.bundle
+  adding changesets
+  adding manifests
+  adding file changes
+  added 5 changesets with 5 changes to 5 files (+1 heads)
+  (run 'hg heads' to see heads, 'hg merge' to merge)
+  $ hgph
+  4 1 a-D
+  3 1 a-C
+  2 1 b-A
+  1 1 a-B
+  0 1 a-A
+