Hg push tries to push data to repo without any changes

[Matt Mackall]

On Tue, 2013-01-29 at 09:13 +0100, Angel Ezquerra wrote:
> 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.

It can't be done when:

a) you're pulling from a shared filesystem where you don't have write
permission
b) you're pulling from an SSH server where you don't have write
permissions
c) you're pulling from an hgweb server which is sensibly paranoid and
the hgweb user doesn't have write permissions

In other worse, the read-only pull case is so common that we should just
accept that this is the way things are rather than muddy the waters with
different behaviors. 

We can even imagine a single repo that is accessed by different people
via NFS, SSH, and hgweb, very likely with different permissions. Do we
really want them behaving differently depending on protocol? I have
enough of a headache explaining to people that they need to figure out
which user hgweb is running as.

It's simpler just to say that pull is read-only.

-- 
Mathematics is the supreme nostalgia of our time.