Topics [was: news from the topic experiment]

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Oct 14 12:54:25 EDT 2016


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?

If we use the same field for either topic or name branch a changeset can 
either be:

  * on a named branch but no topic
  * on a topic but no named branch (so default branch)

As a result, when the changeset become public we end up with:

  * on a named branch [no topic]
  * on the default branch [no topic]

So using named branch and topic on the same project become 
impossible//impracticable as topic is restricted to the default branch 
me and I cannot use topic when targeting a named branch (also meh).

(I'm repeating myself a lot here, but I'm still unsure if I managed to 
get the idea through)

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

I'm not claiming having different namespace is preventing name collision 
between topic and branch. It does not. What I'm saying it that your 
proposal of using the branch field and a flag does not prevent it either.

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

[yep, name colision are possible]

> 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?\

Yes, topic on multiple branch is something we need to iron more in the 
future.

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

[None, I'm just saying that using the same field does not seems to have 
advantages either]

>         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

Maybe we could make the full name name branch:topic be a valid reference 
to have the transistion from old install to new install valid.

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

I agree with you that we have to think about that aspect of the 
compatibility. I had not really realized that myself so thanks for 
bringing it up.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list