news from the topic experiment
quark at fb.com
Thu Sep 22 17:58:01 EDT 2016
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.
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.
> > 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.
> * 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.
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" ?
> * 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.
More information about the Mercurial-devel