Topics [was: news from the topic experiment]

[Pierre-Yves David]

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

Cheers,

-- 
Pierre-Yves David