Re: Topics [was: news from the topic experiment]

[timeless]

Sean Farley wrote:
> For what it's worth, I've started to work on another repo implementing
> what Erik suggested. It removes 'stacks' (since that's obviously out of
> scope) and implements a topic-like branch workflow. So far, it's been a
> good experiment and requires very little change. I'll post here once I
> have more feedback.

Gregory Szorc wrote:
> I want to agree with Erik and you that overloading the existing branches
> metadata is the right thing to do. But I don't think it is practical for
> reasons Pierre-Yves outlined.

> One of Pierre-Yves's posts touched on this, but I want to explicitly call
> out that if topics used existing branches fields, as soon as topics were
> created on a highly used repo like mozilla-central, users on legacy clients
> would start to see a proliferation of named branches and this could be
> confusing.

> The only way to stop that while using branches metadata is to
> mark the branch as closed (which required metadata in a changeset) and that
> would seemingly preclude topics from automatically fading away as their
> phase is made public (because you need to modify the SHA-1 to add the
> closure metadata).

An alternative is to treat branches that are `topic` as `secret` to
clients that aren't aware of `topic`.
We already have `secret`, and there's already a concept of `hidden`,
and `serve` already has pluggable support.

I wonder if that's enough to enable a story where mozilla-central (and
any other similar project with both modern developers and
non-upgrading users) isn't broken

> I'm not keen of "yet another branching method" (it is already a fair
> criticism of Mercurial today). But I don't see how we can shoehorn topics
> metadata into branches metadata without bad side-effects.
>
> As was mentioned, new metadata for topics means old clients see a bunch of
> anonymous heads on changesets that have topics. That is also horrible.

If topic-branches are treated as effectively secret, and thus
invisible to old clients, does that address your problem?
They would not see the anonymous heads, and thus there should be no horror.

> The
> planned `hg display` will have views of non-public heads to make grokking
> this easier. But we're talking about legacy clients, so they won't have `hg
> display`.

> Perhaps some server-side magic could be leveraged here. For
> example, a server could not serve changesets with topics metadata unless
> clients are topics aware.

Oh, great, you came to the same approach as I did :)

> Or, a server could advertise bookmarks corresponding to topic names
> when the client isn't topics aware.

> There are some obvious problems with those approaches.
> But it might be acceptable to some server operators.
> I think we should consider what server-side mitigations might look like.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topics [was: news from the topic experiment]

[Sean Farley]

Pierre-Yves David  writes:

> On 11/01/2016 05:56 AM, Sean Farley wrote:
>> Pierre-Yves David  writes:
>>
>>> On 10/15/2016 04:18 PM, Pierre-Yves David wrote:


 On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
>> Pierre-Yves David  writes:
>>> 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.
>>
>> I don't see that. Currently, we have:
>>
>> - old client cannot see topic at all (making it unusable)
>> - new client can see topics
>>
>> If we move to branchname + flag, we have:
>>
>> - old client can see and update using 'hg update NAME' (extremely
>>   valuable)
>> - old client can merge a topic to default (extremely helpful and
>> surprising)
>> - new client will hide those branches
>>
>> Your argument is that old clients will see those branches. That's a much
>> better side-effect than not being able to update at all to a topic
>> branch.
>
> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
> "BRANCH" is
> bad because you can't filter log by "branch(BRANCH)" in old client.
>>>
>>> Exposing topic directly into the branch field means that all the
>>> behavior related to named branch will be broken for old clients once
>>> someone start using topic in the repository.
>>>
>>>
>>> For example, if a team is using the "foo" branch for development,
>>> tracking the head of "foo" is important. Mercurial keeps a set of
>>> behavior user rely on, eg: hg up "foo" works, and with this branch
>>> active, "hg up" or "hg merge" pick the right head.
>>>
>>> Now, let's assume the topic information is part of the "branch" field,
>>> someone in the team start using topic and do some work on the "bar"
>>> topic, their changeset will contains topic informations. For that user,
>>> the topic information will just fade away when pushed to the public
>>> server. The server will not expose that topic information (because the
>>> changeset is public and the server is new), Other team member pulling
>>> with a new client will see the "foo" branch move forward as expected
>>> without mention of the "bar" topic.
>>> However (if the topic information is part of the "branch" field), old
>>> clients pulling from that server will get a different result. Instead of
>>> having "foo" move forward, they will get a new branch "foo:bar". The
>>> branch "foo" will be stuck behind until someone hopefully do work
>>> without topic. Breaking the behavior described earlier. In addition this
>>> new branch might break various other automation that would now refuse to
>>> push a new branch.
>>>
>>> This highlight how important the control of topic life cycle is. Topics
>>> must be able to disappear for public changeset. This is the feature that
>>> allow the rest of the Mercurial work flows to  keep working for
>>> immutable changeset. And this requires the meaning of the "branch" field
>>> to stay backward compatible.
>>> As a side note, I would like to emphasize that having advanced users
>>> about to try out topic without poisoning the common well will be
>>> important for adoption.
>>
>> I think your logic is very contrived here.
>
> I'm using a full example to show how reusing the same field leads to issue.

As I pointed out to Greg, I don't think it's that bad. In fact, I think
it's preferable.

>> No, branch names don't have to disappear. That's no "a requirement" as you 
>> say.
>
> If we could use plain named branch, plain named branch would have an 
> absolute success and every single users would be using them as their 
> core workflow. We are 10 years after their introduction this is not the 
> case. I don't see why they would become the solution we seek for feature 
> branching. The same way, one of the major issue with bookmark is there 
> life cycle and how hard it is to get ride of them. This highlight how 
> important having feature branch name able to fade away is important.

That's not quite true. I think plain named branches are fine. Closing
them, however, is the problematic part. And that is what Erik and I are
proposing: changing how they are closed (via this metadata is_topic
field).

>> What you are suggesting is very over-engineered [1]. Though, it is getting 
>> late here
>> and I can respond more tomorrow.
>
> I'm not sure what you are referencing with by "what I suggest" 

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 11/01/2016 04:55 PM, Gregory Szorc wrote:

On Mon, Oct 31, 2016 at 9:56 PM, Sean Farley > wrote:

Pierre-Yves David > writes:

> On 10/15/2016 04:18 PM, Pierre-Yves David wrote:
>>
>>
>> On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
>>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
 Pierre-Yves David > writes:
> 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.

 I don't see that. Currently, we have:

 - old client cannot see topic at all (making it unusable)
 - new client can see topics

 If we move to branchname + flag, we have:

 - old client can see and update using 'hg update NAME' (extremely
   valuable)
 - old client can merge a topic to default (extremely helpful and
 surprising)
 - new client will hide those branches

 Your argument is that old clients will see those branches.
That's a much
 better side-effect than not being able to update at all to a topic
 branch.
>>>
>>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
>>> "BRANCH" is
>>> bad because you can't filter log by "branch(BRANCH)" in old client.
>
> Exposing topic directly into the branch field means that all the
> behavior related to named branch will be broken for old clients once
> someone start using topic in the repository.
>
>
> For example, if a team is using the "foo" branch for development,
> tracking the head of "foo" is important. Mercurial keeps a set of
> behavior user rely on, eg: hg up "foo" works, and with this branch
> active, "hg up" or "hg merge" pick the right head.
>
> Now, let's assume the topic information is part of the "branch" field,
> someone in the team start using topic and do some work on the "bar"
> topic, their changeset will contains topic informations. For that
user,
> the topic information will just fade away when pushed to the public
> server. The server will not expose that topic information (because the
> changeset is public and the server is new), Other team member pulling
> with a new client will see the "foo" branch move forward as expected
> without mention of the "bar" topic.
> However (if the topic information is part of the "branch" field), old
> clients pulling from that server will get a different result.
Instead of
> having "foo" move forward, they will get a new branch "foo:bar". The
> branch "foo" will be stuck behind until someone hopefully do work
> without topic. Breaking the behavior described earlier. In
addition this
> new branch might break various other automation that would now
refuse to
> push a new branch.
>
> This highlight how important the control of topic life cycle is.
Topics
> must be able to disappear for public changeset. This is the
feature that
> allow the rest of the Mercurial work flows to  keep working for
> immutable changeset. And this requires the meaning of the "branch"
field
> to stay backward compatible.
> As a side note, I would like to emphasize that having advanced users
> about to try out topic without poisoning the common well will be
> important for adoption.

I think your logic is very contrived here. No, branch names don't have
to disappear. That's no "a requirement" as you say. What you are
suggesting is very over-engineered [1]. Though, it is getting late here
and I can respond more tomorrow.

> I'm confident we can find interesting solution for the various
> inconvenient the old client will see. For example, (random though), we
> could not serve topic changesets to old client by default, while still
> honoring explicit requests in the form "branch:topic".
>
>
> Mercurial have been using this strategy of ignoring new data in the
> past. For example, when named branch or bookmark where introduced in the
> past, old client where able to interact with repository using the new
> repo without too much behavior impact.

Not interested. There is already no buy-in from teams that build tools
on top of 

Re: Topics [was: news from the topic experiment]

[Sean Farley]

Gregory Szorc  writes:

> On Mon, Oct 31, 2016 at 9:56 PM, Sean Farley  wrote:
>
>> Pierre-Yves David  writes:
>>
>> > On 10/15/2016 04:18 PM, Pierre-Yves David wrote:
>> >>
>> >>
>> >> On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
>> >>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
>>  Pierre-Yves David  writes:
>> > 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.
>> 
>>  I don't see that. Currently, we have:
>> 
>>  - old client cannot see topic at all (making it unusable)
>>  - new client can see topics
>> 
>>  If we move to branchname + flag, we have:
>> 
>>  - old client can see and update using 'hg update NAME' (extremely
>>    valuable)
>>  - old client can merge a topic to default (extremely helpful and
>>  surprising)
>>  - new client will hide those branches
>> 
>>  Your argument is that old clients will see those branches. That's a
>> much
>>  better side-effect than not being able to update at all to a topic
>>  branch.
>> >>>
>> >>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
>> >>> "BRANCH" is
>> >>> bad because you can't filter log by "branch(BRANCH)" in old client.
>> >
>> > Exposing topic directly into the branch field means that all the
>> > behavior related to named branch will be broken for old clients once
>> > someone start using topic in the repository.
>> >
>> >
>> > For example, if a team is using the "foo" branch for development,
>> > tracking the head of "foo" is important. Mercurial keeps a set of
>> > behavior user rely on, eg: hg up "foo" works, and with this branch
>> > active, "hg up" or "hg merge" pick the right head.
>> >
>> > Now, let's assume the topic information is part of the "branch" field,
>> > someone in the team start using topic and do some work on the "bar"
>> > topic, their changeset will contains topic informations. For that user,
>> > the topic information will just fade away when pushed to the public
>> > server. The server will not expose that topic information (because the
>> > changeset is public and the server is new), Other team member pulling
>> > with a new client will see the "foo" branch move forward as expected
>> > without mention of the "bar" topic.
>> > However (if the topic information is part of the "branch" field), old
>> > clients pulling from that server will get a different result. Instead of
>> > having "foo" move forward, they will get a new branch "foo:bar". The
>> > branch "foo" will be stuck behind until someone hopefully do work
>> > without topic. Breaking the behavior described earlier. In addition this
>> > new branch might break various other automation that would now refuse to
>> > push a new branch.
>> >
>> > This highlight how important the control of topic life cycle is. Topics
>> > must be able to disappear for public changeset. This is the feature that
>> > allow the rest of the Mercurial work flows to  keep working for
>> > immutable changeset. And this requires the meaning of the "branch" field
>> > to stay backward compatible.
>> > As a side note, I would like to emphasize that having advanced users
>> > about to try out topic without poisoning the common well will be
>> > important for adoption.
>>
>> I think your logic is very contrived here. No, branch names don't have
>> to disappear. That's no "a requirement" as you say. What you are
>> suggesting is very over-engineered [1]. Though, it is getting late here
>> and I can respond more tomorrow.
>>
>> > I'm confident we can find interesting solution for the various
>> > inconvenient the old client will see. For example, (random though), we
>> > could not serve topic changesets to old client by default, while still
>> > honoring explicit requests in the form "branch:topic".
>> >
>> >
>> > Mercurial have been using this strategy of ignoring new data in the
>> > past. For example, when named branch or bookmark where introduced in the
>> > past, old client where able to interact with repository using the new
>> > repo without too much behavior impact.
>>
>> Not interested. There is already no buy-in from teams that build tools
>> on top of Mercurial for *yet another branching method*. I can promise
>> that your proposals will only set back any progress made so far.
>>
>> For what it's worth, I've started to work on another repo implementing
>> what Erik suggested. It 

Re: Topics [was: news from the topic experiment]

[Gregory Szorc]

On Mon, Oct 31, 2016 at 9:56 PM, Sean Farley  wrote:

> Pierre-Yves David  writes:
>
> > On 10/15/2016 04:18 PM, Pierre-Yves David wrote:
> >>
> >>
> >> On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
> >>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
>  Pierre-Yves David  writes:
> > 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.
> 
>  I don't see that. Currently, we have:
> 
>  - old client cannot see topic at all (making it unusable)
>  - new client can see topics
> 
>  If we move to branchname + flag, we have:
> 
>  - old client can see and update using 'hg update NAME' (extremely
>    valuable)
>  - old client can merge a topic to default (extremely helpful and
>  surprising)
>  - new client will hide those branches
> 
>  Your argument is that old clients will see those branches. That's a
> much
>  better side-effect than not being able to update at all to a topic
>  branch.
> >>>
> >>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
> >>> "BRANCH" is
> >>> bad because you can't filter log by "branch(BRANCH)" in old client.
> >
> > Exposing topic directly into the branch field means that all the
> > behavior related to named branch will be broken for old clients once
> > someone start using topic in the repository.
> >
> >
> > For example, if a team is using the "foo" branch for development,
> > tracking the head of "foo" is important. Mercurial keeps a set of
> > behavior user rely on, eg: hg up "foo" works, and with this branch
> > active, "hg up" or "hg merge" pick the right head.
> >
> > Now, let's assume the topic information is part of the "branch" field,
> > someone in the team start using topic and do some work on the "bar"
> > topic, their changeset will contains topic informations. For that user,
> > the topic information will just fade away when pushed to the public
> > server. The server will not expose that topic information (because the
> > changeset is public and the server is new), Other team member pulling
> > with a new client will see the "foo" branch move forward as expected
> > without mention of the "bar" topic.
> > However (if the topic information is part of the "branch" field), old
> > clients pulling from that server will get a different result. Instead of
> > having "foo" move forward, they will get a new branch "foo:bar". The
> > branch "foo" will be stuck behind until someone hopefully do work
> > without topic. Breaking the behavior described earlier. In addition this
> > new branch might break various other automation that would now refuse to
> > push a new branch.
> >
> > This highlight how important the control of topic life cycle is. Topics
> > must be able to disappear for public changeset. This is the feature that
> > allow the rest of the Mercurial work flows to  keep working for
> > immutable changeset. And this requires the meaning of the "branch" field
> > to stay backward compatible.
> > As a side note, I would like to emphasize that having advanced users
> > about to try out topic without poisoning the common well will be
> > important for adoption.
>
> I think your logic is very contrived here. No, branch names don't have
> to disappear. That's no "a requirement" as you say. What you are
> suggesting is very over-engineered [1]. Though, it is getting late here
> and I can respond more tomorrow.
>
> > I'm confident we can find interesting solution for the various
> > inconvenient the old client will see. For example, (random though), we
> > could not serve topic changesets to old client by default, while still
> > honoring explicit requests in the form "branch:topic".
> >
> >
> > Mercurial have been using this strategy of ignoring new data in the
> > past. For example, when named branch or bookmark where introduced in the
> > past, old client where able to interact with repository using the new
> > repo without too much behavior impact.
>
> Not interested. There is already no buy-in from teams that build tools
> on top of Mercurial for *yet another branching method*. I can promise
> that your proposals will only set back any progress made so far.
>
> For what it's worth, I've started to work on another repo implementing
> what Erik suggested. It removes 'stacks' (since that's obviously out of
> scope) and implements a topic-like branch workflow. So far, it's been a
> good experiment and requires 

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 11/01/2016 05:56 AM, Sean Farley wrote:

Pierre-Yves David  writes:


On 10/15/2016 04:18 PM, Pierre-Yves David wrote:



On 10/15/2016 08:47 AM, Yuya Nishihara wrote:

On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:

Pierre-Yves David  writes:

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.


I don't see that. Currently, we have:

- old client cannot see topic at all (making it unusable)
- new client can see topics

If we move to branchname + flag, we have:

- old client can see and update using 'hg update NAME' (extremely
  valuable)
- old client can merge a topic to default (extremely helpful and
surprising)
- new client will hide those branches

Your argument is that old clients will see those branches. That's a much
better side-effect than not being able to update at all to a topic
branch.


I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
"BRANCH" is
bad because you can't filter log by "branch(BRANCH)" in old client.


Exposing topic directly into the branch field means that all the
behavior related to named branch will be broken for old clients once
someone start using topic in the repository.


For example, if a team is using the "foo" branch for development,
tracking the head of "foo" is important. Mercurial keeps a set of
behavior user rely on, eg: hg up "foo" works, and with this branch
active, "hg up" or "hg merge" pick the right head.

Now, let's assume the topic information is part of the "branch" field,
someone in the team start using topic and do some work on the "bar"
topic, their changeset will contains topic informations. For that user,
the topic information will just fade away when pushed to the public
server. The server will not expose that topic information (because the
changeset is public and the server is new), Other team member pulling
with a new client will see the "foo" branch move forward as expected
without mention of the "bar" topic.
However (if the topic information is part of the "branch" field), old
clients pulling from that server will get a different result. Instead of
having "foo" move forward, they will get a new branch "foo:bar". The
branch "foo" will be stuck behind until someone hopefully do work
without topic. Breaking the behavior described earlier. In addition this
new branch might break various other automation that would now refuse to
push a new branch.

This highlight how important the control of topic life cycle is. Topics
must be able to disappear for public changeset. This is the feature that
allow the rest of the Mercurial work flows to  keep working for
immutable changeset. And this requires the meaning of the "branch" field
to stay backward compatible.
As a side note, I would like to emphasize that having advanced users
about to try out topic without poisoning the common well will be
important for adoption.


I think your logic is very contrived here.


I'm using a full example to show how reusing the same field leads to issue.


No, branch names don't have to disappear. That's no "a requirement" as you say.


If we could use plain named branch, plain named branch would have an 
absolute success and every single users would be using them as their 
core workflow. We are 10 years after their introduction this is not the 
case. I don't see why they would become the solution we seek for feature 
branching. The same way, one of the major issue with bookmark is there 
life cycle and how hard it is to get ride of them. This highlight how 
important having feature branch name able to fade away is important.



What you are suggesting is very over-engineered [1]. Though, it is getting late 
here
and I can respond more tomorrow.


I'm not sure what you are referencing with by "what I suggest" here. can 
you be a bit more specific?



I'm confident we can find interesting solution for the various
inconvenient the old client will see. For example, (random though), we
could not serve topic changesets to old client by default, while still
honoring explicit requests in the form "branch:topic".

Mercurial have been using this strategy of ignoring new data in the
past. For example, when named branch or bookmark where introduced in the
past, old client where able to interact with repository using the new
repo without too much behavior impact.


Not interested. There is already no buy-in from teams that build tools
on top of Mercurial for *yet another branching method*. I can promise
that your proposals will only set back any progress made so far.


This is not 

Re: Topics [was: news from the topic experiment]

[Sean Farley]

Pierre-Yves David  writes:

> On 10/15/2016 04:18 PM, Pierre-Yves David wrote:
>>
>>
>> On 10/15/2016 08:47 AM, Yuya Nishihara wrote:
>>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
 Pierre-Yves David  writes:
> 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.

 I don't see that. Currently, we have:

 - old client cannot see topic at all (making it unusable)
 - new client can see topics

 If we move to branchname + flag, we have:

 - old client can see and update using 'hg update NAME' (extremely
   valuable)
 - old client can merge a topic to default (extremely helpful and
 surprising)
 - new client will hide those branches

 Your argument is that old clients will see those branches. That's a much
 better side-effect than not being able to update at all to a topic
 branch.
>>>
>>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
>>> "BRANCH" is
>>> bad because you can't filter log by "branch(BRANCH)" in old client.
>
> Exposing topic directly into the branch field means that all the 
> behavior related to named branch will be broken for old clients once 
> someone start using topic in the repository.
>
>
> For example, if a team is using the "foo" branch for development, 
> tracking the head of "foo" is important. Mercurial keeps a set of 
> behavior user rely on, eg: hg up "foo" works, and with this branch 
> active, "hg up" or "hg merge" pick the right head.
>
> Now, let's assume the topic information is part of the "branch" field, 
> someone in the team start using topic and do some work on the "bar" 
> topic, their changeset will contains topic informations. For that user, 
> the topic information will just fade away when pushed to the public 
> server. The server will not expose that topic information (because the 
> changeset is public and the server is new), Other team member pulling 
> with a new client will see the "foo" branch move forward as expected 
> without mention of the "bar" topic.
> However (if the topic information is part of the "branch" field), old 
> clients pulling from that server will get a different result. Instead of 
> having "foo" move forward, they will get a new branch "foo:bar". The 
> branch "foo" will be stuck behind until someone hopefully do work 
> without topic. Breaking the behavior described earlier. In addition this 
> new branch might break various other automation that would now refuse to 
> push a new branch.
>
> This highlight how important the control of topic life cycle is. Topics 
> must be able to disappear for public changeset. This is the feature that 
> allow the rest of the Mercurial work flows to  keep working for 
> immutable changeset. And this requires the meaning of the "branch" field 
> to stay backward compatible.
> As a side note, I would like to emphasize that having advanced users 
> about to try out topic without poisoning the common well will be 
> important for adoption.

I think your logic is very contrived here. No, branch names don't have
to disappear. That's no "a requirement" as you say. What you are
suggesting is very over-engineered [1]. Though, it is getting late here
and I can respond more tomorrow.

> I'm confident we can find interesting solution for the various 
> inconvenient the old client will see. For example, (random though), we 
> could not serve topic changesets to old client by default, while still 
> honoring explicit requests in the form "branch:topic".
>
>
> Mercurial have been using this strategy of ignoring new data in the 
> past. For example, when named branch or bookmark where introduced in the 
> past, old client where able to interact with repository using the new 
> repo without too much behavior impact.

Not interested. There is already no buy-in from teams that build tools
on top of Mercurial for *yet another branching method*. I can promise
that your proposals will only set back any progress made so far.

For what it's worth, I've started to work on another repo implementing
what Erik suggested. It removes 'stacks' (since that's obviously out of
scope) and implements a topic-like branch workflow. So far, it's been a
good experiment and requires very little change. I'll post here once I
have more feedback.

[1] http://xkcd.com/974/
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 10/15/2016 04:18 PM, Pierre-Yves David wrote:



On 10/15/2016 08:47 AM, Yuya Nishihara wrote:

On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:

Pierre-Yves David  writes:

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.


I don't see that. Currently, we have:

- old client cannot see topic at all (making it unusable)
- new client can see topics

If we move to branchname + flag, we have:

- old client can see and update using 'hg update NAME' (extremely
  valuable)
- old client can merge a topic to default (extremely helpful and
surprising)
- new client will hide those branches

Your argument is that old clients will see those branches. That's a much
better side-effect than not being able to update at all to a topic
branch.


I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding
"BRANCH" is
bad because you can't filter log by "branch(BRANCH)" in old client.


Exposing topic directly into the branch field means that all the 
behavior related to named branch will be broken for old clients once 
someone start using topic in the repository.



For example, if a team is using the "foo" branch for development, 
tracking the head of "foo" is important. Mercurial keeps a set of 
behavior user rely on, eg: hg up "foo" works, and with this branch 
active, "hg up" or "hg merge" pick the right head.


Now, let's assume the topic information is part of the "branch" field, 
someone in the team start using topic and do some work on the "bar" 
topic, their changeset will contains topic informations. For that user, 
the topic information will just fade away when pushed to the public 
server. The server will not expose that topic information (because the 
changeset is public and the server is new), Other team member pulling 
with a new client will see the "foo" branch move forward as expected 
without mention of the "bar" topic.
However (if the topic information is part of the "branch" field), old 
clients pulling from that server will get a different result. Instead of 
having "foo" move forward, they will get a new branch "foo:bar". The 
branch "foo" will be stuck behind until someone hopefully do work 
without topic. Breaking the behavior described earlier. In addition this 
new branch might break various other automation that would now refuse to 
push a new branch.


This highlight how important the control of topic life cycle is. Topics 
must be able to disappear for public changeset. This is the feature that 
allow the rest of the Mercurial work flows to  keep working for 
immutable changeset. And this requires the meaning of the "branch" field 
to stay backward compatible.
As a side note, I would like to emphasize that having advanced users 
about to try out topic without poisoning the common well will be 
important for adoption.



I'm confident we can find interesting solution for the various 
inconvenient the old client will see. For example, (random though), we 
could not serve topic changesets to old client by default, while still 
honoring explicit requests in the form "branch:topic".



Mercurial have been using this strategy of ignoring new data in the 
past. For example, when named branch or bookmark where introduced in the 
past, old client where able to interact with repository using the new 
repo without too much behavior impact.


Cheers,

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

Re: Topics [was: news from the topic experiment]

[Yuya Nishihara]

On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote:
> Pierre-Yves David  writes:
> > 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.
> 
> I don't see that. Currently, we have:
> 
> - old client cannot see topic at all (making it unusable)
> - new client can see topics
> 
> If we move to branchname + flag, we have:
> 
> - old client can see and update using 'hg update NAME' (extremely
>   valuable)
> - old client can merge a topic to default (extremely helpful and surprising)
> - new client will hide those branches
> 
> Your argument is that old clients will see those branches. That's a much
> better side-effect than not being able to update at all to a topic
> branch.

I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding "BRANCH" is
bad because you can't filter log by "branch(BRANCH)" in old client.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topics [was: news from the topic experiment]

[Sean Farley]

Pierre-Yves David  writes:

> On 10/14/2016 05:48 PM, Erik van Zijst wrote:
>> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>> >
>> 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.

I don't see that. Currently, we have:

- old client cannot see topic at all (making it unusable)
- new client can see topics

If we move to branchname + flag, we have:

- old client can see and update using 'hg update NAME' (extremely
  valuable)
- old client can merge a topic to default (extremely helpful and surprising)
- new client will hide those branches

Your argument is that old clients will see those branches. That's a 

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 10/14/2016 05:48 PM, Erik van Zijst wrote:

On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>
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

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 10/14/2016 07:29 PM, Erik van Zijst wrote:

On Fri, Oct 14, 2016 at 9:54 AM, Pierre-Yves David
 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

Re: Topics [was: news from the topic experiment]

[Augie Fackler]

> On Oct 14, 2016, at 1:29 PM, Erik van Zijst  wrote:
> 
>> * 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?
> 
> 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.

I agree.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topics [was: news from the topic experiment]

[Erik van Zijst]

On Fri, Oct 14, 2016 at 9:54 AM, Pierre-Yves David
 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?

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.

-E
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topics [was: news from the topic experiment]

[Sean Farley]

Erik van Zijst  writes:

> On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David <
> 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?

I hadn't thought of these two situations. I am now of the opinion that
this is extremely confusing and undesirable.

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

What about other hosting services (e.g. kallithea)? Requiring them to
adjust their UI and data model to accommodate a sub-branch name /
different namespace is quite onerous at this point.

Having 'hg up NAME' work with existing tools and expected behavior (not
to mention a developer's mental model) is such a clear win that I am
pretty strongly for it.

Plus, it doesn't 

Re: Topics [was: news from the topic experiment]

[Pierre-Yves David]

On 10/14/2016 05:48 PM, Erik van Zijst wrote:

On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David
>
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 

Re: Topics [was: news from the topic experiment]

[Erik van Zijst]

On Thu, Oct 13, 2016 at 7:01 AM, Pierre-Yves David <
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.

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
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel