bundle command changes phase to public and probably shouldn't

[Ethan Barnes]

On 09/28/2012 08:27 AM, Ethan Barnes wrote:
> On 09/28/2012 04:06 AM, Pierre-Yves David wrote:
>> On Thu, Sep 27, 2012 at 10:26:38AM -0600, Ethan Barnes wrote:
>>> In our workflow we have a build server that builds our potential fixes
>>> on multiple platforms. A custom extension bundles our changeset(s) up
>>> and sends them to the build server. When an error is found, we correct
>>> it locally then resubmit to the build server. This may happen several
>>> times before a changeset is actually pushed to the master repo.
>>>
>>> The problem is that every time we submit to the build server, the bundle
>>> command makes the changes public. Thus, when attempting to correct
>>> errors found by the build server, the phase is always "wrong".
>> No, it doesn't. "hg bundle" creates bundle without phase data
>> and do not change any phase locally (I just checked to be sure)
>>
>> I think you have another operation in you script that make either push
>> or a pull operation with the build server. This exchange turns your
>> changeset public (as they are seen on a public server).
> I stand corrected. I just checked the extension and we do a push to the
> build server and not a bundle/unbundle. I have been misled all these years!
I would like to add, however, that it seems a little strange that my 
changesets that are in mercurial queues are now marked public. The 
mindset I had was that queues were work "in-progress", since they are 
not qfinish'ed and thus not actually part of the repository proper.

I can see how safety dictates that when any changes are pushed they 
should be marked public, but that means that the queues are not really 
"in-progress", but are now part of the public repo, which seems strange, 
since they are not 'qfinish'ed.

Not sure what the solution should be here.

Ethan
>> You should either (A) remove this push/pull step (B) make your buil
>> server non publishing.
> I'll see what the possibilities are for both these options.
>
> Sorry for taking your time. Mercurial is a fine bit of work and we
> appreciate the work you put into it. It seems generally well thought-out
> and well implemented.
>
> Ethan
>> If this assumption is False, I would like to seen your custom extension
>> code.
>>
>>> This e-mail (and any attachments) is confidential and may be
>>> privileged.  Any unauthorized use, copying, disclosure or
>>> dissemination of this communication is prohibited.  If you are not the
>>> intended recipient,  please notify the sender immediately and delete
>>> all copies of the message and its attachments.
>> This confidential e-mail have been sent to a public mailing list (I
>> know, that's not your fault)
> That is better anyway, so others can benefit.

This e-mail (and any attachments) is confidential and may be privileged.  Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited.  If you are not the intended recipient,  please notify the sender immediately and delete all copies of the message and its attachments.