[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