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

timeless timeless at gmail.com
Thu Dec 15 07:33:54 CST 2011


**always***

Unbalanced stars :(

On 12/15/11, pierre-yves.david at logilab.fr <pierre-yves.david at logilab.fr> wrote:
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at logilab.fr>
> # Date 1323946653 -3600
> # Node ID 9a49ac428e84d838774a9f38b9014fae082c449e
> # 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 no effects for local operations.
>
> 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.
>
> 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
> @@ -1990,12 +1990,16 @@ class localrepository(repo.repository):
>                  self.hook('pretxnchangegroup', throw=True,
>                            node=hex(cl.node(clstart)), source=srctype,
>                            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)
>
>              tr.close()
>
> 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
> @@ -107,6 +107,32 @@ update must update phase of common chang
>    3 0 a-C
>    2 0 b-A
>    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
> +
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

-- 
Sent from my mobile device


More information about the Mercurial-devel mailing list