bundle command changes phase to public and probably shouldn't

[Ethan Barnes]

On 09/27/2012 03:37 PM, Matt Mackall wrote:

Thanks for your quick reply.

On Thu, 2012-09-27 at 10:26 -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".

This is making the conservative assumption that a bundle effectively
exposes a changeset to the world. The bundle format has no provision for
passing phase information and needs a complex version bump to do so.

Not sure passing phase info in a bundle is warranted, especially since playing conservative is better--for the majority of cases.

What might be nice would be a way to specify that, because of internal process or whatever, bundling is safe? Phases actually solves a problem that we never had. But it causes some that we never had before either, with our process.

Funny, I think we have the opposite behavior on the unbundle side.

That _is_ just a bit funny. Still a few corner cases to work out.

> Is there a way to tell mercurial that bundling is not pushing?

I don't think so. Your idea of tying it to publishing=False might be
good.

That does appear to work now. Just tested and the three mq's did not change from draft to public as they did before.
When I tried it before it did not work--but it helps if one has the correct key "publishing" instead of "publish" which I thought I read somewhere :-). Thanks for the clue!

Ethan

--
Mathematics is the supreme nostalgia of our time.




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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120927/35f60659/attachment-0002.html>