[PATCH 0 of 6 phases] Secret changeset

[Pierre-Yves David]

On Mon, Dec 19, 2011 at 03:42:29PM +0100, Angel Ezquerra wrote:

> > I assume "C" is secret here so local don't know it exist.
> >
> > Such push should not fail. However as I did not add any code to handle such
> > case, it'll probably fail after this series. Thanks for catching the usecase.
> 
> I've been reading the emails about the phases concept and I have a few
> questions.
> I am particularly interested about how this could be used to perform
> code reviews.

Code reviews often implies non-permanent (or mutable) history. Phases are the
first step in this direction.

> Currently if you want someone to review your changes you have several
> options: You can push to "code review repo", where you keep the
> changesets to review. Another alternative is to have people pull the
> changes directly from your local repo. Another is to send patches by
> email, as is done in the mercurial devel mailing list.
> 
> In all these cases, the problem is that once you those patches are in
> the wild, there is no way to tell that those patches are "under
> review" and are not to be spread further by regular push or pull
> operations.
> 
> So my question is whether the phases concept would help with this. For
> example, would it be possible to mark the changes that must be
> reviewed as "secret" and still be able to have someone pull them,
> keeping the secret flag to avoid further spread?

The primary purpose for phases is to have a simple mechanism to track life
cycle of a changeset.

 * You start working on something on your own --> secret changeset.
 * You want share it with other but are not yet convinced of the final result --> draft.
 * The changeset looks good you freeze it in an immutable phase --> public.

Phase only move forward, once you start wharing with other you can't go
backward (secret --> draft). Once you told the rest of the word this changeset
will never get rewritten you can't retract this promise (draft --> public).

Review process usually have more complicated workflow[1] which can't be handled
by the simplicity of phase only. Obsolete concept or other custom overlay may
handle this for you.

I think the setup below may become common once people get used to mutable
mercurial:

    Two central repositories:

    * A non-publishing one where every body can push

    * A publishing one where reviewer can push with enough care and security to
      be sure to only push what they have reviewed.

Phase hooks should play a big role in making sure changeset are not made public by mistake.


-- 
Pierre-Yves David

http://www.logilab.fr/

[1] http://www.logilab.org/workflow/60945?tab=wfgraph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111222/b7b74508/attachment.pgp>