Hg push tries to push data to repo without any changes

[Angel Ezquerra]

On Tue, Jan 29, 2013 at 8:48 AM, Matt Mackall <mpm at selenic.com> wrote:
> 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.

Sorry if this is common knowledge, but since the introduction of
phases I've wondered why pulling from a publishing server does not
automatically turn the pulled revisions public.

I realize that there are many cases where this could not be possible
(e.g. on your read-only NFS share example), but wouldn't it make sense
to do so if possible (e.g. when serving via hgweb)?

This is something that could probably be done with a hook, but it
would be nice if this were the default behavior of if it could be
enabled through some setting.

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

I could not agree more.

Cheers,

Angel