[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