news from the topic experiment

Pierre-Yves David pierre-yves.david at
Thu Sep 22 20:18:48 EDT 2016

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


Pierre-Yves David

More information about the Mercurial-devel mailing list