Hg push tries to push data to repo without any changes

[Matt Mackall]

On Mon, 2013-01-28 at 19:46 +0100, Pierre-Yves David wrote:
> 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.

Roman, Tk, and Bitbucket all did something perfectly reasonable here:
They upgraded Mercurial and kept working the way they used to. We
guarantee this will not break. It broke. The blame lies entirely with
us.

If "such a setup is a bad idea" with your design, then the problem lies
in your design, not the users' setup.

>  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.

So this can happen whenever:

a) someone shares their working repository directly or
b) someone does pull operations on their server repo (ie Bitbucket pull
request)

Both of these are first-class supported use cases that have been in use
since day one.

> 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.

In my view, when you publish, a changeset is public. Check your
dictionary:

        From The Collaborative International Dictionary of English
        v.0.48 [gcide]:
        
          Publish \Pub"lish\, v. t. [imp. & p. p. {Published}; p. pr. &
             vb. n. {Publishing}.] [F. publier, L. publicare,
        publicatum.
             See {Public}, and {-ish}.]
             1. To make public;

The only issue is whether you know you've published. For instance, if we
clone from Alice's ~alice/repo/foo on an NFS server where we don't have
write permission (another first-class use case!), Alice's repo never has
a chance to learn that it's even been pulled from. But in the very real
and important sense of being visible to the world, the changeset is
public at this point regardless of whether the server knows it or not.
This is just a fact of life in a disconnected, distributed system:
sometimes someone's information will be out of date.

Axiom: publishing makes changesets public
Observation: many repos are unavoidably read-only
Lemma: changes are marked draft in some places when they're really
public
Corollary 1: it's not always a bug when that happens
Corollary 2: we should not make a fuss about it

> 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.

Let me be clear that I welcome this trouble with open arms, as it is
1000% preferable to the current trouble. But really, we can't escape
this trouble anyway, as I've demonstrated above. Also consider this
scenario:

        Alice has a repo with draft changeset X.
        Bob pulls from it, gets public X.
        Bob doesn't immediately push back (why would he?)
        Alice rebases X, which she still thinks is draft
        Now we have "trouble", regardless of which model we choose
        But this trouble is no worse than the situation without phases
        
Now consider:
        
        Alice has a repo with draft changeset X.
        Bob pulls from it, gets public X.
        Bob creates Y, pushes back to Alice
         (or Alice pulls from Bob)
        X and Y are now public for Alice.
        Alice attempts to rebase, is denied
        Everything is fine, regardless of which model we choose.

The only time we avoid trouble with your model that isn't avoided with
mine is when all of these planets align:

a) Alice has a publishing repo
b) ..with draft changesets
c) Bob has no descendants of those csets to push
d) ..and tries to push anyway
e) ..and has permission
f) ..and does it before Alice tries to modify a draft changeset

..but there are plenty of variants of the above where the trouble
persists, which is why I'm really not terribly concerned with the
marginal improvement in "correctness".

Lastly, the number one request (that we're likely to honor) from subrepo
users is to please please please not even contact the server for clean
subrepos. If we declare that these clean subrepos are actually dirty,
we'll never be able to do that.

-- 
Mathematics is the supreme nostalgia of our time.