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

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.


Pierre-Yves David
Mercurial-devel mailing list

Reply via email to