Hg push tries to push data to repo without any changes

[Pierre-Yves David]

On Fri, Jan 25, 2013 at 04:33:28PM -0600, Matt Mackall wrote:
> On Fri, 2013-01-25 at 12:33 +0100, Pierre-Yves David wrote:
> > On Wed, Jan 23, 2013 at 01:41:04PM -0600, Matt Mackall wrote:

> > > It's simultaneously advertising that some changesets are draft but that
> > > all of them are public. The client thus tries to tell it "uh, this thing
> > > you think is draft is public now". Both the client and server side are
> > > buggy.
> > 
> > That is the expected behavior. The public server serves a repository also used for local operation.
> 
> Let's try a different approach: how is this not a regression?

I'm not claiming its not a regression. I'm claiming that locally the
fact we try to push phase is expected and the right things to do.

The fact it bugs the users and makes the subrepos push fails IS the
regression.

> We are going to change something here to make this work again for 2.5,
> the only question is what. Here are the options I see:
> 
> a) fix subrepos not to do empty pushes
> b) fix clients and servers to treat published changesets as public, full
> stop
> c) quietly skip phase push whenever authentication is requested
> d) something else
> 
> You should note that (a) presents a paradox because you've defined
> things such that this isn't actually an empty push any more, which means
> that now we can NEVER try to optimize away.
> 
> The absurd thing here is that the whole point of "publishing servers"
> was to not have this class of issue at all. When something is on a
> publishing server, it is supposed to be considered public by all
> clients.

We need to look at the issue at an even higher level.

The issue here is publishing server with draft content. This setup can
seems a bad and rare idea but that is actually a **very common case** as
publishing is the default. All developments repo out there are
publishing server with draft content except if published otherwise.
Such setup is still bad idea. In particular when actually served there
is two main setup that can lead to it:

    1) A developer offers it repo to pull/push for others people and:
       - He kept the default phases.publish=True setting.
       - He did not prevented people from pulling mutable part of his
         history using the secret phases.

    2) A server have some automatic hook to commit changesets:
       - server have the default `phases.new-commit=draft` config.


    - Those draft changesets may be pulled by other peoples.
    - Pull does not changes the phases on pulled repo.
    - When other people have those changeset we want to turn then public
      ASAP to prevent possible drama.

In an ideal world we wont have this issue:

    The developer from (1) should either:
    - Not offer pull
    - Turns its repo non publishing if applicable
    - Ensure he has public or secret changeset only

    The server from (2) will have:
    - `phases.new-commit=public` configured.

But the world is of course not ideal. And both user and server have not
clue that something "wrong" is going on:

(w) Shall we print warning on pull when we detect such situation ?

    That seems a good idea to educate user. But his mean warning
    virtually all the time as publishing with draft is the default.

(x) Shall we print warning on push when we detect such situation ?

    Not sure it is a good idea but we can probably comes with something
    descent.

    "If we do not push changeset but there is phase mismatch, display a
    message. If the remote repo is publishing (suspicious situation)
    warns the user too" That would make is clear that a push is not
    empty.

    Printing something when push is changeset empty but phase full is
    something that we'll need sooner or later.

(y) Shall we still try push phase movement to publishing server:

    I think so, this will prevent mistake and later confusion. See next
    block of the reply.


(z) Shall we consider the push failed if we can't push phase?

    Definitely not. And we can probably reduce the regression to this
    issue.

    Fixing that, client side, sound like (c) and would be my choice.

> Option (c) is obviously both hard and hacky.

If we lazily try to push phase in the case
- changeset have been pushed
- remote is publishing with inconsistent phase

If the push fails (or ask for password in the subrepo case?):
- we do not abort
- we may print a warning so the user can notify the buggy upstream.

I do not see that as particularly hard nor "hacky". We do our best to
prevent troubles but do not die for it.

> In my view, we should do (b) for 2.5. Breaking the relatively obscure
> corner case this failing push is meant to help with is a very small
> price to pay in my mind. And we need to do it for both clients and
> servers because earlier clients and servers will persist for a while.

For me (b) is strongly off the table. This introduces a consequent flaw
in the *default* case of phase behavior.

This is not a corner case, this is one of the most common phase movement
and will remains so as the default setting will not change.

When you have a, b, c public locally and you push them to repository
with default configuration:

  o - a
    \ b - c

If destination have o only, a, b, c will be added public on server
If destination have o and a, we add b and c as public but a phases
movement will not be done.

A developpement repo never push or pull anywhere but rely on another
peer to push and pull to it will never gets its phase updated.

In other words you are suggesting to move from

- Pull does not alter remote phase.
- Push alter remote phases.

to.

- Pull does not alter remote phase.
- Push alter remote phases … sometimes.

And that calls for trouble.


-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130128/446e6dfe/attachment.asc>