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

[Martin Geisler]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

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

Since you've writen such a nice big commit message, I feel it should be
nicely formatted too. So I've re-wrapped your commit message below to a
consistent line-width.


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 behavior seems sane.

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

Note: The publish option is aimed at controlling the behavior of
*server*. Changesets in any state on a publishing server will
**always*** be seen as public by other client. A "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 repository): 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)


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/