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

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
Mercurial-devel mailing list

Reply via email to