bundle command changes phase to public and probably shouldn't

Boggess, Rod rboggess at tenovacore.com
Fri Sep 28 17:09:45 UTC 2012


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] On Behalf Of Kevin Bullock
Sent: Friday, September 28, 2012 11:45 AM
To: Ethan Barnes
Cc: Pierre-Yves David; 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.


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 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120928/b3c2ff71/attachment-0002.html>


More information about the Mercurial mailing list