Hg push tries to push data to repo without any changes

[Pierre-Yves David]

TLDR:
- Proposed behavior changes is bit and unacceptable,
- The error can and should be fix the subrepo side,
- Similar error will reappear soon otherwise
- We should discuss this with a lower latency medium (including air)


On Tue, Jan 29, 2013 at 01:48:16AM -0600, Matt Mackall wrote:
> On Mon, 2013-01-28 at 19:46 +0100, Pierre-Yves David wrote:
> > 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.

Ok, my statement was too wide, I meant:

    Having draft changeset on a public *reference* server is bad idea if you
    want to takes full benefit of the phases feature.

The current design is the best we came along after days of discussion last
year. Phases is a big changes and the choice that we made to have "publishing"
as the default comes with benefit of phases security available transparently to
every body, but at cost of unavoidable impact.

This choice have already broken other common workflow. Pushing mq changesets to
a pre-2.1 try server turn them public. This has forced the whole cohort of
Mozillian to work around that for a whole year (and it is not over).

> So this can happen whenever:
> 
> a) someone shares their working repository directly or

I do not expect such repo to be commonly used as default, main reference for
someone-else subrepo.

> b) someone does pull operations on their server repo (ie Bitbucket pull
> request)

Not exactly. Pull operations worked fine, its the fact a merge is automatically
committed on the reference repo that creates our current issue.

If a alice had:
  1) pull bob branch locally
  2) merged
  3) push to bitbucket reference.
everything would be public.

crew+main does automatic pull and have public only contents as expected.

  $ curl 'http://hg.intevation.org/mercurial/crew+main?cmd=listkeys&namespace=phases'
  publishing      True

The issue is still here but the range of usage that actually have a chances to
affect subrepo is much narrower.

> 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:
>
> […]
>
> 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

One year ago, After days of mooting you convinced me that:

1) Content of Publishing server are seen as public by client.
2) Any changegroup *pushed* to a publish=True server is public

(from http://selenic.com/pipermail/mercurial-devel/2011-December/036390.html)

(1) may lead to changesets both draft and public at the same time in the same
    repo.  It was "necessary" for changeset to turn immutable as fast as
    possible with default configuration.

(2) Was restricted to push:
    (a) pull is better kept read-only all the time
    (b) you just have to turn the common exchange repo non-publishing to exchange
        draft. No client side changes needed.
    (c) we wanted commit, unbundle etc to create draft by default.

The two points above are the only differences between publishing and
non-publishing server. They behave the same way otherwise, in particular
regarding synchronisation on push.

Your proposed behavior change will makes publishing server significantly less
capable that non-publishing one. Publishing server will behaves as pre-phase
server for the outside. Except that pre-phase server have they content turned
public as soon a phase enabled client touch it locally. Draft head can stay on a publishing server forever is nobody touch them again.

I explained our current issue to some people who then argued that maybe we
should drop (1) from the definition of publishing server. "Because Remotely
draft changeset  should not be pull as public in the first place". That seems
hardly a solution regarding (1) justification (dig for last year discussion if
details are needed)

> > 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:
> 
> […] i(scenario about Alice and Bob interracting)
> 
> 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

You missed an important use case here, the same user exchanging changeset
between multiple of its own repo.

Simple version:

a) Alice have local-devel repo
b) Alice have a 'release-XXX' "branch-clone"
c) Alice pull from it's local-devel repo
d) Alice push to it's local-devel repo
e) Alice attempt to rebase (in local-devel)

The current design *correctly* prevents rebase in (e), your suggested changes
does not. You can argue that is not worse that pre-phases era but this is:
- A regression regarding what we do since 2.1
- A push behavior divergence confusing to the user.

Partly synchronised variant:
    add a (c') steps where Alice add changes on some of the draft heads in
    main-devel. Heads with changes are turned public by (d) other stay draft.
    -> confusing buggy behavior

Non-publishing doing better variant:
    - After (b) Alice push to a public bitbucket repo
    - content of 'release-XXX' is turned public
    - (d) keep local-devel draft if local-devel is publishing (default)
    - (d) turn local-devel public if local-devel is non-publishing
    -> publishing gets less secure than non-publishing

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

(note: we always contact the remote to check if our local copy is dirty. I
assumes you mean "s/contact/write to/")

I still strongly opposed to the suggested phase behavior changes. Seeing it as a
strong regression regarding what we do now.

I do not want to spoil the whole phase behavior because of a subrepo whim that
affect people unlucky enough to use a reference repo in a suspicious state.

We need to fix subrepo them self. The "push absolutely everything or die"
mentality of subrepo is an issue by itself. I pretty sure it already causes other issues.

Ensuring that `hg clone; hg push` as non op is all case looks a the poor work
around to it. And it strongly affect other legitimate usecase.

I'm pretty sure that not-so-empty but-not-important push issue will easily show
up later, with either bookmarks, local phase movement irrelevant remotely,
obsolescence marker or anything else.

We needs to make subrepo more resilient now or another similar issue will pop later.

In the meantime user have available work around:

a) set a different default-push.
b) hint the reference owner that something could be better on they side.

(does not means we should not fix the issue, just that they do not need to downgrade)


Discussing this by email is suboptimal. We should either:

1) discuss this using VOIP
2) discuss this at the sprint and land a fix in 2.5.1

(2) Would help the topic to maturate and other people to participate.

-- 
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/20130129/29d3dbe5/attachment.asc>