Integration of Mercurial into LXR

[paul_nathan at selinc.com]

[snip]
> >
> >>> Paul suggested to attack the problem the other way, through change 
sets.
> > +++++
> > I don't think I'll follow this lead. Probably too much hazardous 
coding and
> > the risk to be at mercy of a change in Mercurial.
> 
> I don't think Paul's suggestion was necessarily to use the Mercurial
> API - he was just suggesting that you update to each repository
> revision in turn, and store the size of every file in your own data
> structure. This can all be done via the mercurial command-line and in
> whatever language you like. (However, I don't think it's actually
> necessary to update to each revision; with appropriate use of "hg
> manifest -r" and "hg cat -r" you should be able to extract everything
> you need)
> 

[snip]

My recollection is that it turns out to be faster to iterate through all 
changesets and use
direct file access rather than hg cat.  The API is a considerable speedup 
when querying hg 
about the metadata of the repository. Overall, we have found that the 
performance-minded user 
will find it advantageous  to cache the information in a data structure 
targeted towards their 
particular usage patterns. 

Sadly, I don't have data ready to hand regarding these assertions, though. 
I haven't touched this area
of hg integration in over a year, and my colleague handles this kind of 
behavior now for our
internal tooling[1].  This is from recollections of that work and 
conversations with my colleague. 


Regards,
Paul

[1] The internal tooling tracks all file commits over all changesets, 
along with business-related
metadata for these commits. We query on things such as (example, slightly 
simplistic), 
"who touched this file last on this branch",  which turned out to be 
surprisingly fiddly when
considering merges. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121214/26b16684/attachment-0002.html>