Topics [was: news from the topic experiment]

Tue Nov 1 11:55:05 EDT 2016

On Mon, Oct 31, 2016 at 9:56 PM, Sean Farley <sean at farley.io> wrote:

> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
>
> > On 10/15/2016 04:18 PM, Pierre-Yves David wrote:
> >>
> >>
> >> On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
> >>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
> >>>> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
> >>>>> So, the other branch of that thread made me realised that we cannot
> do
> >>>>> this "BRANCH:TOPIC" storage in the current "branch" field.
> >>>>>
> >>>>> An important part of topic is to have them fade away when the
> >>>>> changesets
> >>>>> become public. This fading away will be implemented client side
> (logic
> >>>>> to stop reading the value). If we expose this data to old client who
> >>>>> does not have this logic this means that topic would live as
> >>>>> "BRANCH:TOPIC" forever on old client, breaking them in various way.
> >>>>
> >>>> I don't see that. Currently, we have:
> >>>>
> >>>> - old client cannot see topic at all (making it unusable)
> >>>> - new client can see topics
> >>>>
> >>>> If we move to branchname + flag, we have:
> >>>>
> >>>> - old client can see and update using 'hg update NAME' (extremely
> >>>>   valuable)
> >>>> - old client can merge a topic to default (extremely helpful and
> >>>> surprising)
> >>>> - new client will hide those branches
> >>>>
> >>>> Your argument is that old clients will see those branches. That's a
> much
> >>>> better side-effect than not being able to update at all to a topic
> >>>> branch.
> >>>
> >>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
> >>> "BRANCH" is
> >>> bad because you can't filter log by "branch(BRANCH)" in old client.
> >
> > Exposing topic directly into the branch field means that all the
> > behavior related to named branch will be broken for old clients once
> > someone start using topic in the repository.
> >
> >
> > For example, if a team is using the "foo" branch for development,
> > tracking the head of "foo" is important. Mercurial keeps a set of
> > behavior user rely on, eg: hg up "foo" works, and with this branch
> > active, "hg up" or "hg merge" pick the right head.
> >
> > Now, let's assume the topic information is part of the "branch" field,
> > someone in the team start using topic and do some work on the "bar"
> > topic, their changeset will contains topic informations. For that user,
> > the topic information will just fade away when pushed to the public
> > server. The server will not expose that topic information (because the
> > changeset is public and the server is new), Other team member pulling
> > with a new client will see the "foo" branch move forward as expected
> > without mention of the "bar" topic.
> > However (if the topic information is part of the "branch" field), old
> > clients pulling from that server will get a different result. Instead of
> > having "foo" move forward, they will get a new branch "foo:bar". The
> > branch "foo" will be stuck behind until someone hopefully do work
> > without topic. Breaking the behavior described earlier. In addition this
> > new branch might break various other automation that would now refuse to
> > push a new branch.
> >
> > This highlight how important the control of topic life cycle is. Topics
> > must be able to disappear for public changeset. This is the feature that
> > allow the rest of the Mercurial work flows to  keep working for
> > immutable changeset. And this requires the meaning of the "branch" field
> > to stay backward compatible.
> > As a side note, I would like to emphasize that having advanced users
> > about to try out topic without poisoning the common well will be
> > important for adoption.
>
> I think your logic is very contrived here. No, branch names don't have
> to disappear. That's no "a requirement" as you say. What you are
> suggesting is very over-engineered [1]. Though, it is getting late here
> and I can respond more tomorrow.
>
> > I'm confident we can find interesting solution for the various
> > inconvenient the old client will see. For example, (random though), we
> > could not serve topic changesets to old client by default, while still
> > honoring explicit requests in the form "branch:topic".
> >
> >
> > Mercurial have been using this strategy of ignoring new data in the
> > past. For example, when named branch or bookmark where introduced in the
> > past, old client where able to interact with repository using the new
> > repo without too much behavior impact.
>
> Not interested. There is already no buy-in from teams that build tools
> on top of Mercurial for *yet another branching method*. I can promise
> that your proposals will only set back any progress made so far.
>
> For what it's worth, I've started to work on another repo implementing
> what Erik suggested. It removes 'stacks' (since that's obviously out of
> scope) and implements a topic-like branch workflow. So far, it's been a
> good experiment and requires very little change. I'll post here once I
> have more feedback.
>
> [1] http://xkcd.com/974/

I want to agree with Erik and you that overloading the existing branches
metadata is the right thing to do. But I don't think it is practical for
reasons Pierre-Yves outlined.

One of Pierre-Yves's posts touched on this, but I want to explicitly call
out that if topics used existing branches fields, as soon as topics were
created on a highly used repo like mozilla-central, users on legacy clients
would start to see a proliferation of named branches and this could be
confusing. The only way to stop that while using branches metadata is to
mark the branch as closed (which required metadata in a changeset) and that
would seemingly preclude topics from automatically fading away as their
phase is made public (because you need to modify the SHA-1 to add the
closure metadata).

I'm not keen of "yet another branching method" (it is already a fair
criticism of Mercurial today). But I don't see how we can shoehorn topics
metadata into branches metadata without bad side-effects.

As was mentioned, new metadata for topics means old clients see a bunch of
anonymous heads on changesets that have topics. That is also horrible. The
planned `hg display` will have views of non-public heads to make grokking
this easier. But we're talking about legacy clients, so they won't have `hg
display`. Perhaps some server-side magic could be leveraged here. For
example, a server could not serve changesets with topics metadata unless
clients are topics aware. Or, a server could advertise bookmarks
corresponding to topic names when the client isn't topics aware. There are
some obvious problems with those approaches. But it might be acceptable to
some server operators. I think we should consider what server-side
mitigations might look like.

I also think adding an official extension (or even core feature) to prevent
name collisions across all "namespaces" would be a welcome feature addition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161101/1e123470/attachment-0001.html>