Jun Wu <qu...@fb.com> writes: > 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.
This is an extremely advanced method for something I have never seen used on a dev team. I find it very dubious that "it'd better support something similar." *Very* dubious. > 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 actually haven't seen that when introducing this idea. >> > 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. https://xkcd.com/974/ >> * 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. I completely disagree. A benefit of having them in the metadata is that we can offer something git cannot: archaeology. I have heard this request / complaint about git many times while I've never seen the *need* for editing refs. Git's ref model is simple. Just as you state. But the downside is that you cannot track what happens between ref movement. There are heuristics, sure, but they are just that: heuristics. Evolve + topics solves that quite elegantly and simply. > 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. Writing remotenames taught me a lot. Mainly, it taught me what not to do for Mercurial. There are pieces of tracking names, sure, that belong in core (and I will hopefully do that soon) but it is too easy to wind up with a ref model. Things just don't make sense after enabling remotenames: what exactly are these anonymous heads? Where do named branches fit in? Why can't I delete these commits when I delete the bookmark? At the end of the day, I was fighting the DVCS I was working with. There is a way to get a ref-like workflow: use git. Seriously. I'm not trying to be rude or condescending but by re-implementing bookmarks / remote bookmarks you end up with a python version of git. Mercurial's basic philosophy is that everything[1] is part of the DAG. I think instead of fighting that, we should embrace a branching design that is built on top of it. > 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" ? Completely false. Take a look at the hgtopics repo: $ hg log --debug -vr 093a | grep "\(topic=\|phase\)" phase: public extra: topic=stackheader >> * it works with bundle1 > > This is some implementation detail that should not affect the design. > Eventually everyone can upgrade. Again: https://xkcd.com/974/ One of the biggest benefits of having a simpler model is that it enables easier tooling around the DVCS. This point should really, really be emphasized more than one sentence. >> >> 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. See above. Your mental model about this is off. >> * only one head per branch > > Sounds like remote bookmark is a better fit here. I think you came to this conclusion based on a incorrect mental model. I could be wrong but can't tell, so I'll wait for another response. [1] obviously ignoring phases and obsolescence markers _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
