[PATCH 0 of 6 phases] Secret changeset

[Angel Ezquerra]

On Thu, Dec 22, 2011 at 11:47 AM, Pierre-Yves David
<pierre-yves.david at logilab.fr> wrote:
> 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 see. So the phases concept is a step on that direction but is not
meant to be the actual final solution.

> 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.

That is perhaps what I had missed. I thought that pushing to _any_
repo would always make the changesets public (i.e. take them out of
the draft phase). Are you saying that is not the case?

Thank you for your answers!

Angel