Topics [was: news from the topic experiment]

[Sean Farley]

Erik van Zijst <erik.van.zijst at gmail.com> writes:

> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David <
> 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?

I hadn't thought of these two situations. I am now of the opinion that
this is extremely confusing and undesirable.

>> 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.
>
> That said, the situation might be different for CI servers and generally
> any other automated tool that doesn't anticipate the (in their legacy view,
> illegal branch name). Assuming new clients would still hide the prefix in
> their UI (and so would Bitbucket), telling a legacy CI server to checkout
> topic "foo" would likely fail.
>
> I understand we might be driven by somewhat different motivations. The
> prospect to some level of compatibility with existing tools (not
> necessarily just an old hg client) I think is huge in our world. If
> Bitbucket teams couldn't switch to using topics until all CI and deployment
> infrastructure had been patched and upgraded first, that might lead to a
> chicken-and-egg problem.

What about other hosting services (e.g. kallithea)? Requiring them to
adjust their UI and data model to accommodate a sub-branch name /
different namespace is quite onerous at this point.

Having 'hg up NAME' work with existing tools and expected behavior (not
to mention a developer's mental model) is such a clear win that I am
pretty strongly for it.

Plus, it doesn't preclude having a new namespace in the future (':' is
banned from a name so we could still use it as a separator).