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.
Excerpts from Pierre-Yves David's message of 2016-09-14 21:14:16 +0200: > In the past couple of weeks I made a couple of extra changes to the > topic experiment, > > 'hg topic --verbose' got a large update and now list various information > about the topics, this should help people getting a grasp on the current > state of they topic in a single command: > > Example output > > > $ hg topic -v > > bisect (on branch: default, 11 changesets, 149 > > behind) > > diff.order.issue (on branch: default, 4 changesets, 2 > > heads, 3 behind) > > exception-too-wide (on branch: default, 1 changesets, 2027 > > behind) > > vfs.cleanup (on branch: default, 12 changesets, 3 > > troubled, 2 heads, 253 behind) > > * vfs.ward (on branch: default, 7 changesets, 2 > > troubled, 2 heads, 189 behind) > > > The most notable change is probably the creation of the 'hg stack' > command. The 'hg stack' command display comprehensive information about > all changesets in your current topic. > > Here is some example output (without the Christmas color) > > > $ hg stack > > ### topic: bisect > > ### branch: default, 149 behind > > t9: may update > > t8: move checkstate > > t7: checkstate #2 > > t6: checkstate #1 > > t5: move plain update code around > > t4: printresult > > t3: extract extendrange > > t2: extract reset > > t1: use vfs for reset > > ^ hgweb: document why we don't allow untrusted settings to control zlib > > Example output for messy state: > > > ### topic: vfs.ward (2 heads) > > ### branch: default, 189 behind > > t7$ reposvfs: add a ward to check if locks are properly... (unstable) > > t6@ mq: release lock after transaction in qrefresh (current) > > t5: perf: release lock after transaction in perffncachewrite > > t3^ repovfs: add a ward to check if locks are properly taken (base) > > t4$ ignore bisect (unstable) > > t3: repovfs: add a ward to check if locks are properly taken > > t2: vfs: add the possibility to have a "ward" to check vfs usage > > t1: pull: grab wlock during pull > > ^ journal: take wlock for writting the 'shared' file > > > On the performance side, timeless introduced some improved regarding > caching that should reduce some of the performance impact. There is > still low hanging fruit there, but situation is already much better. > > Sean Farley initiated a flake8 crusade and enforced some more coding > style through the code. > > The topic extension also gained some raw documentation about its various > features, its not great but is better than nothing. Feel free to send > patch to improve it. > > reminder, the extension can be found there: > > https://www.mercurial-scm.org/repo/topic-experiment/ > > Cheers, > _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel