Topics [was: news from the topic experiment]

[Yuya Nishihara]

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.