bundle command changes phase to public and probably shouldn't
Boggess, Rod
rboggess at tenovacore.com
Sat Sep 29 02:55:22 UTC 2012
Sorry about the format, but phone email is limited.
I'm pretty sure 1.x is before phases. That means everytime you talk to one of those, everything will come back as public.
Sent from my HTC smartphone on the Now Network from Sprint!
----- Reply message -----
From: "Ethan Barnes" <EBarnes at fusionio.com>
To: "Boggess, Rod" <rboggess at tenovacore.com>
Cc: "Kevin Bullock" <kbullock+mercurial at ringworld.org>, "Ethan Barnes" <EBarnes at fusionio.com>, "Pierre-Yves David" <pierre-yves.david at logilab.fr>, "mercurial at selenic.com" <mercurial at selenic.com>
Subject: bundle command changes phase to public and probably shouldn't
Date: Fri, Sep 28, 2012 6:02 pm
On 09/28/2012 11:09 AM, Boggess, Rod wrote:
I set the Outlook options to use >, and this is what I get. They should fire Blamer. Nothing works consistently now.
From: mercurial-bounces at selenic.com<mailto:mercurial-bounces at selenic.com> [mailto:mercurial-bounces at selenic.com] On Behalf Of Kevin Bullock
Sent: Friday, September 28, 2012 11:45 AM
To: Ethan Barnes
Cc: Pierre-Yves David; mercurial at selenic.com<mailto:mercurial at selenic.com>
Subject: Re: bundle command changes phase to public and probably shouldn't
On 28 Sep 2012, at 9:43 AM, Ethan Barnes wrote:
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.
[Boggess, Rod] This sounds an awful lot like an interaction between a newer version of mercurial and an older version – one that doesn’t support secret phases.
FWIW, I am using v2.3.1 locally, but I believe most other clients in the company are version 1.7 or 1.9.
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.
Do the sane thing and set mq.secret = True in your hgrc. It had to be made an off-by-default option for hysterical raisins (backward compatibility).
Note that that means your push won't push queued changes. But if you want to exchange MQ patches, you should probably be using a versioned patch queue anyway.
pacem in terris / мир / शान्ति / سَلاَم / 平和
Kevin R. Bullock
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.
More information about the Mercurial
mailing list