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.da...@ens-lyon.org <mailto:pierre-yves.da...@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.

So, the other branch of that thread made me realised that we cannot do this "BRANCH:TOPIC" storage in the current "branch" field.

An important part of topic is to have them fade away when the changesets become public. This fading away will be implemented client side (logic to stop reading the value). If we expose this data to old client who does not have this logic this means that topic would live as "BRANCH:TOPIC" forever on old client, breaking them in various way.

[sad panda]

I guess topic will keep being stored in there dedicated extra field then.

Cheers,

--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to