news from the topic experiment

[Sean Farley]

Jun Wu <quark at fb.com> writes:

> Excerpts from Sean Farley's message of 2016-09-22 13:54:22 -0700:
>> Jun Wu <quark at fb.com> 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