Topics [was: news from the topic experiment]

[Sean Farley]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> On 11/01/2016 05:56 AM, Sean Farley 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.
>
> I'm using a full example to show how reusing the same field leads to issue.

As I pointed out to Greg, I don't think it's that bad. In fact, I think
it's preferable.

>> No, branch names don't have to disappear. That's no "a requirement" as you say.
>
> If we could use plain named branch, plain named branch would have an 
> absolute success and every single users would be using them as their 
> core workflow. We are 10 years after their introduction this is not the 
> case. I don't see why they would become the solution we seek for feature 
> branching. The same way, one of the major issue with bookmark is there 
> life cycle and how hard it is to get ride of them. This highlight how 
> important having feature branch name able to fade away is important.

That's not quite true. I think plain named branches are fine. Closing
them, however, is the problematic part. And that is what Erik and I are
proposing: changing how they are closed (via this metadata is_topic
field).

>> What you are suggesting is very over-engineered [1]. Though, it is getting late here
>> and I can respond more tomorrow.
>
> I'm not sure what you are referencing with by "what I suggest" here. can 
> you be a bit more specific?

Here is where I explain more:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/089843.html

>>> 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.
>
> This is not the feeling I got at the sprint.

The feeling from the sprint was that we'd try to implement topics on
Bitbucket. Erik made great progress on it but its design poses many
challenges (which Erik mentioned in a previous email).

It should also be pointed out that there is some serious underestimation
of the value of having tools mostly working (with little changes) with
Erik's proposal.

To be completely honest, topics as-is has little to no chance of making
it to Bitbucket. We have multiple tools that are built on our APIs (not
to mention we have Mercurial pipelines support, and SourceTree) and
having to add topics support (not to mention explaining
yet-another-branch-model!) is a non-starter for teams here.