On 10/14/2016 07:29 PM, Erik van Zijst wrote:
On Fri, Oct 14, 2016 at 9:54 AM, Pierre-Yves David
<pierre-yves.da...@ens-lyon.org> wrote:
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)

Why would a topic imply that it is on the default branch? I don't
think I see that. In my mental model a topic is really just a branch,
just like any named branch. What does it mean for a topic to be "on
the default branch"? What does that facilitate?

The current rules are:
* without branch information, a changeset is on the default branch,
* When a changeset is public, the topic fade away and stop applying to the changeset.

You proposal is:
* let's use the branch field for topic  + a flag (if I got that right)

So the result of this is:
* When a changeset turns public we stop reading the topic data, the changeset. As the changeset have no other information, it is on the default branch.

However, going deeper on this made me realize that we cannot use the branch field for anything topic related. A strong part of topic is that it fades away when it become public. An old client will not have any logic to enforce the fade out of the topic informations. So we cannot expose the topic information to any old client as they would wrongly keep being affected by closed topic.

Sadly this also affect the BRANCH:TOPIC idea.

If one insists on some form of named-branch-context, then wouldn't
that simply be the named branch that the topic was originally forked
off of? I don't think I see the need for that information to be
carried forward in every topic commit.

The current way branch works is by having a dedicated field stored in all changesets. The work around topic is not planning to change that and this will probably be true until the end of time for backward compatibility reason.


Pierre-Yves David
Mercurial-devel mailing list

Reply via email to