Determining what files were touched in a changeset algorithmically

Tony Mechelynck antoine.mechelynck at gmail.com
Wed Jun 22 20:36:37 CDT 2011


On 23/06/11 01:51, paul_nathan at selinc.com wrote:
> Greetings,
>
> I am working on some analysis tools for hg logs.
>
> hg log --template "{files}" is the naive way to do this.
>
> Demonstration of problem:
>
> $ hg log -r 34 --template "{file_mods}\n"
> baz baz baz foo bar spacey.txt
>
> What files were modified?
>
> In order to determine this, I have to run manifest on 34 and perform
> some lexical analysis for all files in that changeset to determine which
> files actually got modified.
>
> Reviewing the hg source code, the rendering code (showlist function in
> http://selenic.com/hg/file/8deebb577751/mercurial/templatekw.py)
> performs a join with spaces here. This is... problematic for fast
> algorithmic determination.
>
> I have thousands of changesets that need to be processed repeatedly and
> shelling out on each changeset is going to be slow.
>
> Is there a better way? I'd like to only shell out to hg once and get all
> the needed information.
>
> (the file names were "baz baz baz" and "foo bar spacey.txt")
>
> - - -
> Regards,
> Paul Nathan

Maybe use

	hg log --style xml

and then reprocess the XML output to get what you want? This would allow 
you to get in a single hg run all the data for your changesets, neatly 
organized as follows (the --config argument is there to override a 
setting in my hgrc; and I'm using -l 5 in this example to get only the 
five latest changesets but of course you might want to select a 
different set of revisions):

  # hg --config pager.pager= log -l 5 --style xml
<?xml version="1.0"?>
<log>
<logentry revision="2997" node="687eb4a3f9bf960528c2ad824fea211b32a4177f">
<tag>tip</tag>
<parent revision="2988" node="1e0b536610ab563be0d61a18430b7bde80b315ce" />
<parent revision="2996" node="f43c2f39001fc247a44cca5495ec724a48b0df02" />
<author email="antoine.mechelynck at gmail.com">Tony Mechelynck</author>
<date>2011-06-20T09:37:58+02:00</date>
<msg xml:space="preserve">Automated merge with 
https://vim.googlecode.com/hg/</msg>
<paths>
<path action="M">.hgtags</path>
<path action="M">src/ex_cmds.h</path>
<path action="M">src/gui.c</path>
<path action="M">src/normal.c</path>
<path action="M">src/os_macosx.m</path>
<path action="M">src/version.c</path>
</paths>
</logentry>
<logentry revision="2996" node="f43c2f39001fc247a44cca5495ec724a48b0df02">
<author email="bram at vim.org">Bram Moolenaar</author>
<date>2011-06-20T05:02:58+02:00</date>
<msg xml:space="preserve">Added tag v7-3-230 for changeset 
70c8f54e7efb</msg>
<paths>
<path action="M">.hgtags</path>
</paths>
</logentry>
<logentry revision="2995" node="70c8f54e7efbd7b59bbe6764d0fbfa1f1602273f">
<tag>v7-3-230</tag>
<author email="bram at vim.org">Bram Moolenaar</author>
<date>2011-06-20T05:02:58+02:00</date>
<msg xml:space="preserve">updated for version 7.3.230
Problem:    &quot;:wundo&quot; and &quot;:rundo&quot; don&#39;t unescape 
their argument.  (Aaron
             Thoma)
Solution:   Use FILE1 instead of XFILE.</msg>
<paths>
<path action="M">src/ex_cmds.h</path>
<path action="M">src/version.c</path>
</paths>
</logentry>
<logentry revision="2994" node="cfe8cf0d57a72307e5268f4b17cc44036e8a189a">
<author email="bram at vim.org">Bram Moolenaar</author>
<date>2011-06-20T00:53:15+02:00</date>
<msg xml:space="preserve">Added tag v7-3-229 for changeset 
07647a0545c9</msg>
<paths>
<path action="M">.hgtags</path>
</paths>
</logentry>
<logentry revision="2993" node="07647a0545c9f0fad4e1e84062e0572a07d94659">
<tag>v7-3-229</tag>
<author email="bram at vim.org">Bram Moolenaar</author>
<date>2011-06-20T00:53:15+02:00</date>
<msg xml:space="preserve">updated for version 7.3.229
Problem:    Using fork() makes gvim crash on Mac when build with
             CoreFoundation.
Solution:   Disallow fork() when __APPLE__ is defined. (Hisashi T 
Fujinaka)</msg>
<paths>
<path action="M">src/gui.c</path>
<path action="M">src/version.c</path>
</paths>
</logentry>
</log>



Best regards,
Tony.
-- 
Immortality -- a fate worse than death.
		-- Edgar A. Shoaff


More information about the Mercurial mailing list