Re: [Monotone-devel] hg2mtn 0.0.20070824

[Patrick Georgi]

Thomas Keller schrieb:
> I'm a Python novice myself, so I can't give you much advice (despite I
> don't like "tmp"-named variables very much in any language ;). However,
> by skimming through your code I found this:
>   
Those are fields I simply don't care about - hence "tmp".. mercurial 
doesn't seem to expose the interesting bits separately (and they exist 
in a single data structure in revlog, so it would likely be more 
expensive, too)

> # FIXME: handle renamed files
> ofctx = parentcontext.filectx(file)
> oldid = sha.new(ofctx.data()).hexdigest()
>
> This looks like you're hashing the old file contents for each patch you
> are going to feed into mtn, right? Wouldn't it be better to use some
> kind of cache here, since if you process the revisions forwardly, you
> should already know all the fileids from previous revisions, don't you?
> Maybe this could speed up the thing a bit more.
>   
That would mean I'd have to keep the manifests around (but with 
monotone's hashes, as mercurial gives me some "other" data), and copy 
the stuff appropriately.
I'd also need to handle the case where the manifests don't exist 
(incremential update)

For my purpose (35000 files per manifest, usually less than 10 patches), 
I think the brute force way I implemented is more efficient, esp. as 
access to file data in mercurial is very fast. I'm not sure at which 
point it would be more efficient to keep that cache (small repositories 
with lots of files changed in every revision?)
> And yeah, a little code cleanup and some explaining comments would be
> nice ;)
>   
That's what I'll do next. Together with some improv.. ermm.. initial 
work at a user interface. :-)


Regards,
Patrick Georgi