Call for discussion: Phase names

[Angel Ezquerra]

On Jan 10, 2012 12:36 AM, "Matt Mackall" <mpm at selenic.com> wrote:
>
> On Mon, 2012-01-09 at 16:41 -0600, Sean Farley wrote:
> > >
> > > And what is the rationale for that? That -also- seems obviously wrong.
> > >
> >
> > Agreed.
> >
> >
> > > I see: the rationale is it saves transmit time for the edge case of
> > > "pushing changeset that are already present but secret on target".
> > >
> > > That's a fairly contrived scenario, and a poor reason to make this
> > > design choice. And it's almost certainly going to cause trouble.
> > > People today do things like 'hg id -r tip remote' to figure out what
> > > their incoming changeset group is going to look like, and if we don't
> > > actively hide these changesets from remote clients, we're breaking
that.
> > > Similarly, if discovery says there are remote csets and we get an
empty
> > > changegroup, we're going to upset people using 'hg summary --remote'.
> > >
> > > If we have to resend changesets because they happen to exist but are
> > > secret remotely, then I'm absolutely fine with that if it means we can
> > > have them actually be properly isolated.
> >
> >
> > Ah, ok, I finally get it now. I agree about not sharing the 'private /
> > secret / local' csets, but if that's the case, then what exactly is
> > ambiguous with using 'local' as the name? Unless you mean it clashes
with
> > 'local repo' naming?
>
> Draft csets are (generally speaking) local as well. Nothing about the
> word 'local' says 'not only are these csets not shared YET, but they're
> not even allowed to be shared'. Private/secret/restricted do convey
> that.

"restricted" is awfully generic? restricted in which way? IMHO it does not
immediatelly indicate that it refers to the shared status of the changeset
as secret and private do...

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120110/d72ef84c/attachment.html>