[12:02] (it is just state based, and knows that key X follows key Y) [12:02] Doesn't it work by parsing rlog output? Isn't that already ambiguous? [12:02] mhagger: cvsps works by parsing rlog, I don't know the details on that side [12:03] (As I work above cvsps, not below it) [12:03] mhagger: here some basic examples http://bazaar-vcs.org/Integrating_with_Bazaar [12:03] Though I have some hooks to invoke cvsps with the "correct" arguments. [12:03] I found the cvsps command line to be pretty ugly [12:04] and here http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html -- epydoc like docs [12:04] So if your tree isn't too tricky, you can do "bzr cvsps-import CVSROOT MODULE OUTPUT" and not need to know anything about cvsps (other than have it available) [12:04] jam-laptop: Would you be interested in working together on this? I bet we could have something done in a day or two [12:04] mhagger: I would be happy to help when I can [12:05] I work full time on the project [12:05] mhagger: just another question about cvsnt [12:06] cvsnt (as I say) have record about merge points [12:06] AFAIK before 1.5 svn does not record merges [12:06] jam-laptop: Do you work for Canonical? [12:06] mhagger: yes [12:06] is this concept fit to current cvs2svn? [12:07] cvs2svn doesn't try to deduce merge points, because there is no such info in standard CVS === bialix wonder if name of project one day becomes cvs2any... [12:07] What is the form of the mergepoint information? [12:07] I understand it, hence my question [12:08] wait [12:08] something like this: mergepoint1 @1.5.2.1@; [12:09] mhagger: so if you are interested in poking at it a bit, I'm guessing the only thing that would need to change would be to write a Parser to replace the cvsps Parser [12:10] As long as the "_PatchSet" objects can contain the information you want to copy over [12:11] jam-laptop: By "parser" I assume you mean "the huge amount of code needed to read RCS files and deduce the changesets" [12:11] cvsps-import uses rcs to directly extract the texts, so it sort of depends on how cvs2svn extracts stuff [12:11] mhagger: well the Parser takes cvsps Patches and turns them into meta-info plus a list of (file, version) data [12:11] Maybe we should move this to #cvs2svn to avoid disturbing the good folks of #bzr? [12:12] mhagger: but you've already done all the work to do that part of the parsing [12:12] mhagger: na, this is an open channel [12:12] Yes, of course [12:12] the #bzr policy is to discuss anything even remotely related to #bzr [12:12] unless the channel is extra busy [12:13] Yes, we parse, then put everything in a dependency graph, then remove cycles in the graph, then topologically sort, and the changesets fall out. [12:13] btw, cvsnt mark changesets with ids: commitid 44441d436f80000; [12:13] ...with lots of extra code for working with vendor branches, CVS's spurious commits, etc [12:14] bbiab [12:14] bialix: Does the mergepoint indicate that all changes on the 1.5.2 branch through 1.5.2.1 have been merged into that revision? [12:14] ...or only that the single 1.5.2.1 delta has been merged, or what? [12:15] bialix: To support CVSNT... [12:15] because I don't have access to docs -- I can't say for sure [12:15] but I can do some experiments [12:15] with TortoiseCVS [12:15] to see what happens [12:16] (1) The RCS parser would have to be enhanced a bit. Currently it discards the newphrases [12:16] generally my TortoiseCVS workflow was very close to one we use in bzr [12:16] i.e. I'm always merge full branch history, not cherrypicking it [12:16] (2) I think that CVSNT supports some other file modes (i.e., binary vs. text vs. keyword expansion etc) [12:16] Those would have to be supported. [12:17] 2) -- I think so [12:17] (3) The commitid information would have to be used. I don't think this would be very difficult. [12:17] 3) at least it could be used as suggestion? [12:18] (4) Whatever different strange corner cases, corruption etc that exist in CVSNT repos would have to be dealt with. [12:18] Yes, the most trivial thing to do with commitids is to use it as an exclusion criterion: if the commitids are different, then the revisions *cannot* be part of a single commit. [12:18] what do you mean by corruption? [12:18] There are a few forms of CVS repo corruption that we have seen repeatedly. [12:19] ah, ok [12:19] Probably resulting from CVS bugs in some historical version or something [12:19] or maybe poor disaster recovery [12:19] Presumably CVSNT has similar things [12:19] may be [12:20] btw, I don't remember, is cvs2svn supports CVS modules? [12:20] Not the modules file. It is not clear what to do with it. [12:21] but cvs2svn supports CVS repositories with multiple projects [12:21] in bzr we have concept of nested trees, but it still not production ready [12:21] each project can be converted independently of the others; for example, branches and tags in different projects can be considered distinct. [12:21] mhagger: well, that and the fact that most people do manual surgery to rename files, etc [12:22] And if you do it "correctly" you still have a bunch of cvsadmin work to do [12:22] Ouch let's not even talk about that [12:22] :-) [12:23] Often there is too little left in the history to know what happened, so figuring it out is too much to ask of a conversion tool [12:23] Maybe it needs a "mechanical Turk" module :-) [12:23] mhagger: can you have some sort of description of real CVS format for ,v files? [12:24] bialix: man rcsfile is a good start [12:24] yeah, but this man is a bit short and unclear [12:24] Somewhere there is also documentation specific to CVS that describes their file extensions briefly [12:25] I mean: to understand what is standard CVS words, and what is cvsnt specific claims [12:25] lo jam-laptop, welcome back to irc :) [12:25] hi lifeless, good to be around :0 [12:26] jam-laptop: I suggest that to get started you send an email to the cvs2svn dev mailing list with references telling us where to find cvsps-import and what modules to look at. [12:26] (jam was unhappy because there was no one to talk with, so we start to talk with ubotu) :-) [12:26] lifeless: ^ [12:27] bialix: I don't know of better RCS file documentation. Of course one could try to figure it out from the CVS source code. [12:27] well [12:27] rcs source code :) [12:27] I've seen enough of them to understand them pretty well [12:28] Well, RCS files as used by CVS. So you need to know both. [12:28] modules is well documented - new repos get a sensible modules [12:28] CVS uses its own RCS file parsing machinery, so I guess it is definitive. [12:28] its runtime evaluated [12:28] IIRC that is. [12:29] anyhow, I haven't read all the backlog, would someone like to clue me in on the question quickly :) ? [12:29] We're discussing the possibility of adding a bzr backend for cvs2svn [12:29] (I'm the cvs2svn maintainer) [12:30] the cvs2svn script, last time I looked, was relatively easy to break with 'impossible' (but they happen) timestamp + ,v topological ordering combinations across files [12:30] lifeless: Then I guess the last time you looked was before cvs2svn 2.0 :-) [12:30] I don't mean this as a criticsm btw [12:30] sounds like its improved massively [12:31] The new code uses a dependency graph to deduce changesets, and fixed all the known bugs in 1.x [12:31] It uses quite a bit more RAM, but otherwise works very well. [12:31] does it ever run incrementally, or is it a 1-shot tool ? [12:31] I don't know of a CVS repo that it can't handle [12:31] 1-shot, unfortunately. [12:31] righto [12:32] cscvs for all its flaws is incremental [12:32] Maybe a deep-pocketed sponsor could encourage an incremental conversion feature ;-) [12:32] so it has extra state added to its output to allow incremental operation [12:32] What are the pros and cons of cscvs? I'm not really familiar with it. [12:32] I know every time it was tried on the BSD repo, it fell over. That might have been pre-2.0, though. [12:33] FreeBSD works now. [12:33] Sweet. [12:33] There are some problems with symbols being defined multiple times in a single file. These have to be resolved manually using a "hints" file. [12:34] There's some Scary Shit(tm) hidden in there. Any conversion that can swallow it deserves biiig kudos. [12:34] It is not clear even how a perfect system would deal with corruption like that. [12:34] well [12:34] (The repeated symbols, I mean) [12:34] one is doomed to failure [12:34] the question is how close one wants to come to success ;) [12:35] anyhow, cscvs, whats different - its geared for incremental runs, which means detecting ,v file moves and the like [12:35] added complexity [12:35] multiple front end and back ends [12:35] There were some FreeBSD guys hanging around a couple of weeks ago (converting to git) and I'm pretty sure they were successful after I added the hints file workaround for their duplicated symbols [12:35] its really vcs2vcs these days [12:36] What input/output formats does cscvs have? [12:37] I'm impressed by incremental conversions. I've thought about how to add it to cvs2svn and it will be a good chunk of work. [12:37] its nasty [12:37] don't :) [12:37] [At least if your incremental conversions really work robustly! It's easy to do a "works most of the time" solution.] [12:37] ddaa and mwh know cscvs way better than I do these days [12:38] but reads-from svn, cvs [12:38] writes to bzr (we use this), tla (but we don't use this - it may be bitrotten now) [12:39] Does it read arbitrary svn repos, or only repos that use the stylized trunk/tags/branches structure? [12:39] so, cscvs is meant to break loudly if the incremental conversion looks horked, and let you manually correct the state, then resume [12:39] oh, thats probably the other big difference [12:39] its branch-at-a-time [12:40] so any svn repo, you just identify the path to convert [12:40] what else is interesting [12:40] CVS is also branch-at-a-time? [12:40] oh yeah, there is pure python cvs wire protocol implementation in there [12:40] yes [12:40] Hmmm, that's curious [12:41] cscvs was originally written for a vcs which had no concept of free-form branch naming === mhagger thinks about whether that simplifies conversions significantly [12:41] long as you convert the parent branch[es] first, and provide a way to find them [12:41] It sure must reduce the computational resources needed for a conversoin [12:42] thats one area could do with improvement actually [12:42] Here's a Q: How easy would it be to use some of the properties work planned/done to store up info on file rev sources, so I could "bzr find src/foo.c cvsrev:1.234"? [12:42] fullermd: theres a header in the revision already [12:43] fullermd: have a look at one of the cvs conversions on launchpad [12:44] OK it's bedtime in Berlin... [12:44] Let me just repeat my offer: [12:44] If somebody with bzr experience is willing to join forces, I'd be happy to work on a bzr backend for cvs2svn. [12:45] well [12:45] I'm happy to answer any questions and sketch out the right bits of the bzrlib api to use [12:45] It shouldn't be more than a couple of days work [12:45] we should have everything you might want already present [12:45] if it's possible to have some progress with merge points, I can help [12:46] lifeless: Know one of them offhand? [12:46] drop me a mail if you like, describing what the backend ends - 'robert at canonical' [12:46] I mostly don't have time to find everything and learn all of the bzr concepts [12:46] fullermd: no [12:46] and I'll come back to you with a brain dump and such [12:46] OK, thanks lifeless [12:47] I'll try to get to it in the next couple of days. [12:47] If you are interested, meanwhile look at cvs2svn source files cvs2svn_lib/git_output_option.py and git_repository_recorder.py [12:48] I am swamped :( [12:48] I guess what you need will be pretty obvious by analogy [12:48] I'm racing against the next release clock to get my performance impoved repository merged [12:48] Goodnight, thanks for the interesting conversation! [12:49] night === mhagger is now known as mhagger-afk [12:50] night [12:56] I think I have one bug left in this bisection work [12:56] and it will be done === fog [n=fog@debian/developer/fog] has left #bzr [] [01:11] hmm, 'InventoryDirectory' object has no attribute 'snapshot' [01:12] right [01:12] commit builder has that logic now [01:12] faster, more tightly coupled to the repository so different repos can do different things === p4tux [n=p4tux@189.169.95.23] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [01:18] hi [01:19] morning [01:22] I think I am going to factor out a ParsedRegions class [01:22] once I fix this bug [01:27] good morning [01:28] i'm feeling much better today [01:28] i made some progress on commit [01:28] cool [01:28] I'm a tad seedy [01:28] i suspect a bug in how update_base_.... interacts with the inventory cache [01:28] and horms wedding party is tonight === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr [01:30] poolie: what sort of bug? [01:31] something like the inventory and dirstate being out of sync [01:31] it's just a gut feeling so i don't want to debate if it's likely or not [01:32] i'm just going to see if the same test fails on other wt formats [01:34] fair enough [01:35] what i see in particular is that [01:35] an apparently correct delta is passed in, [01:35] but when the test looks at the inventory later, some files have not been removed [01:36] so its looking at the inventory of the parent? [01:36] or the inventory of the tree? [01:36] the test is looking at the wt inventory iirc [01:36] that would be a bug [01:37] yes, apparently [01:37] in the test - because the update_...delta() method is meant to update the parent tree [01:37] anyhow, that was what i suspected last night [01:37] oh, [01:37] interesting [01:37] of course [01:38] but really we seem to need something that both updates the parent tree and also the wt [01:38] (you can see the method being tested in bzrlib.tests.workingtree_implementations.test_parents) [01:39] why do we need to update both? updates to the current tree can be done directly in dirstate representation === m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has joined #bzr [01:44] poolie: unless there is a performance problem, it seems cleaner to me to do the wt changes and the basis tree changes separately; and theres no performance problem I see doing it separately [01:44] hang on [01:45] okydoky [01:45] i think you're right, i was expecting it to update both of them the same way [01:46] which is not quite sensible [01:46] um [01:46] i agree you can probably do it efficiently with two separate calls [01:47] the wt changes are uncommon [01:47] whereas the parent changes always [01:47] right, only for autoremove and similar things [01:47] umm. hasn't the documentation been updated for a long time or what..? instead of bzr in the documentation, i need to use baz. also it shows the latest version is 0.91, but i have 1.4.2 and all the commands are different.? [01:47] m0rra: 'baz' is a very old tool [01:47] m0rra: I think you have the wrong software package installed somehow [01:48] m0rra: if you are on ubuntu/debian install 'bzr'. [01:48] we should fix that package naming [01:48] there is a bug for it [01:48] bazaar->baz [01:48] ah, i see. i apt-get installed bazaar... [01:48] ok, i see the problem [01:49] food time for roberts [01:49] Do you want a morning sync; I have plenty to do without syncing [01:49] me too, i'm just going to persist with this [01:50] only question would be, do you want me to declare a freeze, declare a slip, do nothing? === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr [01:54] morning === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [01:58] why is build_tree in TestCaseInTempDir and not TestCaseWithMemoryTransport? [01:59] hi jml, igc [01:59] poolie: hello [01:59] jml, i can't see a good reason why [01:59] hi poolie [01:59] withMemoryTransport is robert's invention, he may be able to help when he gets back [01:59] thanks. [02:00] uhm [02:00] those raisins are hysterical [02:00] lifeless: doesn't 'build_tree' build on disk [02:00] hi jam-laptop [02:00] disk or transport [02:00] And "WithMemoryTransport" doesn't have a disk location? [02:00] can do either [02:01] MemoryTransport still has local disk, because of the bug where we write config files [02:01] when you do anything [02:01] and also because posix makes it hard to chdir /nonexisting/path :) [02:01] poolie: release wise - your call, I'm fine however you play it === m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has left #bzr ["] [02:08] lifeless: Btw, any news on my pqm patches - or should I wait until after 0.92 before asking you about those again? === bialix [i=chatzill@77.109.17.57] has joined #bzr [02:25] jelmer: yah, wait a bit [02:25] very single-track right now === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr === fbond [n=fab@pool-71-169-154-64.burl.east.verizon.net] has joined #bzr [02:48] hmm [02:49] someone has disputed the neutrality of the bzr wiki page [02:49] simply because it doesn't list cons [02:54] cons? [03:01] pros and cons === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr [03:01] bzr has only pros [03:04] bialix: I wish :) === pete__c_ [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr [03:04] bialix: then I'd have no work to do ;) [03:04] hmm, if i bzr push to a bzr+ssh server that doesn't exist, it shouldn't bail with a 20 item traceback, should it? it sais ssh: projects.launchpad.net not found; then a huge traceback follows [03:04] no, we work on new features, to increase amount of pros ;-) [03:05] no should not [03:05] lifeless, which wiki page? [03:05] there is bug report about this [03:06] !ubotu fas [03:06] Sorry, I don't know anything about fas - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [03:06] stupid ubotu [03:07] !ubotu traceback [03:07] Sorry, I don't know anything about traceback - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi === orospakr [n=orospakr@bas4-ottawa23-1177612037.dsl.bell.ca] has joined #bzr [03:07] never mind [03:07] keir: no, it shouldn't, I think there's a bug open about that. [03:08] Oh, as bialix said :) [03:09] keir: it's also traceback when your connection suddenly dropped and some more unpleasant things [03:09] that's not very nice [03:09] indeed [03:09] jam-laptop: ping? === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [03:14] hey lifeless [03:14] I managed to crawl into work [03:15] lol [03:15] I was working at the usual time :) [03:15] keir: wikipedia's 'Bazaar_(vcs)' page [03:16] lifeless: I think I may go home [03:17] lol [03:20] apparently Jaq didnt turn up for work this morning [03:20] ahha === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr === pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] === poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has joined #bzr === adhoc [n=kim@ppp121-45-74-196.lns10.adl6.internode.on.net] has joined #bzr [04:22] hi guys... [04:22] can i use bzr with an authenticated web proxy ? [04:26] vila will really know [04:26] but I think you can yes === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr === AfC [n=andrew@m770f36d0.tmodns.net] has joined #bzr [04:43] spiv: ping [04:47] jam-laptop: pong, although I want to get some lunch in a minute [04:52] spiv: k, I just wondered if you had any ideas about trying to track down memory leaks in python [04:52] and what the gc.set_debug() flags really mean. [04:52] Feel free to respond to my email [04:52] (I'm worried I'm setting a refcount incorrectly, and wondering if gc.collect() can tell me about that sort of problem) [04:52] It sounds like it can, but I'm not positive what everything means [04:54] hi jam-laptop long call ? [04:56] about 1 hr [04:57] just dealing with other stuff [04:58] jam-laptop: I'm not very familiar with the precise meanings of the various gc.DEBUG_* flags. [04:59] jam-laptop: although if you're worried about refcounts, perhaps sys.getrefcount or gc.get_referrers may help you test hypotheses. [04:59] well reading http://www.python.org/doc/current/lib/module-gc.html === igc food [04:59] DEBUG_UNCOLLECTABLE [04:59] seemed relevant [04:59] (I'm not sure, but I'm guessing that Pyrex would tend to generate objects that play nicely with get_referrers) [05:00] typing is slow with a baby in one arm Z) [05:00] Right, everything I know about those flags I learned from that page :) [05:01] Well, I guess I could spend some quality time with Modules/gcmodule.c ;) [05:07] don't worry about it too much [05:14] spiv: so is your reconcile patch landed? === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr === jamesh__ is now known as jamesh [05:17] WOOT [05:18] lunchies === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [05:48] so who is dogfooding [05:48] packs that is [05:48] mwhudson: ping [05:50] bzr.dev is edgy enough for me... [05:53] def all_revision_ids(self, transaction): [05:53] """See RevisionStore.all_revision_ids().""" [05:53] rev_file = self.get_revision_file(transaction) [05:53] return rev_file.get_ancestry(rev_file.versions()) [05:53] thats a WTF moment right there === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [05:59] Subject: Should we baptized "in the name of the Father, Son, and Holy Spirit" or "in Jesus' name"? [05:59] now that is offtopic [06:00] "either, as long as it is a utf-8 name" [06:00] Sounds like a difficult debate. We should compromise and do it in my name instead. [06:00] wow [06:00] I just managed to trip a md5 has collision on pull [06:01] really? [06:02] yeah, packs with the same data have the same content :) [06:03] so the question is why I'm copying this data at all [06:06] igc: poolie_: jam-laptop: partial-index-using packs pushed to my usual 'repository' branch === bratsche [n=cody@adsl-68-94-34-240.dsl.rcsntx.swbell.net] has joined #bzr === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr [06:35] (reading ian's paper) [06:44] ah, I think I know [06:44] see if this scans [06:45] do a commit, adds a revision that triggers autopack [06:45] something causes a failure right there [06:45] mm more detail [06:45] we autopack [06:45] add the new pack and its indices [06:45] then start removing the obsoleted packs [06:45] which is where it breaks [06:46] the result is that we have a set of packs, which when packed generate the same pack again [06:46] and that new pack is already present [06:48] if this theory is right [06:48] doing a manual pack will let me pull bzr.dev [06:48] because it doesn't aim for the log distribution [06:49] thanks lifeless [06:50] spiv: what did you think of my python bug ? :) [06:50] yup, doing a pack let it work [06:51] wow, performance jump :) [06:53] lifeless: cute [06:54] spiv: is your reconcile patch ok'd ? and merging ? === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr [07:00] poolie_: igc: spiv: requesting a review of the index bisection patch. [07:00] This is the last patch needed to send in a patch adding packs. [07:01] hm, how big is it? [07:01] big [07:01] ok === poolie_ rolls up his underscore sleeves === poolie_ is now known as poolie [07:02] NEWS | 10 [07:02] bzrlib/bisect_multi.py | 64 ++++ [07:02] bzrlib/index.py | 504 ++++++++++++++++++++++++++++++++++++-- [07:02] bzrlib/tests/__init__.py | 1 [07:02] bzrlib/tests/test_bisect_multi.py | 344 +++++++++++++++++++++++++ [07:02] bzrlib/tests/test_index.py | 290 +++++++++++++++++++++ [07:02] bzrlib/tests/test_knit.py | 12 [07:02] 7 files changed, 1198 insertions(+), 27 deletions(-) [07:02] sweet, we have patch markers now? [07:03] mm? [07:03] i imagine he ran diffstat by hand [07:03] it would be nice if send did it though [07:03] oh, i didn't know that command existed [07:03] keir: 'bzr send -o- | diffstat' [07:03] also there is a diffstat plugin [07:03] but I haven't used it so can't comment === fullermd still misses CVSish +/- in log :| [07:04] keir: my repository branch now does the naive bisection robustly [07:04] lifeless, niiice! [07:04] fullermd, i can't remember what that is [07:05] keir: looks like there is *tonnes* of room for improvement on this though, with the design we've been batting around [07:05] lifeless, yeah, i like the differential encoding of the hash table [07:05] i'll read that patch then take a break i think [07:05] lifeless, it's a nice little trick [07:05] revision 1.7 [07:05] date: 2006/01/21 01:17:04; author: mfuller; state: Exp; lines: +29 -7 [07:05] yup [07:06] I think that + topological grouping on the first graph, is going to be quite a huge win [07:06] lifeless, i agree totally [07:06] Easier on my eye than diffstat for a quick glance at magnitude. Maybe that's just familiarity, but... [07:06] fullermd: per-file [07:06] fullermd, i def. prefer diffstat [07:07] i'd even like to get diffstat by default on commit and such, but i'm crazy [07:07] lifeless, is it possible at all for lookup_keys_via_location to be split up? [07:07] or _parse_region for that matter [07:07] lifeless, on a slightly different note, i've been trying to figure out what i don't like about the bzr dev docs [07:07] fullermd: also, you know about diffstat's format parameter ? [07:08] keir: I think the diffstat plugin may do that [07:08] I s'pose once I dig into writing commit mailings on bzr, I'll end up having to get my brain on diffstat, since it exists and a straight +/- doesn't. [07:08] keir: if it doesn't, you can definately do a post-commit hook plugin to do it [07:08]