Topics [was: news from the topic experiment]

[Sean Farley]

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

> On 10/14/2016 05:48 PM, Erik van Zijst wrote:
>> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>> wrote:
>>
>>
>>     So, thanks for exploring possibilities to make this frontier thiner.
>>     However, I can see some issues with some aspects of this proposal,
>>     using the same field for either branch or topic make them mostly
>>     mutually exclusive. Publishing a topic on a named branch would
>>     require to alter the changesets data (and therefore, hash) This
>>     means people could use topic only with the default branch (or
>>     significant more complexity to work around this). As I understand,
>>     Bitbucket enforces a single master branch so that might actually fit
>>     your model. This is probably too restricting for the general project
>>     (more about that later).
>>
>>
>> I'm not sure I understand. I would think that the mutually exclusive
>> part would be desirable, not a limitation. I'm not sure how that would
>> limit people to using only the default branch?
>>
>> One could still create 2 long-lived branched. The most common workflows
>> are based around gitflow and typically define 2 long-lived branches:
>> e.g. "master" and "develop". While Bitbucket only treats one branch as
>> the "main branch", most teams have more than 1 long-lived branch.
>> Bitbucket's main branch merely serves as the default pull request
>> destination and initial context for the source browser.
>>
>>         It would seem to me that this could have some benefits:
>>
>>         1. There would be no risk of a name collision between the branch and
>>         topic namespaces.
>>
>>
>>     I'm not certain this actually avoid the risk of name collision.
>>     People could use the same branch/topic name on different changesets
>>     with different values for the flag. That would lead to both a topic
>>     and a named branch to exists with the same name.
>>
>>
>> Clashes after pulling between forks are a reality. I could have a topic
>> "foo" and pull in a named branch "foo", this is true. However, I'm not
>> sure I see how a separate topic and branch namespace would solve that.
>>
>> If I have a topic "default:foo", I could pull a named branch "foo" and
>> unless we expose the prefix part in the topic name, that would get
>> ambiguous too.
>>
>> Additionally, a distinct namespace might open us up to more fork
>> ambiguity. I could pull a topic "develop:foo". Would that be considered
>> the same topic? Should it be merged with mine? Would it have a
>> consequence for the implicit merge/rebase target?
>>
>>
>>     In all cases we should have the local UI fight hard to prevent
>>     people to create collisions between branch and topic. (And some
>>     descent way to point out name conflict if they appends).
>>
>>
>> For sure. Though I'm not sure I see the advantage of separate namespace
>> in this situation.
>>
>>
>>         2. Interoperability with non-topic clients would mostly just work.
>>
>>         This could be a big boon for existing ecosystem tools like CI
>>         servers
>>         that wouldn't have to be modified.
>>
>>
>>     There is some very interesting ramification to this proposal. Even
>>     if we do not go with the flag approach. We store the full (branch,
>>     topic) pair into the branch field. For example we could use ":" as a
>>     separator branch=BRANCH:TOPIC. Not only this would allow old clients
>>     to transport the data (we already have that) but this also mean old
>>     client can also view and preserve that data (and this is new) even
>>     if it does not get the behavior improvement related to topic. That
>>     would be a large usability boost for old client.
>>
>>
>> I really like that idea and I hadn't considered myself. It would, at
>> least in theory, mean old clients won't wreak havoc and will be able to
>> see all topics and branches. They could even commit on top of a topic
>> without breaking anything.
>
> 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 think this is arguably better than the ambiguity of having
multiple heads, non-working CI builds, unclear forking workflows, etc.