news from the topic experiment

Jun Wu quark at fb.com
Thu Sep 22 16:09:51 EDT 2016


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,
> 


More information about the Mercurial-devel mailing list