Topics [was: news from the topic experiment]

[Sean Farley]

Gregory Szorc <gregory.szorc at gmail.com> writes:

> 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 think the goal posts are being moved by this legacy client argument.
I'm going to try to outline each situation I have in mind:

* branch names

  - legacy client: will see lots of branches but can filter the list
    down
  - new client: will see the correct list of branches

* topic names

  - legacy client: *impossible* to disentangle to the correct head, will
    see thousands of anonymous heads
  - new client: will see the list of topics

Of the two situations with legacy clients, I think only one is
preferable: the ability to filter. Anonymous heads are already
confusing and basically impossible to work with after a handful.

I don't see why legacy clients seeing lots of branches is so bad
(especially compared to the alternative). The advice would be the same:

* branch names (I see too many branches)

  - legacy client: upgrade to a new client

* topic names (I see too many anonymous heads)

  - legacy client: upgrade to a new client

So, to me, branch names is absolutely preferable to topic names. (There
are other arguments to: yet another branch concept, third-party tools,
etc. but I will save that for another email.)