Topics [was: news from the topic experiment]

[Erik van Zijst]

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?


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

Cheers,
Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161014/7132a75c/attachment.html>