<div dir="ltr">I thought something like a 'non-publishing push' command instead before. The 'non-publishing push' command will abort if any draft revisions would turn to public by pushing them to another repository. If the remote repository is 'non-publishing', it will work just as a normal push. It could be a guard against accidentally publishing unfinished draft revisions. What do you think?<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 10:02 AM, Dov Feldstern <span dir="ltr"><<a href="mailto:dovdevel@gmail.com" target="_blank">dovdevel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I like to keep changesets that are still in-development secret --<br>
keeping them just as draft is risky, since I find that I am wont to<br>
"push" without limiting what branch I'm pushing, with the result that<br>
I push work that is not really ready to be published (this was not so<br>
much of a problem with mq, since patches did not get pushed by<br>
default, but now that I'm switching to evolve -- which I am generally<br>
very happy with :) -- this is more of an issue).<br>
<br>
OTOH, keeping the changesets secret means I can't share them with<br>
*any* repositories, though often I would like to be able to share<br>
among my different non-publishing repositories (this is one of the<br>
main drivers for switching from mq to evolve -- that with evolve it<br>
should be easier to share in-progress, still-mutating, work). This is<br>
also similar to the questions asked at [1,2], the answers to which I<br>
find not very satisfying (no offense, Martin!).<br>
<br>
So, my idea is something like this: it would be nice if I could<br>
configure "friend" repositories -- say, by adding a "friends" key<br>
under the [phases] config, with the value being a list of "paths" from<br>
[ui]. Then, I would like any operations relative to "non-publishing<br>
friends" to also include secret changesets, and to not promote the<br>
phase of the changesets simply by virtue of this sharing.<br>
<br>
In order to play around with this, I've just created a few patches<br>
which add a '-F, --friend' flag to 'outgoing' and to 'push'; where, if<br>
set, these operations will not exclude secret csets. The patches<br>
actually work for me, though I've only tested two local repositories<br>
at the moment. And in any case, I think the interface I describe above<br>
(configuring friends) would be better than adding a per-command flag.<br>
<br>
But even this simple implementation has already raised some issues:<br>
<br>
1. The pushed secret changesets get promoted to "draft" in both the<br>
local and remote repos. What's actually happening, I think, is that<br>
the csets get pushed to the remote as "draft", and then the comparison<br>
of the local with the remote finds that they are draft in the remote,<br>
and so promotes them to draft locally as well. (It was easy enough to<br>
prevent the promotion of the local csets, but I couldn't find where<br>
the promotion of the remote ones was happening; and if they get<br>
promoted, then preventing the promotion of the local ones is<br>
meaningless or downright wrong.) So, any tips on where the promotion<br>
of the remote changesets to "draft" is happening?<br>
<br>
2. If the secret changesets in the remote are manually forced back to<br>
secret, then subsequent 'outgoing -F' shows them again as outgoing!<br>
This may simply be because I haven't implemented "friend" support for<br>
the incoming commands, yet; but regardless, it raises the question of<br>
what happens, under the scheme proposed above, if the "friendship"<br>
configuration is not symmetrical -- i.e., if repo1 defines repo2 as<br>
its friend, but not vice versa, then repo1 can't see repo2's secrets,<br>
and so secrets from repo1 will always appear to be outgoing to repo2.<br>
To be sure, it really only makes sense to define as friends repos over<br>
which you have control (either directly, or via a "real" friend that<br>
you are sharing with) -- so just fixing the relations to be symmetric<br>
should not be much of a problem; and in any case, at the worst, a<br>
subsequent push will attempt to push the secrets again, and then they<br>
don't get pushed because they already exist (mercurial outputs, e.g.,<br>
"added 0 changesets with 0 changes to 11 files.")<br>
<br>
3. Just a general observation after having looked at the code a bit:<br>
it seems that the *current* semantics of secrets are pretty widely<br>
assumed, so I'm a *little* worried about being able to cover all<br>
edge-cases with a change like this...<br>
<br>
So --<br>
<br>
Does this idea sound interesting/useful to anyone else? And if so, any<br>
pointers on how to move ahead with this?<br>
<br>
Thanks!<br>
Dov<br>
<br>
I'll send the patches I mentioned above as a patchbomb, just for reference.<br>
<br>
[1] <a href="http://stackoverflow.com/questions/9637984/mercurial-include-secret-changesets-in-bundle/9645786#9645786" target="_blank">http://stackoverflow.com/questions/9637984/mercurial-include-secret-changesets-in-bundle/9645786#9645786</a><br>
[2] <a href="http://stackoverflow.com/questions/10029718/push-secret-changesets/17046989#17046989" target="_blank">http://stackoverflow.com/questions/10029718/push-secret-changesets/17046989#17046989</a><br>
_______________________________________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</blockquote></div><br></div>