[PATCH 00 of 18] Current advance on the states/phase topic
pierre-yves.david at logilab.fr
Mon Oct 10 08:50:25 CDT 2011
On Mon, Oct 10, 2011 at 03:36:30PM +0200, Angel Ezquerra wrote:
> > * States have been renamed to phases to avoid confusion with Status
> Personally I find the "phases" name a bit confusing, although I don't
> know if there are much better names... what about "stages" as in the
> different "stages" in the life cycle of a changeset?
Stage also collide with 'status' (as a commande) and is too much similar to the
git staging area. Adding more confusion to user using both mercurial and git
seems a very bad idea. (given whe already have pull = fetch, fetch = pull,
branch=bookmark, - = branch)
> > * We use phase names as few as possible until proper name are picked. This is to
> > be changed in the final series for clarity. See the link bellow for details
> > http://mercurial.selenic.com/wiki/StatesPlan#Naming
> > the revset filtering on phase suffer the most from this lack of name.
> > Future works
> > ------------
> > * implement phases boundary exchange and publish=False server: Please see my
> > previous email on the list about it.
> > * Adding a phase: <phasename> when phase != 0. It's pretty trivial but I prefer to wait for phasename to be choosed before altering all test with a new log output.
> > * Behaviour of current extension will change:
> > - rebase will refuse to work on public changeset without --keep.
> > - mq will refuse to qimport public changeset.
> > - mq managed changeset will be secret.
> Will still be possible to qimport a public changeset using a --force
> flag or similar?
Maybe. Anyway, It will be possible to change the phase of a changeset with a
dedicated command (hg phase). People might always make public changeset (0)
draft one (1) manually then qimport them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Mercurial-devel