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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Dec 13 06:58:29 CST 2011


On Tue, Dec 13, 2011 at 10:59:41AM +0100, Martin Geisler wrote:
> 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.

Oups, I did notchecked the formatting from the pad export after Alain and Benoit
reviewed it and updated the message using --log. Thanks for the re-wrapping.


> 
> à bientôt
> 
> Thomas
> 
> 
> 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/


More information about the Mercurial-devel mailing list