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.
Cheers,
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
