|
From: | Patrick Georgi |
Subject: | Re: [Monotone-devel] hg2mtn 0.0.20070824 |
Date: | Sat, 25 Aug 2007 11:30:51 +0200 |
User-agent: | Thunderbird 2.0b2 (X11/20070411) |
Thomas Keller schrieb:
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)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:
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)# 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.
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?)
That's what I'll do next. Together with some improv.. ermm.. initial work at a user interface. :-)And yeah, a little code cleanup and some explaining comments would be nice ;)
Regards, Patrick Georgi
[Prev in Thread] | Current Thread | [Next in Thread] |