Having more than three phases (was RFC: Phase UI (revset, phase command and others))

Pierre-Yves David pierre-yves.david at logilab.fr
Tue Jan 3 11:23:04 UTC 2012


On Tue, Jan 03, 2012 at 12:01:45PM +0100, Laurens Holst wrote:
> Op 03-01-12 10:38, Pierre-Yves David schreef:
> >Phase are not suitable for:
> >
> >   Implementing a trash phase to mark deleted changeset: phase are designed to
> >   move a given direction (old phase>  new phase) and moving changeset from
> >   draft or secret phase to a trash one will break this rule.
> >
> >   Tracking complex review work flow: Review work flow usually implies moving
> >   back and forth between "waiting for review" and "work in progress" phase
> >   which again does not fit with the way phase move.
> 
> I don’t want to stir up a done discussion (link?), but:
> 
> Why can’t phases move backwards, what is the reason for this design
> choice? These two examples would be useful additions that I think
> would otherwise fit snugly in the phases flow.

Phase are synchronize in a very simple way: When a changeset is seens in two
different phase, the minimal value is used (public < draft < secret).

This behavior make it very simple to merge concurrent phase value. This remove
the need to tracking history of phase movement and to make complexe processing
of merge data.

**During synchronization** phase move only forward. This is a key point of
phase and ensure a simple a smoothy concept.

> There are already commands that will move the phase backwards (mq),
> and also the user can do this manually.

This is a local phase movement that may be overwritten by later
synchronisation.


-- 
Pierre-Yves David

http://www.logilab.fr/

ps: I'm not again explicit command to move remote phase backward but it should
*NOT* be part of standard workflow.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120103/15e2782a/attachment.asc>


More information about the Mercurial-devel mailing list