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

Re: news from the topic experiment

[Erik van Zijst]

Working on our Bitbucket spike I wondered if topics could perhaps
benefit from a small simplification. Instead of adding the topic name
as an additional field, what if we defined a topic commit by merely
adding a boolean property to the meta dict; e.g. `is_topic: True`?
Named branches would not have the property set.

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.

During our little Bitbucket spike and demo during the sprint we made
the assumption that topics and branches should never clash, which
allowed me to put them in the existing, single branches namespace.
This would seem desirable as topics are essentially branches, with the
only real difference being their anticipated longevity. This greatly
simplified the UI as hardly anything needed to be modified.

2. Interoperability with non-topic clients would mostly just work.

Currently, when cloning a topics repo with an old client, all topics
would appear as an amorphous mess of anonymous heads on default.
Instead, if we dropped the separate topic name field and just used the
branch name as the topic name, an old client would see the same layout
as a topic-enabled client and while an old client would not be able to
create new topic commits, read-only clients should be totally fine.
This could be a big boon for existing ecosystem tools like CI servers
that wouldn't have to be modified.

The only downside I can think of is that when the topic and original
branch name are separate fields, that a topic sort of remains
associated with the branch it was based on. This would provide
implicit merge and rebase targets and therefore slightly shorter
commands. However, I'm not sure that's worth giving up the above
points.

I do realize it's quite possible I'm overlooking other reasons for
having topics encoded as an additional namespace, separate from the
named branch name.

Cheers,
Erik

On Tue, Oct 11, 2016 at 11:29 AM, Gregory Szorc  wrote:
>
>
>> On Oct 10, 2016, at 10:51, Denis Laxalde  wrote:
>>
>> Gregory Szorc a écrit :
>>> There are still some areas for improving topics.
>>>
>>> 1) `hg log` still shows *all* changesets in the repository. This is
>>> confusing for users that don't want to be burdened with the complexity
>>> of multiple heads. I'd like the behavior of `hg log` to only show
>>> ancestors - and possibly descendants - of the working directory
>>> changeset when the working directory changeset is unpublished and has a
>>> topic. If we show descendants, we should delimit the current changeset
>>> somehow, possibly by making -G or a mode like it the default in this
>>> scenario. Realistically, I think `hg log` should behave like `hg log -f`
>>> and `hg log --children` should supplement that with descendants and a
>>> marking of the wdir changeset. If there is a branch point in the
>>> descendants, we should automatically add the graphical view because
>>> showing changesets from multiple DAG heads without the graphical view is
>>> really confusing. I can also make the argument that the graphical view
>>> should always be shown so merge commits can be rendered properly.
>>
>> It seems to me that, if we consider topics as lightweight *branches*, we
>> can improve (part of) this :
>>
>> * when on a topic, `hg log` could only show changesets in the current
>> topic (and their public ancestors);
>>
>> * when not on a topic, a bare `hg log` could only show changesets
>> without a topic;
>>
>> * with an additional -t/--topic option to log command, we could see
>> changesets of a particular topic even we not activated.
>
> Per discussion on Sunday, we decided to introduce "hg display " as a 
> new mechanism that essentially is a named (revset, template) pair to show 
> useful views of repository data (not necessarily limited to changeset data).
>
> We'll prefer to use "hg display" for common queries instead of adding yet 
> more functionality and special behavior to "hg log."
>
> I'll hopefully send out an RFC series soon that explains "hg display" in more 
> detail.
>
>>
>> Basically, just like with named branches, I think.
>>
>>
>> If we follow the same idea (topics are branches), why not considering
>> make `hg pull` behave differently with topics?
>>
>> I would imagine that `hg pull` will not fetch any changeset with a
>> topic unless the client is on a topic that got updated remotely. But,
>> the server response could list information about available topics,
>> something like:
>>
>>   remote: new topics "bugfix1", "newfeature22"
>>   remote: new changes in topics "foo"
>>   remote: topics "importbugfix", "docstringtypo" got published
>>
>> And add a -t/--topic option to `hg pull` to explicitly pull some topic(s).
>>
>> Here, this diverges from `hg pull` behavior with respect to named
>> branches (all branches are pulled by default). But this might be an
>> occasion to "fix" things?
>>
>> --
>> Denis 

Re: news from the topic experiment

[Denis Laxalde]

Gregory Szorc a écrit :

There are still some areas for improving topics.

1) `hg log` still shows *all* changesets in the repository. This is
confusing for users that don't want to be burdened with the complexity
of multiple heads. I'd like the behavior of `hg log` to only show
ancestors - and possibly descendants - of the working directory
changeset when the working directory changeset is unpublished and has a
topic. If we show descendants, we should delimit the current changeset
somehow, possibly by making -G or a mode like it the default in this
scenario. Realistically, I think `hg log` should behave like `hg log -f`
and `hg log --children` should supplement that with descendants and a
marking of the wdir changeset. If there is a branch point in the
descendants, we should automatically add the graphical view because
showing changesets from multiple DAG heads without the graphical view is
really confusing. I can also make the argument that the graphical view
should always be shown so merge commits can be rendered properly.


It seems to me that, if we consider topics as lightweight *branches*, we
can improve (part of) this :

* when on a topic, `hg log` could only show changesets in the current
topic (and their public ancestors);

* when not on a topic, a bare `hg log` could only show changesets
without a topic;

* with an additional -t/--topic option to log command, we could see
changesets of a particular topic even we not activated.

Basically, just like with named branches, I think.


If we follow the same idea (topics are branches), why not considering
make `hg pull` behave differently with topics?

I would imagine that `hg pull` will not fetch any changeset with a
topic unless the client is on a topic that got updated remotely. But,
the server response could list information about available topics,
something like:

   remote: new topics "bugfix1", "newfeature22"
   remote: new changes in topics "foo"
   remote: topics "importbugfix", "docstringtypo" got published

And add a -t/--topic option to `hg pull` to explicitly pull some topic(s).

Here, this diverges from `hg pull` behavior with respect to named
branches (all branches are pulled by default). But this might be an
occasion to "fix" things?

--
Denis Laxalde
Logilab http://www.logilab.fr
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Topic + Mozila [was news from the topic experiment]

[Gregory Szorc]

On Tue, Oct 4, 2016 at 6:57 PM, Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

>
>
> On 10/01/2016 09:36 PM, Gregory Szorc wrote:
>
>> On Thu, Sep 22, 2016 at 5:26 PM, Augie Fackler > > wrote:
>>
>>
>> > On Sep 22, 2016, at 8:18 PM, Pierre-Yves David <
>> pierre-yves.da...@ens-lyon.org
>> > wrote:
>> >
>> >>> I assume this is along the spirit of your 'hg undo' for evolve
>> (that
>> >>> preserves the hash)?
>> >>
>> >> No. We are thinking about using topic to replace bookmark as the
>> recommended
>> >> workflow at fb. People can get confused if local bookmarks point
>> to public
>> >> changesets.
>> >
>> > I would be happy to discuss that ;-)
>>
>> As would I. I’ve fielded several user complaints lately that boil
>> down to wanting an ephemeral, user-selected name for each draft
>> commit (a la what we had with mq patch names). I suspect topics
>> might be able to fill that niche as well.
>>
>>
>> Many long-time Mercurial users at Mozilla still use MQ. Having talked to
>> many of them, many of their arguments for using MQ all have a common
>> theme: "it's simpler." Specifically:
>>
>> * `hg qseries` provides a concise view of all their "in progress" work
>> * Individual commits have names which can be easily referenced - not
>> some random 12 character hexidecimal value
>> * The complexities of managing many active heads are hidden from them
>> (rebase, graft, log -G, etc)
>> * They like that they can edit patch files in .hg/patches if the VCS
>> gets in the way
>>
>> It's worth noting that the Firefox repository has N heads spread out
>> over M repositories. The Nightly head is in a different repository from
>> the Aurora head from the Beta head, etc. While each repository shares
>> the same root changeset and can be pulled into a "unified" repository
>> with multiple heads, many developers only clone/pull a single repo/head.
>> This means their local repo only has a single head by default. And if
>> you use MQ, your local clone continues to only have a single head.
>>
>
> Are these multiple heads identified in any way? Do you use named branch
> for this ? otherwise, how does someone can someone identify them when it
> pulls them all of them into a single repository.
>

Not in the canonical repos (sadly). We have an extension that adds names to
a custom namespace when pulling from these repos. We also have
https://hg.mozilla.org/mozilla-unified, which is a server-side aggregation
of these repos that uses bookmarks to track the heads (the same extension
converts these bookmarks to a namespace when pulling this repo).


>
> It is important to remember that there is a significant complexity jump
>> from a single head to multiple heads. Once you introduce multiple heads,
>> you need to understand:
>>
>> * The concept of a DAG
>> * How to find multiple heads
>> * How to figure out which head you are on
>> * How to switch your working directory to a different head
>> * How to copy/move changesets between heads (graft, rebase, etc)
>> * How to combine multiple heads (merging)
>> * How to push only what you want to push
>>
>> Mercurial makes many of these things difficult. For example:
>>
>> * `hg log` shows changesets from multiple heads without any indication
>> they are from multiple heads. Contrast with `hg log -G` or `hg log -f`.
>> * Existing feature development methods except for MQ (branches and
>> bookmarks) lack a command that concisely lists *all* of "my" commits
>> (`hg branches` and `hg bookmarks` only list the tip-most changeset and
>> don't show the changeset author or description by default).
>>
>
> I agree we need improvement here.
>
> But I'm not sure how that useful it is to be able to see all commits
> details in a single command. I've been using a mix of `hg topics --verbose`
> and `hg stack` for some time and I'm quite happy about it. The first one
> list the open works with some extra data. The second list the content of a
> specify topic.
>
> That said, none of that is showing the exact DAG relationship of these
> bits and that could be useful.
>
> * `hg rebase` must be explicitly enabled. Some users think this means
>> they shouldn't be using it.
>>
>
> I think the main reason it is still and extension is that the UI can get
> confusing. However last year improvement in the handling of default
> destination probably helped a lot there.
>
> I personally also wonder if we could not integrate the main feature
> directly in the merge commands (something like `hg merge --linear`)
>
> The fact it drops named branch is also a significant issue in my opinion
> (really looks like an implementation details/shortcoming that became a
> "feature").
>
> * `hg push` pushes all heads by default. Great if you are backing up
>> your work to a non-publishing repo. Bad if you are trying to land
>> something to the canonical repo.
>>
>
> Unfortunatly 

Re: news from the topic experiment

[Pulkit Goyal]

> * `hg rebase` must be explicitly enabled. Some users think this means they
> shouldn't be using it.

Yeah as someone who is learning Mercurial I agree, usually I/people think that
we need extensions when we are doing something which is not normal/general.

> * `hg push` pushes all heads by default. Great if you are backing up your
> work to a non-publishing repo. Bad if you are trying to land something to
> the canonical repo.
> * `hg update` and `hg pull -u`'s heuristic based model can result in
> surprises
> * No easy way to figure out how the current working directory revision
> relates to the overall repo/DAG
>
> Many of us have installed extensions, aliases, etc on our own machines or
> have rolled these out to our users to pave over these deficiencies. That
> works... where you have control to do that. It doesn't generally work in
> open source: people are at the whim of what Mercurial supports out of the
> box.
>
> Many of us also understand the concepts of distributed version control -
> what the DAG is, how to interact with it, etc. It is really easy to lose
> sight of the fact that most users simply want to get stuff done and they
> don't care about the complexities. They will learn the minimum number of
> commands required to accomplish what they set out to do. A version control
> tool is a barrier to them getting actual work done. They will choose the
> mechanism that is simplest and fastest.
>
> Despite all of Mercurial's current deficiencies in this area, it's worth
> noting that I think it's still better off than Git. If the leap from single
> to multiple heads is hard, try introducing remote refs, tracking branches,
> detached HEAD, the reflog, the staging area, etc. And on top of that add a
> convoluted CLI that makes grasping the concepts difficult. Many of the
> hardcore MQ users at Mozilla detest Git because it is too complex. Only with
> a baptism of fire and likely a lot of hand holding do they warm up to Git.
> And - get this - once they learn the power of the DAG, of rebasing and
> interactive history editing, they fall in love. They think Mercurial's MQ
> model is primitive. Then I show them how to do "Git like" multiple head
> development in Mercurial and they're like "oh, this is basically the same
> except there aren't the complexities of understanding refs, the staging
> area, etc - this is quite nice."
>
> So, topics.
>
> I desperately want topics to be a compelling replacement for die hard MQ
> users. That means that topics needs to maintain the simplicity of MQ as much
> as possible. If people start with a single head repository, topics needs to
> be as simple to use as MQ is, even if multiple topics do introduce multiple
> heads in the DAG. Yet topics should also provide the features needed by
> advanced users - those who fully understand how the DAG works and how to
> manipulate changesets within it.
>
> For the beginning user, Mercurial/topics needs to provide:
>
> * A mechanism to show all active lines of work (list the topics) (and
> possibly how they relate to each other and the underlying repository)
> * A mechanism to show the current line of work (and possibly how it related
> to the overall repository)
> * A mechanism to show/search for unfinished changesets
> * A mechanism to provide a human friendly name to a changeset
>
> I think the existing topics experiment shows a ton of promise in these
> areas. And as a bonus, the transition from a beginning topics user (1
> published head, 1 topic) to more advanced scenarios is much better than with
> MQ because you don't have to transition to different commands (away from the
> q* MQ commands): you simply add more advanced commands like "rebase" and
> "merge" to your skills set without having to relearn anything. I also love
> how topics "fade away" when changesets become published. That's such an
> improvement over having to manually delete things later. Just as long as the
> user knows when their topics disappear...
>
> There are still some areas for improving topics.
>
> 1) `hg log` still shows *all* changesets in the repository. This is

We should limit the output to a certain number and will be better if we have
hg log --all to get all changesets. Same in the case of hg tags. I
think its better
to limit output to a certain number and have an --all flag which is
quite common.

> confusing for users that don't want to be burdened with the complexity of
> multiple heads. I'd like the behavior of `hg log` to only show ancestors -
> and possibly descendants - of the working directory changeset when the
> working directory changeset is unpublished and has a topic. If we show
> descendants, we should delimit the current changeset somehow, possibly by
> making -G or a mode like it the default in this scenario. Realistically, I
> think `hg log` should behave like `hg log -f` and `hg log --children` should
> supplement that with descendants and a marking of the wdir changeset. If
> there is a branch point in the 

Re: news from the topic experiment

[Gregory Szorc]

On Thu, Sep 22, 2016 at 5:26 PM, Augie Fackler  wrote:

>
> > On Sep 22, 2016, at 8:18 PM, Pierre-Yves David <
> pierre-yves.da...@ens-lyon.org> wrote:
> >
> >>> I assume this is along the spirit of your 'hg undo' for evolve (that
> >>> preserves the hash)?
> >>
> >> No. We are thinking about using topic to replace bookmark as the
> recommended
> >> workflow at fb. People can get confused if local bookmarks point to
> public
> >> changesets.
> >
> > I would be happy to discuss that ;-)
>
> As would I. I’ve fielded several user complaints lately that boil down to
> wanting an ephemeral, user-selected name for each draft commit (a la what
> we had with mq patch names). I suspect topics might be able to fill that
> niche as well.
>

Many long-time Mercurial users at Mozilla still use MQ. Having talked to
many of them, many of their arguments for using MQ all have a common theme:
"it's simpler." Specifically:

* `hg qseries` provides a concise view of all their "in progress" work
* Individual commits have names which can be easily referenced - not some
random 12 character hexidecimal value
* The complexities of managing many active heads are hidden from them
(rebase, graft, log -G, etc)
* They like that they can edit patch files in .hg/patches if the VCS gets
in the way

It's worth noting that the Firefox repository has N heads spread out over M
repositories. The Nightly head is in a different repository from the Aurora
head from the Beta head, etc. While each repository shares the same root
changeset and can be pulled into a "unified" repository with multiple
heads, many developers only clone/pull a single repo/head. This means their
local repo only has a single head by default. And if you use MQ, your local
clone continues to only have a single head.

It is important to remember that there is a significant complexity jump
from a single head to multiple heads. Once you introduce multiple heads,
you need to understand:

* The concept of a DAG
* How to find multiple heads
* How to figure out which head you are on
* How to switch your working directory to a different head
* How to copy/move changesets between heads (graft, rebase, etc)
* How to combine multiple heads (merging)
* How to push only what you want to push

Mercurial makes many of these things difficult. For example:

* `hg log` shows changesets from multiple heads without any indication they
are from multiple heads. Contrast with `hg log -G` or `hg log -f`.
* Existing feature development methods except for MQ (branches and
bookmarks) lack a command that concisely lists *all* of "my" commits (`hg
branches` and `hg bookmarks` only list the tip-most changeset and don't
show the changeset author or description by default).
* `hg rebase` must be explicitly enabled. Some users think this means they
shouldn't be using it.
* `hg push` pushes all heads by default. Great if you are backing up your
work to a non-publishing repo. Bad if you are trying to land something to
the canonical repo.
* `hg update` and `hg pull -u`'s heuristic based model can result in
surprises
* No easy way to figure out how the current working directory revision
relates to the overall repo/DAG

Many of us have installed extensions, aliases, etc on our own machines or
have rolled these out to our users to pave over these deficiencies. That
works... where you have control to do that. It doesn't generally work in
open source: people are at the whim of what Mercurial supports out of the
box.

Many of us also understand the concepts of distributed version control -
what the DAG is, how to interact with it, etc. It is really easy to lose
sight of the fact that most users simply want to get stuff done and they
don't care about the complexities. They will learn the minimum number of
commands required to accomplish what they set out to do. A version control
tool is a barrier to them getting actual work done. They will choose the
mechanism that is simplest and fastest.

Despite all of Mercurial's current deficiencies in this area, it's worth
noting that I think it's still better off than Git. If the leap from single
to multiple heads is hard, try introducing remote refs, tracking branches,
detached HEAD, the reflog, the staging area, etc. And on top of that add a
convoluted CLI that makes grasping the concepts difficult. Many of the
hardcore MQ users at Mozilla detest Git because it is too complex. Only
with a baptism of fire and likely a lot of hand holding do they warm up to
Git. And - get this - once they learn the power of the DAG, of rebasing and
interactive history editing, they fall in love. They think Mercurial's MQ
model is primitive. Then I show them how to do "Git like" multiple head
development in Mercurial and they're like "oh, this is basically the same
except there aren't the complexities of understanding refs, the staging
area, etc - this is quite nice."

So, topics.

I desperately want topics to be a compelling replacement for die hard MQ
users. That means 

Re: news from the topic experiment

[Long Vu]

On Wed, Sep 28, 2016 at 8:20 AM, Pierre-Yves David
 wrote:
>
>
> On 09/27/2016 05:44 PM, Long Vu wrote:
>>
>> Have not observed anything weird with missing obsolescence marker
>> propagation, what symptom should we be paying attention to?
>
> If you pull from both master and fork you should not have any issue. Pulling
> from master only would let you pull the published version without obsoleting
> the latest draft.
>

Ah I see, but I suppose that would be a rare case.

Why would someone been pulling from the fork repo then stop and only
pull from the master only?

Once the feature/bugs is released, we continue to use the same fork
repo on the server for subsequent features/bugs so we will keep
pulling/pushing from/to that fork again and again.

However, my 2 cents, having the obsolescence marker on the master is
sort of a waste because the master repo has none of those obsolete
revisions so what's a point to have a file listing revisions that do
not exist in that master repo?  If it's just for obsolescence marker
transfer, well they are already being transfer naturally because we
keep using the fork repo after that.

>>
>> Cool.
>
>
> Did this convinced your to have a look at topic ?
>

Yes it does :)


-- 
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.

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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/27/2016 05:44 PM, Long Vu wrote:

On Tue, Sep 27, 2016 at 8:19 AM, Pierre-Yves David
 wrote:


On 09/24/2016 03:21 AM, Long Vu wrote:


I forgot a step.  The final "release" is a push to master, followed by a
push to the fork to propagate the public phase to the fork.  Is phase
propagation what you meant?


I mean obsolescence marker propagation. Do you have enabled on either of
your central repository ?



I only enable evolve on the fork, not on the master.  I am using
Kallithea as the repo manager, not hgweb.

Both of us pull/push very frequently to the fork.


So you get changeset/phases from the master and obsmarker from the fork. 
And this is not a problem since you always pull from both. You should 
try enabling evolve on the master too. That would get you the obsmarker 
when you pull from master too (behavior would be a bit more correct)



Have not observed anything weird with missing obsolescence marker
propagation, what symptom should we be paying attention to?


If you pull from both master and fork you should not have any issue. 
Pulling from master only would let you pull the published version 
without obsoleting the latest draft.



I would love to try Evolve on Bitbucket ... is Sean listening :D


I've added him in CC


Pardon my ignorance because I have not yet tried topic, but since evolve
+ named branch already gave me what topic would provide, what makes
topic superior?

Why would I want to try it other than because I am curious?

Not saying it's not useful.  Just want to know what it brings to the
table.



As topic is designed for feature branch you would get various small
advantage that will smooth your experience out:

- Simpler push: pushing new topic to your non-publishing repo do not
requires --force (if the non-publishing repository have topic enabled).


Ah right, with named branch, I have to push with --new-branch each time.


Pushing to your main repository also make the topic disappear without the
need of an initial rebase.


True I have to rebase before releasing.



- Simpler and less error prone rebase: Running `hg rebase` from your topic
will automatically update it on the head of the 'default' branch. Without
removing the topic information.


Also true, to keep the branch name I have to rebase with --keepbranch



- Better command to work with your stack

  + `hg topic` list you active feature branch. `hg topic --verbose` list
various statistic`

  + `hg stack` show your current stack an help you to move within it,

  + `hg evolve --all` will always evolve all of your topic only.

  + `hg next` and `hg prev` stick to your current topic.



Cool.


Did this convinced your to have a look at topic ?

Cheers,

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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/23/2016 06:08 PM, Long Vu wrote:

On Fri, Sep 23, 2016 at 11:50 AM, Long Vu  wrote:


I emulate git lightweight branching by basically using named branch
with evolve and working on the fork of the "master" repo.



We only enable evolve and non-publishing on the fork repo to make sure
we can not alter history on the master repo where the releases are
coming from.


You could enable evolution on the main (publishing) repository. It will 
allow people pushing changeset on the non-publishing one to get proper 
obs-markers when they directly pull from the publishing one.



We have one bug/feature per branch on the fork repo so it's very easy
to manage when we have many concurrent bugs/projects to juggle.


From your explanation in the previous email. It sounds like you are 
using named-branch in a way close to what topic would provide you. Maybe 
you should try topic for a bit and tell use how it feels.



Since we push often to this fork repo, it's like having backup of the
work on our machine and taking last minute day off is easy because the
other person have all the latest code to continue the work without
having to hunt where we store that ongoing work on our machine.


I'm happy to see people using evolution for some of its intended usage ☺

Cheers,

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

Re: news from the topic experiment

[Long Vu]

On Wed, Sep 14, 2016 at 3:14 PM, Pierre-Yves David
 wrote:
>
>   https://www.mercurial-scm.org/repo/topic-experiment/
>

Sorry for jumping late to the discussion.

I am a very happy Evolve user and so far I manage to basically
replicate the lightweight branching of git with just evolve.  Just
sharing my experience in case it sparks other ideas.

I emulate git lightweight branching by basically using named branch
with evolve and working on the fork of the "master" repo.

Disclaimer: we are only 2 using this workflow so far to collaborate so
we probably not hitting any rough edge yet.

user1: hg branch, modify code, hg commit, hg commit ... push to the fork repo

user2: pull update to that branch, more commits, push to the fork repo

user1: pull, evolve --all, more commits, push to the fork repo

rince and repeat for both users until the bug/feature is complete

when ready to "release": hg rebase -d default -s roots(branchname),
push to master repo

This way:

* only the fork repo is polluted with all the temporary branches and
intermediate revisions

* hg log -r 'branch(name)' gives me all the commits of that branch, a
feature that is harder to replicate with bookmarks

* in that "temporary branch that only exist on the fork repo" we can
do all kind of surgery (fold, split, rebase, evolve, prune, ...) and
all history is kept until the project is over and is all tracked with
the branch name: hg log -r 'branch(name)' --hidden

I feel like this even gives me more than just git lightweight
branching as I have full old history all neatly organized in the
"temporary branch" and I can "push changes to the other user's
checkout via evolve" the features that native git lightweight
branching do not even provide.

So very happy camper so far.


-- 
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.

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

Re: news from the topic experiment

[Jun Wu]

Excerpts from Pierre-Yves David's message of 2016-09-23 02:43:37 +0200:
> In the same way large organisation will probably want to define and 
> enforce naming scheme for topics. But they already need to do so today 
> for named-branch of git-branch. So nothing specific to topic here.

For git, IIUC, Bob can create a "tidy" branch that tracks
"alice/smartfixup". He can also rename "master" to "@", tracking
"origin/master". So people can name local branches whatever they like. No
need to have a naming scheme to avoid name collisions.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Kevin Bullock]

> On Sep 22, 2016, at 20:14, Jun Wu  wrote:
> 
> Excerpts from Sean Farley's message of 2016-09-22 17:30:34 -0700:
>> Completely false. Take a look at the hgtopics repo:
>> 
>> $ hg log --debug -vr 093a | grep "\(topic=\|phase\)"
>> phase:   public
>> extra:   topic=stackheader
> 
> I admit I didn't look into the details carefully. Sorry for that.
> 
> I think the major difference is the "local" vs "global" part. I do think
> having the ability to give changesets private labels locally can be useful -
> that's probably another extension other than "topic".

It's not even an extension -- if a local label is what you want, we've had 
localtags since before bookmarks existed.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

Re: news from the topic experiment

[Sean Farley]

Pierre-Yves David  writes:

> On 09/23/2016 02:30 AM, Jun Wu wrote:
>> Excerpts from Pierre-Yves David's message of 2016-09-23 02:01:11 +0200:
>>>
>>> On 09/22/2016 10:09 PM, Jun Wu wrote:
 Could we consider storing the topic of a changeset elsewhere so it's not
 part of the changeset metadata? This will make it more lightweight and
 help preserve hashes with remote peers.
>>>
>>> One could definitely consider it. I've never been thrilled with having
>>> the topic as part of the hash. I agree if makes it more heavy weight
>>> that I would like to create and rename them. Not having them part of the
>>> hash with part of my initial criteria for a lightweight solution.
>>>
>>> However, when Matt, Augie and I were discussing topic somewhere in
>>> Minneapolis last year, Augie made a good case for storing them in the
>>> changesets at least until someone come with something better. Having
>>> them part of extra is solving many of hard problems right away:
>>>
>>> * We already how to discover and exchange them (just reuse changeset and
>>> named branch discovery)
>>>
>>> * We already can track history of changes (just reuse evolution related
>>> data)
>>>
>>> * We can handle rename, cyclic rename and and divergent rename (just
>>> reuse evolution related feature set).
>>
>> I think the following is the major disagreement. (this also applies to other
>> emails)
>>
>> Is the exchange thing the desired behavior? Or, should topic be global or
>> local? I'd prefer the later, because 1. this is *D*VCS and people should
>> have freedom to name things whatever they want. 2. topic names do not affect
>> the actual content.
>
> The exchanged is not only a desired behavior, it is a -required- 
> behavior. The main motivation being solving the feature branch struggle 
> and topic as a solution is to offer a way for people to identify feature 
> branches they exchange. This is central and extremely important. 
> Solution that does not fill this needs fully are not solution :-)
>
>> Consider the following example:
>>
>> 1. Alice makes 3 commits under the "smartfixup" topic.
>> 2. Bob pulls from Alice, got those 3 commits.
>> 3. Bob dislikes the "smartfixup" name, and renamed the topic to "tidy".
>> 4. Bob adds a typo fix commit. Of course, it has the topic name "tidy".
>> 5. Alice pulls the typo fix from Bob. Suddenly all commits get rewritten
>>to use the "tidy" name.
>> 6. Alice dislike the "tidy" name, and thinks wtf you renamed *my* topics...
>> 7. Alice dislike the behavior.
>
> I would clarify this as a "human and workflow issue" This does not only 
> apply to topic. Bob could be pull Alice and rename all the variables. 
> (Or even worse, rewrite the whole project in Ruby!).

Yes, I think this is going to have to be an understood limitation.
Renaming your own branch (with evolve) though seems good enough for me.

> People should not mess around with other people Changesets without prior 
> consent (or explicit workflow) and it is likely that we implement some 
> (friendly) barrier to have people think twice about it. But this is 
> something human being need to sort out between themself.
>
> In the same way large organisation will probably want to define and 
> enforce naming scheme for topics. But they already need to do so today 
> for named-branch of git-branch. So nothing specific to topic here.

I want to point out (because it seems it is implied but not explicit):
while git's ref model is simple, the downside is that it relies on
social definitions.

For instance, there is absolutely nothing preventing a dev from rebasing
'master'. In Mercurial, this restriction is built into the workflow by
building topics upon phases. "Can I rebase 'default'?" <- No. This would
prevent so many support issues.

For the average dev, prepending the username (as most large teams using
git suggest) would solve the same situation here.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Jun Wu]

Excerpts from Sean Farley's message of 2016-09-22 17:30:34 -0700:
> Completely false. Take a look at the hgtopics repo:
> 
> $ hg log --debug -vr 093a | grep "\(topic=\|phase\)"
> phase:   public
> extra:   topic=stackheader

I admit I didn't look into the details carefully. Sorry for that.

I think the major difference is the "local" vs "global" part. I do think
having the ability to give changesets private labels locally can be useful -
that's probably another extension other than "topic".
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Jun Wu]

Excerpts from Jun Wu's message of 2016-09-23 01:30:28 +0100:
> Excerpts from Pierre-Yves David's message of 2016-09-23 02:01:11 +0200:
> > 
> > On 09/22/2016 10:09 PM, Jun Wu wrote:
> > > Could we consider storing the topic of a changeset elsewhere so it's not
> > > part of the changeset metadata? This will make it more lightweight and
> > > help preserve hashes with remote peers.
> > 
> > One could definitely consider it. I've never been thrilled with having 
> > the topic as part of the hash. I agree if makes it more heavy weight 
> > that I would like to create and rename them. Not having them part of the 
> > hash with part of my initial criteria for a lightweight solution.
> > 
> > However, when Matt, Augie and I were discussing topic somewhere in 
> > Minneapolis last year, Augie made a good case for storing them in the 
> > changesets at least until someone come with something better. Having 
> > them part of extra is solving many of hard problems right away:
> > 
> > * We already how to discover and exchange them (just reuse changeset and 
> > named branch discovery)
> > 
> > * We already can track history of changes (just reuse evolution related 
> > data)
> > 
> > * We can handle rename, cyclic rename and and divergent rename (just 
> > reuse evolution related feature set).
> 
> I think the following is the major disagreement. (this also applies to other
> emails)
> 
> Is the exchange thing the desired behavior? Or, should topic be global or
> local? I'd prefer the later, because 1. this is *D*VCS and people should
> have freedom to name things whatever they want. 2. topic names do not affect
> the actual content.

Also, the *D* part is important to deal with name collisions.

Say if both Alice and Bob decide to use "topic1" as the topic name
locally, independently. So Alice's "topic1" and Bob's "topic1" mean totally
different things. If Bob pulls from Alice, he probably doesn't want to get
Alice's "topic1" which will mess up his own stack.

> 
> Consider the following example:
> 
> 1. Alice makes 3 commits under the "smartfixup" topic.
> 2. Bob pulls from Alice, got those 3 commits.
> 3. Bob dislikes the "smartfixup" name, and renamed the topic to "tidy".
> 4. Bob adds a typo fix commit. Of course, it has the topic name "tidy".
> 5. Alice pulls the typo fix from Bob. Suddenly all commits get rewritten
>to use the "tidy" name.
> 6. Alice dislike the "tidy" name, and thinks wtf you renamed *my* topics...
> 7. Alice dislike the behavior.
> 
> If we don't exchange topic names, Bob can change them freely locally, and
> have no issues exchange the actual commits with Alice. Bob can even write
> a hook to automatically rename the topic of incoming commits from
> "smartfixup" to "tidy".
> 
> > The last one is especially important because this is one of the main 
> > issue with bookmark. The life cycle is messy, conflict are annoying to 
> > express/resolve and propagation of all that is a hell.
> > 
> > So, yes ideally I would be happy with an ever lighter-weight solution. 
> > However given the vast amount of critical advantage we gain from this 
> > -in-extra- solutions it is unlikely we can divert our scarce resources 
> > to build a whole better solution.
> > 
> > But sure if someone show up with a solid alternative and his willing to 
> > implement it. It would certainly get the attention it deserve.
> > 
> > Cheers,
> > 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Sean Farley]

Jun Wu  writes:

> Excerpts from Sean Farley's message of 2016-09-22 14:21:12 -0700:
>> > Having topic in commit metadata makes it hard to rename them, and they are
>> > not fundamentally different from branches imo - i.e. we can probably also
>> > make branches work like the current topics implementation with a some 
>> > tweaks
>> > - does not seem to need a fresh new concept.
>> 
>> I'm not convinced by how hard it is to rename them. That's what
>> evolution is for.
>
> Today I can "vim .hg/bookmarks" and do a massive change to bookmarks. If
> topics is designed to be lightweight and local, it'd better support
> something similar for power users.

This is an extremely advanced method for something I have never seen
used on a dev team. I find it very dubious that "it'd better support
something similar." *Very* dubious.

> I dislike hash change without actual content change as always. I think most
> people will prefer / expect no hash change with no actual content change.

I actually haven't seen that when introducing this idea.

>> > Conceptually, I think (I may be wrong) this is a lightweight way to specify
>> > a set of changesets, like the common "tag" concept to changesets. And it
>> > should be easy to add / remove a "tag" to / from a changeset easily.
>> 
>> It's (to me) more than that. The data model as currently defined is
>> attractive for a few reasons:
>> 
>> * a commit can only be on one topic (for better or worse)
>
> True but we can also enforce this if topics live outside changelog.

https://xkcd.com/974/

>> * you can follow the evolution of a topic very easily
>> * it's very familiar with the average user of Mercurial (because of
>>   named branches)
>
> I think our understanding differs on the "it should 'dissolve' upon being
> finished" part (from README). To me, it feels the topic names exist locally
> and they shouldn't be exposed to other peers in changelog. So they are
> guaranteed "dissolved", clean and simple.

I completely disagree. A benefit of having them in the metadata is that
we can offer something git cannot: archaeology. I have heard this
request / complaint about git many times while I've never seen the
*need* for editing refs.

Git's ref model is simple. Just as you state. But the downside is that
you cannot track what happens between ref movement. There are
heuristics, sure, but they are just that: heuristics. Evolve + topics
solves that quite elegantly and simply.

> We can have ".hg/bookmarks" or
> ".hg/remotenames" style state to track them if we do want to exchange
> the information between peers - it will be like remotenames, but one name
> points to a set of changesets, instead of just the head.

Writing remotenames taught me a lot. Mainly, it taught me what not to do
for Mercurial. There are pieces of tracking names, sure, that belong in
core (and I will hopefully do that soon) but it is too easy to wind up
with a ref model. Things just don't make sense after enabling
remotenames: what exactly are these anonymous heads? Where do named
branches fit in? Why can't I delete these commits when I delete the
bookmark?

At the end of the day, I was fighting the DVCS I was working with. There
is a way to get a ref-like workflow: use git. Seriously. I'm not trying
to be rude or condescending but by re-implementing bookmarks / remote
bookmarks you end up with a python version of git.

Mercurial's basic philosophy is that everything[1] is part of the DAG. I
think instead of fighting that, we should embrace a branching design
that is built on top of it.

> IIUC, the current implementation rewrites changesets to strip the metadata
> when the phase of changesets changes from "non-public" to "public". It
> sounds unnecessary complex to me and brings new problems unnecessarily -
> what if I "hg phase --public -f a-changeset-with-topic" ?

Completely false. Take a look at the hgtopics repo:

$ hg log --debug -vr 093a | grep "\(topic=\|phase\)"
phase:   public
extra:   topic=stackheader

>> * it works with bundle1
>
> This is some implementation detail that should not affect the design.
> Eventually everyone can upgrade.

Again: https://xkcd.com/974/

One of the biggest benefits of having a simpler model is that it enables
easier tooling around the DVCS. This point should really, really be
emphasized more than one sentence.

>> >> One of the nice features of the topic name being in the hash is that a
>> >> server (Bitbucket in this case) can enforce settings with bundle1 since
>> >> we can't really control the client of our users (unlike Facebook and
>> >> Google).
>> >
>> > I don't really understand the feature. Is it some kind of ACL or so?
>> 
>> * it allows branch permissions / restrictions
>
> Since it will eventually "dissolve", what's the usecase for permissions on
> topics? For example, if I'm allowed to use topic A but not topic B, I just
> push everything using topic A. The metadata "dissolves" anyway so I don't
> see the difference on the final 

Re: news from the topic experiment

[Jun Wu]

Excerpts from Pierre-Yves David's message of 2016-09-23 02:01:11 +0200:
> 
> On 09/22/2016 10:09 PM, Jun Wu wrote:
> > Could we consider storing the topic of a changeset elsewhere so it's not
> > part of the changeset metadata? This will make it more lightweight and
> > help preserve hashes with remote peers.
> 
> One could definitely consider it. I've never been thrilled with having 
> the topic as part of the hash. I agree if makes it more heavy weight 
> that I would like to create and rename them. Not having them part of the 
> hash with part of my initial criteria for a lightweight solution.
> 
> However, when Matt, Augie and I were discussing topic somewhere in 
> Minneapolis last year, Augie made a good case for storing them in the 
> changesets at least until someone come with something better. Having 
> them part of extra is solving many of hard problems right away:
> 
> * We already how to discover and exchange them (just reuse changeset and 
> named branch discovery)
> 
> * We already can track history of changes (just reuse evolution related 
> data)
> 
> * We can handle rename, cyclic rename and and divergent rename (just 
> reuse evolution related feature set).

I think the following is the major disagreement. (this also applies to other
emails)

Is the exchange thing the desired behavior? Or, should topic be global or
local? I'd prefer the later, because 1. this is *D*VCS and people should
have freedom to name things whatever they want. 2. topic names do not affect
the actual content.

Consider the following example:

1. Alice makes 3 commits under the "smartfixup" topic.
2. Bob pulls from Alice, got those 3 commits.
3. Bob dislikes the "smartfixup" name, and renamed the topic to "tidy".
4. Bob adds a typo fix commit. Of course, it has the topic name "tidy".
5. Alice pulls the typo fix from Bob. Suddenly all commits get rewritten
   to use the "tidy" name.
6. Alice dislike the "tidy" name, and thinks wtf you renamed *my* topics...
7. Alice dislike the behavior.

If we don't exchange topic names, Bob can change them freely locally, and
have no issues exchange the actual commits with Alice. Bob can even write
a hook to automatically rename the topic of incoming commits from
"smartfixup" to "tidy".

> The last one is especially important because this is one of the main 
> issue with bookmark. The life cycle is messy, conflict are annoying to 
> express/resolve and propagation of all that is a hell.
> 
> So, yes ideally I would be happy with an ever lighter-weight solution. 
> However given the vast amount of critical advantage we gain from this 
> -in-extra- solutions it is unlikely we can divert our scarce resources 
> to build a whole better solution.
> 
> But sure if someone show up with a solid alternative and his willing to 
> implement it. It would certainly get the attention it deserve.
> 
> Cheers,
> 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Augie Fackler]

> On Sep 22, 2016, at 8:18 PM, Pierre-Yves David 
>  wrote:
> 
>>> I assume this is along the spirit of your 'hg undo' for evolve (that
>>> preserves the hash)?
>> 
>> No. We are thinking about using topic to replace bookmark as the recommended
>> workflow at fb. People can get confused if local bookmarks point to public
>> changesets.
> 
> I would be happy to discuss that ;-)

As would I. I’ve fielded several user complaints lately that boil down to 
wanting an ephemeral, user-selected name for each draft commit (a la what we 
had with mq patch names). I suspect topics might be able to fill that niche as 
well.


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: news from the topic experiment

[Pierre-Yves David]

On 09/22/2016 11:58 PM, Jun Wu wrote:

Excerpts from Sean Farley's message of 2016-09-22 14:21:12 -0700:

Having topic in commit metadata makes it hard to rename them, and they are
not fundamentally different from branches imo - i.e. we can probably also
make branches work like the current topics implementation with a some tweaks
- does not seem to need a fresh new concept.


I'm not convinced by how hard it is to rename them. That's what
evolution is for.


Today I can "vim .hg/bookmarks" and do a massive change to bookmarks. If
topics is designed to be lightweight and local, it'd better support
something similar for power users.


It would be easy to have a 'topicedit' command that pops up an editor. 
As no content changes happens, it is easy to rewrite all the changeset 
in memory in a very smooth manners.



I dislike hash change without actual content change as always. I think most
people will prefer / expect no hash change with no actual content change.


I much as I would like to avoid it, the current benefit of having it 
(see earlier email) in extra largely out weight the inconvenience. I've 
also found that renaming topic is not something that I end up doing so 
often.



[…]

* you can follow the evolution of a topic very easily
* it's very familiar with the average user of Mercurial (because of
  named branches)


I think our understanding differs on the "it should 'dissolve' upon being
finished" part (from README). To me, it feels the topic names exist locally
and they shouldn't be exposed to other peers in changelog. So they are
guaranteed "dissolved", clean and simple. We can have ".hg/bookmarks" or
".hg/remotenames" style state to track them if we do want to exchange
the information between peers - it will be like remotenames, but one name
points to a set of changesets, instead of just the head.


We definitely want to be able to exchange them. Evolution allow feature 
branch exchange and topic is giving use the ability to express these 
feature branches. So smooth experience when exchanging is a very 
important part of the design/concept/



IIUC, the current implementation rewrites changesets to strip the metadata
when the phase of changesets changes from "non-public" to "public". It
sounds unnecessary complex to me and brings new problems unnecessarily -
what if I "hg phase --public -f a-changeset-with-topic" ?


Urg, no. We do -not- "rewrite changeset when the phase of the changeset 
change". We simply stop reading the metadata on public changeset. Phase 
movement stay a simple operation that does not affect the hash.


In the Facebook case, if you want to have an history without (unread) 
topic metadata, you could easily have the pushrebase extension removing 
it when performing its duty.



* it works with bundle1


This is some implementation detail that should not affect the design.
Eventually everyone can upgrade.


One of the nice features of the topic name being in the hash is that a
server (Bitbucket in this case) can enforce settings with bundle1 since
we can't really control the client of our users (unlike Facebook and
Google).


I don't really understand the feature. Is it some kind of ACL or so?


* it allows branch permissions / restrictions


Since it will eventually "dissolve", what's the usecase for permissions on
topics? For example, if I'm allowed to use topic A but not topic B, I just
push everything using topic A. The metadata "dissolves" anyway so I don't
see the difference on the final outcome.


* only one head per branch


Sounds like remote bookmark is a better fit here.


I'm not sure what you mean here.

(also note that topic+branch allow to tend toward 1 head per 
branch:topic (and could be enforced for bitbucket) while still allowing 
for multiple heads (from pull or intentionally) temporarily which is a 
very useful intermediate state.


Cheers.

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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/22/2016 11:12 PM, Jun Wu wrote:

Excerpts from Sean Farley's message of 2016-09-22 13:54:22 -0700:

Jun Wu  writes:


Could we consider storing the topic of a changeset elsewhere so it's not
part of the changeset metadata? This will make it more lightweight and
help preserve hashes with remote peers.


I assume this is along the spirit of your 'hg undo' for evolve (that
preserves the hash)?


No. We are thinking about using topic to replace bookmark as the recommended
workflow at fb. People can get confused if local bookmarks point to public
changesets.


I would be happy to discuss that ;-)


Having topic in commit metadata makes it hard to rename them, and they are
not fundamentally different from branches imo - i.e. we can probably also
make branches work like the current topics implementation with a some tweaks
- does not seem to need a fresh new concept.


No, we want both named branch and topics. They are and important 
difference in life-cycle and therefor semantic. One of the main issue 
with bookmark is their life-cycle. Having life cycle expectation 
(mutable life only) built in the topic design is important here. And 
then we still need named-branches for more long-lived target.



Conceptually, I think (I may be wrong) this is a lightweight way to specify
a set of changesets, like the common "tag" concept to changesets. And it
should be easy to add / remove a "tag" to / from a changeset easily.


(I know I'm repeating myself from the previous email, but better safe 
than sorry).


Defining the set locally is not too hard. But all the exchange part is 
much harder. You have to handle the distributed aspect of DVCS with all 
the possible renames (possibly divergent renames) and other related 
cases. And that is the very hard problem that we can just make vanish by 
reusing all our solution regarding changesets.


Cheers,

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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/22/2016 10:09 PM, Jun Wu wrote:

Could we consider storing the topic of a changeset elsewhere so it's not
part of the changeset metadata? This will make it more lightweight and
help preserve hashes with remote peers.


One could definitely consider it. I've never been thrilled with having 
the topic as part of the hash. I agree if makes it more heavy weight 
that I would like to create and rename them. Not having them part of the 
hash with part of my initial criteria for a lightweight solution.


However, when Matt, Augie and I were discussing topic somewhere in 
Minneapolis last year, Augie made a good case for storing them in the 
changesets at least until someone come with something better. Having 
them part of extra is solving many of hard problems right away:


* We already how to discover and exchange them (just reuse changeset and 
named branch discovery)


* We already can track history of changes (just reuse evolution related 
data)


* We can handle rename, cyclic rename and and divergent rename (just 
reuse evolution related feature set).


The last one is especially important because this is one of the main 
issue with bookmark. The life cycle is messy, conflict are annoying to 
express/resolve and propagation of all that is a hell.


So, yes ideally I would be happy with an ever lighter-weight solution. 
However given the vast amount of critical advantage we gain from this 
-in-extra- solutions it is unlikely we can divert our scarce resources 
to build a whole better solution.


But sure if someone show up with a solid alternative and his willing to 
implement it. It would certainly get the attention it deserve.


Cheers,

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

Re: news from the topic experiment

[Sean Farley]

Jun Wu  writes:

> Excerpts from Sean Farley's message of 2016-09-22 13:54:22 -0700:
>> Jun Wu  writes:
>> 
>> > Could we consider storing the topic of a changeset elsewhere so it's not
>> > part of the changeset metadata? This will make it more lightweight and
>> > help preserve hashes with remote peers.
>> 
>> I assume this is along the spirit of your 'hg undo' for evolve (that
>> preserves the hash)?
>
> No. We are thinking about using topic to replace bookmark as the recommended
> workflow at fb. People can get confused if local bookmarks point to public
> changesets.

Ah, cool.

> Having topic in commit metadata makes it hard to rename them, and they are
> not fundamentally different from branches imo - i.e. we can probably also
> make branches work like the current topics implementation with a some tweaks
> - does not seem to need a fresh new concept.

I'm not convinced by how hard it is to rename them. That's what
evolution is for.

> Conceptually, I think (I may be wrong) this is a lightweight way to specify
> a set of changesets, like the common "tag" concept to changesets. And it
> should be easy to add / remove a "tag" to / from a changeset easily.

It's (to me) more than that. The data model as currently defined is
attractive for a few reasons:

* a commit can only be on one topic (for better or worse)
* you can follow the evolution of a topic very easily
* it's very familiar with the average user of Mercurial (because of
  named branches)
* it works with bundle1

>> One of the nice features of the topic name being in the hash is that a
>> server (Bitbucket in this case) can enforce settings with bundle1 since
>> we can't really control the client of our users (unlike Facebook and
>> Google).
>
> I don't really understand the feature. Is it some kind of ACL or so?

* it allows branch permissions / restrictions
* only one head per branch
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Jun Wu]

Excerpts from Sean Farley's message of 2016-09-22 13:54:22 -0700:
> Jun Wu  writes:
> 
> > Could we consider storing the topic of a changeset elsewhere so it's not
> > part of the changeset metadata? This will make it more lightweight and
> > help preserve hashes with remote peers.
> 
> I assume this is along the spirit of your 'hg undo' for evolve (that
> preserves the hash)?

No. We are thinking about using topic to replace bookmark as the recommended
workflow at fb. People can get confused if local bookmarks point to public
changesets.

Having topic in commit metadata makes it hard to rename them, and they are
not fundamentally different from branches imo - i.e. we can probably also
make branches work like the current topics implementation with a some tweaks
- does not seem to need a fresh new concept.

Conceptually, I think (I may be wrong) this is a lightweight way to specify
a set of changesets, like the common "tag" concept to changesets. And it
should be easy to add / remove a "tag" to / from a changeset easily.

> One of the nice features of the topic name being in the hash is that a
> server (Bitbucket in this case) can enforce settings with bundle1 since
> we can't really control the client of our users (unlike Facebook and
> Google).

I don't really understand the feature. Is it some kind of ACL or so?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[Jun Wu]

Could we consider storing the topic of a changeset elsewhere so it's not
part of the changeset metadata? This will make it more lightweight and
help preserve hashes with remote peers.

Excerpts from Pierre-Yves David's message of 2016-09-14 21:14:16 +0200:
> In the past couple of weeks I made a couple of extra changes to the 
> topic experiment,
> 
> 'hg topic --verbose' got a large update and now list various information 
> about the topics, this should help people getting a grasp on the current 
> state of they topic in a single command:
> 
> Example output
> 
> > $ hg topic -v
> >bisect(on branch: default, 11 changesets, 149 
> > behind)
> >diff.order.issue  (on branch: default, 4 changesets, 2 
> > heads, 3 behind)
> >exception-too-wide(on branch: default, 1 changesets, 2027 
> > behind)
> >vfs.cleanup   (on branch: default, 12 changesets, 3 
> > troubled, 2 heads, 253 behind)
> >  * vfs.ward  (on branch: default, 7 changesets, 2 
> > troubled, 2 heads, 189 behind)
> 
> 
> The most notable change is probably the creation of the 'hg stack' 
> command. The 'hg stack' command display comprehensive information about 
> all changesets in your current topic.
> 
> Here is some example output (without the Christmas color)
> 
>  > $ hg stack
> > ### topic: bisect
> > ### branch: default, 149 behind
> > t9: may update
> > t8: move checkstate
> > t7: checkstate #2
> > t6: checkstate #1
> > t5: move plain update code around
> > t4: printresult
> > t3: extract extendrange
> > t2: extract reset
> > t1: use vfs for reset
> >   ^ hgweb: document why we don't allow untrusted settings to control zlib
> 
> Example output for messy state:
> 
> > ### topic: vfs.ward (2 heads)
> > ### branch: default, 189 behind
> > t7$ reposvfs: add a ward to check if locks are properly... (unstable)
> > t6@ mq: release lock after transaction in qrefresh (current)
> > t5: perf: release lock after transaction in perffncachewrite
> > t3^ repovfs: add a ward to check if locks are properly taken (base)
> > t4$ ignore bisect (unstable)
> > t3: repovfs: add a ward to check if locks are properly taken
> > t2: vfs: add the possibility to have a "ward" to check vfs usage
> > t1: pull: grab wlock during pull
> >   ^ journal: take wlock for writting the 'shared' file
> 
> 
> On the performance side, timeless introduced some improved regarding 
> caching that should reduce some of the performance impact. There is 
> still low hanging fruit there, but situation is already much better.
> 
> Sean Farley initiated a flake8 crusade and enforced some more coding 
> style through the code.
> 
> The topic extension also gained some raw documentation about its various 
> features, its not great but is better than nothing. Feel free to send 
> patch to improve it.
> 
> reminder, the extension can be found there:
> 
>https://www.mercurial-scm.org/repo/topic-experiment/ 
> 
> Cheers,
> 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: news from the topic experiment

[David Demelier]

2016-09-20 15:39 GMT+02:00 Pierre-Yves David :
> At this point, reference to non-publishing repository implies evolution
> support. At some point evolution will stop being experimental and turned on
> by default.



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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/17/2016 08:21 AM, David Demelier wrote:

2016-09-16 18:35 GMT+02:00 Pierre-Yves David :

This is a very valid feedback. The start of the topic experiments come from
the finding that after 5 years of struggle trying to make bookmarks viable,
they seems too alien to other Mercurial concept to ever work in a
satisfactory way.


Okay so now I assume bookmarks no longer exist.

First, I've seen a hg stack function, I would suggest naming it
'topics' so it more meaningful and more appropriate since some
commands have plural forms (e.g. tag/tags, branch/branches).


- If you work on multiple feature at the same time (ie: have multiple
anonymous/bookmarked heads, you can use topic locally to organize them,


Okay, so to my point of view, local topics seem to work pretty fine
and looks like a good idea. My major disappointment with bookmarks is
the combination of "default" and "@", with topics, you will just need
to hg up default or the-topic. no more @, default and
featured-bookmarks :-)


- If you do advanced code review and use non-publishing review to exchange
draft with other people. You can use topics to organize these.



This is exactly what I dislike.

You need to use a non-publishing server to share topics. This means I
can rewrite history, delete revisions on the remote when using topics.
Thus, breaking any basic users who just do some hg pull and build.
Those users will not understand why their local repositories are
cluttered with many revisions that does not exist anymore. Probably we
should mix evolve features + topics so that we can use on
non-publishing server?

Personally, I will probably use topics only locally if it will still
requires only draft changesets and do code review with a pre-push
manner using some additional workflow (reviewboard, mailing lists,
etc...)


At this point, reference to non-publishing repository implies evolution 
support. At some point evolution will stop being experimental and turned 
on by default.


Cheers,

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

Re: news from the topic experiment

[David Demelier]

2016-09-14 21:14 GMT+02:00 Pierre-Yves David :
> In the past couple of weeks I made a couple of extra changes to the topic
> experiment,
>
> 'hg topic --verbose' got a large update and now list various information
> about the topics, this should help people getting a grasp on the current
> state of they topic in a single command:
>
> The most notable change is probably the creation of the 'hg stack' command.
> The 'hg stack' command display comprehensive information about all
> changesets in your current topic.
>
>
> The topic extension also gained some raw documentation about its various
> features, its not great but is better than nothing. Feel free to send patch
> to improve it.
>
> reminder, the extension can be found there:
>
>   https://www.mercurial-scm.org/repo/topic-experiment/

Hello,

Disclaimer: this will be totally subjective.

Branches, bookmarks, topics. Too much ways to do something in Mercurial.

When I started using Mercurial, there was only branches and it was
fine. Then we introduced bookmarks to simulate git branches and it
works mostly fine too. But it has increased the learning curve and
added new workflows. For the end user, it's not very easy to start and
learn all these things and when I should use that, or this or
whatever.

Now topics, yet another new way of working. A new question may arise:
when to use topics, when to use bookmarks, when to use branches?

I think we really should improve what is existing (understand
bookmarks) instead of creating new Mercurial commands. Mercurial
always had the reputation of being easy to learn. The upcoming evolve
will already add new commands and it seems that topics will also
introduce new commands. I'm not sure if the reputation of being easy
will stay :-).

I if recall correctly, someone on the #mercurial channel told me that
topics requires a non-publishing repository. If it's true, for me it's
a reason to not use topics.

What I'm really in hurry to see, is the journal extension to have a
better bookmark workflow :-)

Regards,

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

Re: news from the topic experiment

[Pierre-Yves David]

On 09/15/2016 07:27 PM, Durham Goode wrote:

On 9/14/16 12:14 PM, Pierre-Yves David wrote:

Example output for messy state:


### topic: vfs.ward (2 heads)
### branch: default, 189 behind
t7$ reposvfs: add a ward to check if locks are properly... (unstable)
t6@ mq: release lock after transaction in qrefresh (current)
t5: perf: release lock after transaction in perffncachewrite
t3^ repovfs: add a ward to check if locks are properly taken (base)
t4$ ignore bisect (unstable)
t3: repovfs: add a ward to check if locks are properly taken
t2: vfs: add the possibility to have a "ward" to check vfs usage
t1: pull: grab wlock during pull
  ^ journal: take wlock for writting the 'shared' file

>

Why not use the graph ascii art to make the ancestry clearer? You can
still put the 'tX' shortcut in front of each commit.


Partly because 'it simply has not been done yet', This is not just a 
graphlog call, as we have to build the graph edge by hand (but 
definitely doable).


In practice, it is also not that critical, with color enabled, the 
(base) lines stand out a lot.

http://imgur.com/vWl4Qcn

In addition, stack focus on a single topic that is expected to be 
linear, so any branching is supposed to be a temporary problematic case. 
So the output is not optimisted too much for that case as bugging the 
user until it is solved is an actual goal here. In addition the base can 
also be outside the topic (in which case, the line do not have a t#) and 
the graphlog will not be very informative.



I had to sit and stare at this output for a while to figure out what was
going on (in particular, that t3 was present twice).


The glyph next to the changeset short id are a bit cryptic at first. I'm 
open to idea of how to improve that and in the mean time I expect user 
to adjust in a descent amount of time.


Cheers,

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

news from the topic experiment

[Pierre-Yves David]

In the past couple of weeks I made a couple of extra changes to the 
topic experiment,


'hg topic --verbose' got a large update and now list various information 
about the topics, this should help people getting a grasp on the current 
state of they topic in a single command:


Example output


$ hg topic -v
   bisect(on branch: default, 11 changesets, 149 behind)
   diff.order.issue  (on branch: default, 4 changesets, 2 heads, 3 
behind)
   exception-too-wide(on branch: default, 1 changesets, 2027 behind)
   vfs.cleanup   (on branch: default, 12 changesets, 3 
troubled, 2 heads, 253 behind)
 * vfs.ward  (on branch: default, 7 changesets, 2 troubled, 
2 heads, 189 behind)



The most notable change is probably the creation of the 'hg stack' 
command. The 'hg stack' command display comprehensive information about 
all changesets in your current topic.


Here is some example output (without the Christmas color)

> $ hg stack

### topic: bisect
### branch: default, 149 behind
t9: may update
t8: move checkstate
t7: checkstate #2
t6: checkstate #1
t5: move plain update code around
t4: printresult
t3: extract extendrange
t2: extract reset
t1: use vfs for reset
  ^ hgweb: document why we don't allow untrusted settings to control zlib


Example output for messy state:


### topic: vfs.ward (2 heads)
### branch: default, 189 behind
t7$ reposvfs: add a ward to check if locks are properly... (unstable)
t6@ mq: release lock after transaction in qrefresh (current)
t5: perf: release lock after transaction in perffncachewrite
t3^ repovfs: add a ward to check if locks are properly taken (base)
t4$ ignore bisect (unstable)
t3: repovfs: add a ward to check if locks are properly taken
t2: vfs: add the possibility to have a "ward" to check vfs usage
t1: pull: grab wlock during pull
  ^ journal: take wlock for writting the 'shared' file



On the performance side, timeless introduced some improved regarding 
caching that should reduce some of the performance impact. There is 
still low hanging fruit there, but situation is already much better.


Sean Farley initiated a flake8 crusade and enforced some more coding 
style through the code.


The topic extension also gained some raw documentation about its various 
features, its not great but is better than nothing. Feel free to send 
patch to improve it.


reminder, the extension can be found there:

  https://www.mercurial-scm.org/repo/topic-experiment/

Cheers,

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