Topics [was: news from the topic experiment]

Sean Farley sean at farley.io
Tue Nov 1 00:56:26 EDT 2016


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/


More information about the Mercurial-devel mailing list