[00:34] hmm, test suite core dumping [00:34] :( [00:34] trying pristine pbuilder to make sure my environment isn't the problem [00:39] hi guys [00:39] if I have a branch that is stacked on another [00:39] how can I confirm (in a unit test) that the branch that is stacked doesn't have all the revisions? [00:40] a simple count of revisions in the branch's repository would suffice for the test case I guess [00:42] stacked_branch.bzrdir.open_repository().all_revision_ids() [00:42] lifeless: ta [00:42] stacked_branch.repository.all_revision_ids() [00:42] set and difference kgo [00:42] spiv: ping [00:44] lifeless: pong [00:45] so jam and vila seem to not be fixed by the bug fix [00:45] see last night around 11 [00:48] Hmm. [00:49] thumper: yes. [00:53] * spiv tries to reproduce [01:06] lifeless: I can't reproduce; if I push that same bbc-1.14 branch with bzr.dev I get the error on pull, and if I push it with the fix branch I don't get the error. [01:07] spiv: then I blame 'they didn't use the new branch' [01:07] lifeless: that's my guess. [01:08] It's possible that at the time vila pushed up the bzr.dev in LP was a bit different so as to tickle subtly different case, but that strikes me as unlikely. [01:12] agreed [01:12] vila: ping [01:12] jam: ping [01:12] ^^^^ [01:30] hello - is this the place for bzr help? [01:30] its a place ;) [01:30] anyone will do - thanks ;-) [01:34] I'm a *complete* bzr naif. Here's my problem. (Sorry if my terminology is wrong.) [01:34] I branched mailman 2.1 awhile ago and made changes to one file, .../cron/gate_news. [01:34] I then pushed that to launchpad. Now I want to make a mailman 2.2 branch and [01:34] transfer all my changes to that branch. How do I do that? I have my mailman 2.1 [01:34] branch and a pristine mailman 2.2 branch. My first change was at rev 1135. My [01:34] last was at rev 1139. Do I just get a diff and apply it with patch or is there a more [01:35] bzr-ish way to do that? [01:35] cd mailman2.2; bzr merge $path_to_mailman2.1 [01:35] you could first try "bzr merge " [01:35] depending on how mailman 2.1 and 2.2 are maintained this may do more than you want [01:36] if it's small things such as the version number you can revert them and commit [01:36] Yeah, I just want *my* changes to the 2.1 branch [01:36] if it's huge then you want to cherry-pick [01:36] skip_m: start by trying the simplest thing [01:37] skip_m: if that grabs too much, use merge -r branch:lp:mailman/2.1.. $your-mailman2.1-branch [01:38] The simplest thing for me is 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' but is that the correct way to do things? [01:38] liefless: I don't understand the merge -r branch... thing. [01:39] skip_m: it would figure out the 1134..1139 for you [01:39] 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' is better written as 'bzr merge -r 1134..1139 ../mailman2.1' [01:40] And if that merge command doesn't do what I want is there a way to easily revert it or do I just blow away my mailman2.2 repo and branch again? [01:40] 'bzr revert' [01:41] ok - skip holds his breath and gingerly types 'bzr merge -r 1134..1139 ../mailman2.1' RET [01:43] have you tried just 'bzr merge ../mailman2.1' ? [01:43] not so good. Something about 34 conflicts. To many files I didn't touch. bzr revert looks bad too. Time for 'rm -rf ; bzr branch ...' [01:43] lifeless: no, i'll try that next. [01:43] skip_m: huh, no need to rm -rf [01:43] what did bzr revert do? [01:44] it was ugly: [01:44] % bzr revert [01:44] - cron/ [01:44] -D cron/gate_news.OTHER [01:44] -D cron/spambayes.ini [01:44] Conflict: can't delete cron because it is not empty. Not deleting. [01:44] And I wound up with a mailman2.2 which had a 2.2 directory and an empty cron directory. [01:44] It's all gone now. [01:45] (should I be using pastebin or something for these little snippets?) [01:45] skip_m: no, its fine [01:45] anyhow, if you ever feel the need to rm -rf, just ask; you shouldn't ever get that wedged with bzr [01:45] so, try 'bzr merge ../mailman2.1' [01:46] lifeless: that's what people tell me about mercurial too. I think it probably boils down to me being an old fart. CVS and Subervsion are probably about all my feeble brain can handle. :-/ [01:46] its the simplest, and often the right command to use [01:46] hey beuno :) [01:47] do you know if there's an equivalent in bzr to rebase in git? [01:47] so all the conflict means is that there was a file (gate_news.OTHER) that bzr didn't put in cron, that would be permanently lost if bzr deleted the cron directory [01:47] Ursinha: 'rebase' [01:47] hahaha [01:47] simple as that :) [01:47] It's a plugin, though, bzr-rebase. [01:48] oh, now I understand why I couldn't find it right away [01:48] thanks Peng [01:48] Peng_, even [01:48] and lifeless [01:48] np [01:48] skip_m: so, bzr doesn't delete cron and lets you decide how to handle the situation [01:50] skip_m: how did 'bzr merge ../2.1' go for you ? [01:51] (and when we say ../2.1, we mean the path to your patched copy of 2.) [01:51] (although, IIUC, it seems like a bug that revert doesn't implicitly mark conflicts as resolved, thus removing the conflict files, thus removing one common source of irritating and confusing "can't delete some_dir" conflicts) [01:52] ok - i figured out what went wrong. I had INSTALL, FAQ, cron, ... in my mailman2.1 dir. When I branched in my mailman2.2 dir it created a 2.2 dir containing INSTALL, FAQ, cron, ... Doing a bzr merge there failed miserably. Next time around I mv'd 2.2/* and 2.2/.bzr* to . which then made mailman2.1 and mailman2.2 proper siblings. The merge worked *much better*: [01:52] spiv: it does, but revert can conflict itself [01:52] % bzr merge ../mailman2.1 [01:52] +N cron/spambayes.ini [01:52] M cron/gate_news [01:52] Text conflict in cron/gate_news [01:52] 1 conflicts encountered. [01:52] I'm sure I can fix the gate_news conflict with no problem. [01:52] Thanks for the help folks. Right now I'm off to the pool (swim, swim, swim - sure beats typing at the keyboard every now and then!!!) [01:52] ciao [01:53] lifeless: any case that "bzr merge SOMETHING; bzr revert" doesn't Just Work smells odd to me. [01:54] spiv: I agree; skip_m hadn't done that though :) [01:54] the .orig file causing the conflict was the output of patch [01:55] igc: could I bother you to get usertest to tell us if trunk has regressed in performance at all [01:55] igc: what with the big merges yesterday [02:11] lifeless: sure. I'm working on exactly that (great mind think alike) [02:11] lifeless, spiv: some pain though ... [02:11] bzr.dev 4266 can't branch Bob's 1.14rc branch :-( [02:12] the AbsentContentFactor get_bytes_as bug [02:12] igc: grab it via http rather than bzr+ssh [02:12] as a workaround [02:13] spiv: cool. I was about to try that [02:13] spiv: just a reminder about how bad that bug is (not that you needed reminding) [02:24] so spiv: how do I find http address for an lp branch? It's no longer in the UI? [02:24] jml: ^ [02:24] igc: lp:~aa/bb/cc -> http://bazaar.launchpad.net/~aa/bb/cc [02:24] thanks [02:38] igc, spiv, poolie: can we get some reviews of abentley's big branch for nested trees please? We don't want it to go stale again. [02:59] lifeless: you around? [02:59] lifeless: I have a stacking question === timchen1` is now known as nasloc__ [03:07] thumper: ask the question :) [03:08] lifeless: skype would be easier I believe [03:08] spiv: I reckon land that fix [03:08] thumper: ok [03:15] lifeless: hmm, yeah [03:18] Any major bzr folks in the Bay Area? [03:31] davidstrauss: thats SF right? [03:31] lifeless: yes [03:31] lifeless: I'm in SF for the week for Drupal.org sprinting, and I'm always looking to see friendly free software faces :-) [03:32] davidstrauss: uhm, dunno :). robey pointer is there I think, but he's paramiko/loggerhead and other things, not so much a regular bzr person [03:32] lifeless: I met with Aaron when I was in Toronto [03:32] davidstrauss: I'd drop a mail to the list TBH [03:32] or twitter or whatever [03:32] lifeless: TBH? [03:32] lifeless: I'll tweet it [03:32] to be honest [03:32] ok [03:32] lifeless: thans [03:32] lifeless: thanks [03:49] igc, ping [03:53] hi rockstatr [03:53] rockstar^ [03:53] thumper: sure, planning to review it RSN [03:54] * spiv -> lunch [03:54] thumper: just running some performance tests first so we know when 1.14 is better than 1.13 and --development is better than --1.9 [03:55] jelmer: Yay, you upgraded bzr-svn to btrees. :) [03:59] igc: great [04:00] * igc lunch - bbiab [04:04] igc, hi, for some reason, your response didn't turn my tab blue. [04:04] If I branch a library into a subdirectly of tree and "bzr join" it, will I still be able to merge in upstream changes from the library's original branch? [04:05] And, if so, how would I perform such a merge? [04:07] igc, I'm integrating your revnocache into loggerhead. [04:07] igc, and I'm can't think of a single use case for RevnoCache. [04:11] igc, but I can see a use case of the opposite graph: {revid: revno} [04:16] Er, I mean {revno: revid} [04:27] igc, so I guess I have two questions: (1) how is RevnoCache supposed to be used, and (2) why use a tuple to describe a dotted revno? [04:38] rockstar: so the secret to integrating revnocache is this: make sure loggerhead is getting the graph by using Branch.iter_merge_sorted_revisions() [04:38] rockstar: there is no step 2 :-) [04:39] rockstar: revnocache is about to be superceded by bzr-historycache btw [04:39] igc, :( [04:39] bzr-historycache will do the same thing but more [04:40] Is --reference being dropped as an option to "join"? [04:40] davidstrauss: the nested tree stuff is actively being changed right now [04:40] igc, so my RevGraphCache gets created with Branch.iter_merge_sorted_revisions() [04:41] davidstrauss: abentley is the man to ask [04:41] rockstar: so revnocache had multiple ways of caching revnos - history will use just the best of those and be configurable as to whether it's on or not [04:41] thumper: Currently, if I join a branch, I lose "common history" with the branch I joined from [04:41] rockstar: yes [04:41] thumper: I'll ask abentley [04:41] :) [04:41] and the next call to it (or the next call to a dotted revno lookup) uses that cache [04:41] igc, ah, so I was using all three types of cache, but it seems like RevGraphCache and a mapping of revno->revid should be all I need. [04:42] rockstar: you want graph caching, I think it's called "revgraph" or something like that in revnocache [04:43] igc, yea, RevGraphCache. [04:43] ignore the others [04:43] igc, yea. [04:44] rockstar: I'm about a week away from releasing historycache [04:44] igc, so, I also need to convert a stringified revno to a tuple revno for that graph. Is there a helper function for that, or do I create my own? [04:44] I have some other things ahead of it in my queue, e.g. confirming the NG format is performing well on all use cases, reviewing nested trees, etc. [04:46] rockstar: I'll look, but something like tuple(revnostr.split('.')) ought to go close [04:46] igc, yeah, that's similar to what I was thinking. [04:49] rockstar: so it turns out to be slightly more complex ... [04:49] grab parse_revno from revnocache/revnocache.py [04:49] if I have an open branch, how do I get the transport for that branch? [04:50] it would be nice to have that in the core I guess, so put up a patch if you get a moment [04:50] rockstar: ^ [04:51] rockstar: any other questions for now? I'm about to head into the other room where my desktop is for a while [04:51] hello igc [04:51] hi poolie - welcome back! [04:51] thanks [04:52] poolie: hope you had a great break [04:52] igc, I don't believe so. I'm already pretty far along. [04:52] it was great, thanks [04:52] rockstar: if you do, just put a message into IRC or email and I'll check back later [04:53] igc, thanks for the help. [04:58] nm === release is now known as samurai [05:27] how can I update my working tree to a specific revision? [05:31] I'm not finding the "Register a release" under the 1.14 series, perms problem? vila ? poolie ? [05:31] hi BasicOSX [05:32] hi, attempting to register 1.14rc1 and upload the .zip and tar.gz, but do not see the "Register a release" for 1.14 series [05:32] sohail: 'bzr pull -r 123 .' [05:32] BasicOSX: hm me either [05:33] don't see it for 1.13 either :-( [05:33] BasicOSX: i think this changed in the last release of lp [05:33] hmm, once I figure it out, I'll need to update the releasing documentation [05:34] I see your Code for this series now [05:34] BasicOSX: maybe you need to add a milestone? [05:35] there was some work on fusing releases and milestones [05:35] There is a 1.14rc1 milestone there already, let me look at it [05:35] http://blog.launchpad.net/coming-features/linking-project-releases-in-launchpad-to-milestones [05:38] BasicOSX: you could ask in #launchpad [05:38] some devs idle there ;) [05:39] I get this message from bzr status: 'Text conflict in cron/gate_news' [05:39] I took care of the conflicts in the source and deleted the cron/gate_news. files. Still the [05:39] conflict message is there. How do I get rid of it? [05:39] long time cvs user. . . been reading about and playing with bzr. Seems v.cool, is this an appropriate place to ask questions if I need help? (after researching first) [05:40] SKArfaceGC: 'bzr resolve' [05:40] sorry [05:40] skip_m: ^ [05:40] :) [05:40] SKArfaceGC: sure it is [05:40] cool. [05:40] but not from me right, now [05:40] * lifeless heads to the shops ;) [05:40] Don't have any at the moment. just lurking [05:40] lifeless: thanks [05:42] In my mailman2.1 repo I have this push branch: [05:42] bzr+ssh://smontanaro@bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/ [05:42] Can I just push to it from my mailman2.2 branch without creating problems? [05:42] SKArfaceGC: you may want to know that both this channel and the project's mailing list are used jointly for user[s of bzr] as well as hacker[s working on the tool] discussion. So sometimes it can get a little esoteric [05:45] I write large security software for a living. I can deal with esoteric. :) [05:46] poolie, thank you! [05:46] I used bzr push --overwrite ... which seemed to work. If that was a bad thing, speak now or forever hold your peace. :-) [05:59] skip_m: push --overwrite will overwrite the history in that branch to be the same as the branch you are pushing from [05:59] skip_m: so if that's what you wanted to happen, then that's fine :) [06:00] spiv: Thanks - that's fine. Mailman 2.1 is a dead end. I was asked to port my changes to Mailman 2.2. I officially no longer care about [06:00] mm 2.1. [06:00] lifeless: btw, my fix branch failed because it adds one more get_parent_map call the stacked push acceptance test. [06:00] skip_m: sounds good then. [06:02] skip_m: (normally in that situation I would have merged 2.2 into my branch and committed that, in which case a regular push would work just as well as there is no divergence of history) [06:03] hrm. . . are there any karma granting/branch locking hooks available? Something like sheila for CVS [06:03] spiv: i know nothing about the possibly divergent histories of mm 2.1 and 2.2 (and don't really care). I just wanted to get my little enhancement out there for people to use. [06:07] spiv: as it stands it has to [06:07] spiv: so +1 to increasing the ratchet === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc1 released 07 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [06:08] lifeless: that's my feeling too. Glad you agree :) [06:11] BasicOSX: Congrats on the release (candidate). :) [06:11] long road traveled on this one.. thank you though [06:13] On a different subject, is it just me or do some of BasicOSX's gpg-signed emails fail verification? Like the 1.14rc1 announcement on the announce list. [06:15] That's the 2nd time I've heard that. Seems to be only to mailing lists. [06:15] Oh, nice. [06:16] First time was a user on Win32, so I, well, kinda ignored them [06:16] tbird doesn't have the best pgp hooks [06:16] (not that mail.app is any better) [06:17] * Peng_ is using Thunderbird + Enigmail [06:17] :-P [06:17] On windows? :-) [06:17] No, an out-of-date Ubuntu box. :D [06:18] sheesh bug reports coming in on 1.14rc1 already [06:20] I think several of you have been to bed and gotten up again while I've been awake. :\ [06:21] (Well, if you haven't, then you should be getting more sleep!) [06:29] lifeless: btw, I'm using ec2test. [06:43] PQM playing 1.14rc1 back into bzr.dev, afk for dinner [06:45] spiv: liking it ? [06:53] lifeless: it's neat, but it'll be much more likeable with the rough edges smoothed off :) [06:53] spiv: thats true [06:56] spiv: feel free to shave :) [06:57] lifeless: any thoughts on bug 357478? [06:58] Launchpad bug 357478 in bzr "development6-rr vs gc-chk255-big regressions" [Undecided,New] https://launchpad.net/bugs/357478 [06:58] igc: none beyond my reply [06:58] oh, I didn't see that - I'll look [06:58] hi all [06:59] hmm, I may not have disabled tree references enough [07:06] hi vila [07:14] spiv: +1 on any changes to ec2.test [07:14] .txt [07:17] spiv: possibly we should ask the source, or more-local of the repositories for the parents. [07:17] spiv: or something [07:18] lifeless: yeah. It would be nice to have a good way of saying "get these {parents,revisions,whatever} from a set of repositories, but try the most local first". [07:18] It's a desire that comes up occasionally. [08:18] hello all, congrats on landing brisbane-core in trunk [08:18] two observations [08:19] commit after status seems really quick (delta over status is low) [08:19] excellent [08:19] that was one of the key things we were removing overhead on [08:19] and thanks [08:19] explicit commit (commit file file file) seems slower than normal commit, which i don't understand since it doesn't have to check as much dirstate [08:19] and commit after add seem much slower than it used to be [08:20] explicit commit: we can't use the new commit code path in all cases yet; we have to teach our core diff logic (iter_changes) to report parent directories in some cases, or you end up with a broken commit [08:21] aha [08:21] this is one of the things we'll polish while its a beta format [08:21] so you're seeing the older commit codepath when you do commit [paths..] [08:21] doing commit -x path will trigger that too, as iter_changes hasn't been taught to do excludes [08:23] commit after add: is it slower for both the initial commit, and later commits after adds, or just the initial one? [08:24] the split inventory structure requires more calculation to create the initial tree than the old flat-file xml format (but it wins massively on subsequent commits as you're seeing) [08:25] so another item of polish is to work on making that initial tree operation faster [08:28] The old format just wants everything in the tree appended to a list, whereas the brisbane-core format builds a dictionary. That said, there is plenty of room for optimisation. [08:46] BasicOSX: please do update NEWS in bzr.dev :) its in the process I thought.. [08:47] I merged bzr.dev into my local branch, fixed up the conflicts, PQM'd it back, got a success [08:48] merge lp:~tanner/bzr/1.14rc1 http://bazaar-vcs.org/bzr/bzr.dev [08:48] Command was successful. [08:48] lifeless: ec2 fix BB:approved, lowering (but not zeroing !) ec2 setup priority :) [08:48] I did merge my lp branch "merged" so it doesn't show [08:48] and a fresh branch of bzr.dev show my merge [08:48] ok [08:49] I've just not pulled in the last 40 minutes :P [08:50] hmm, patch succeeded at 1:22am CDT [08:50] fsvo 40 [08:50] :P [08:51] BasicOSX: bzr version now shows 1.14rc1 in bzr.dev ! [08:51] * BasicOSX hides [08:51] lol [08:52] I'm bring down fresh, I'm sure I forgot something :-( last part of releasing documentation isn't very detailed (I'm fixing that) [08:52] BasicOSX: when you merge back you need to preserve bzr.devs concept of being bzr.dev [08:53] so its merge, tweak NEWS bzr bzrlib/__init__.py [08:53] yes, my mistake [08:53] BasicOSX: visual inspection bzr diff -c 4267 doesn't reveal anything else, you're doing good ! [08:55] BasicOSX: I suspect you're bumping into many "it's so obvious it's not documented" points due to previous RMs being more experienced and you did a good job already updating the release process documentation, so, it's just part of it [08:57] sadly, my free time is 11pm-3am, so the documentation is my double check when I'm sleepy [08:57] well, the docs used to say to do this [08:57] but perhaps lost at some point [08:57] If it's not already done, advance the version number in bzr and bzrlib/__init__.py. Submit this back into pqm for bzr.dev. [08:58] I read that as advance it from 1.13final to 1.14rc1 [08:58] that line lies [08:58] or [08:58] is overly brief [08:58] I got notes now, need to make sure it's 'dev' [08:59] so advance means 'change 1.14dev to 1.15dev' [09:00] ok, just need branch, it's 1,14,0,'dev',0, [09:00] yup [09:00] later all [09:01] do I need to update bzr's _script_version too ? [09:06] BasicOSX: yes, it's even surprising it isn't mentioning dev... [09:15] * BasicOSX winks [09:15] lifeless: beat me to pqm [09:16] lp:~tanner/bzr/bzr.dev has my fix in it, if someone wants to verify [09:16] v$ ./bzr --version [09:16] Bazaar (bzr) 1.15dev [09:17] 3:17am, sleep, email me if I need to work on other stuff I messed up :-) [09:18] BasicOSX: good night ! [09:47] * igc dinner [09:50] spiv: you about? [10:11] hello johnf [10:12] poolie: howdy [10:55] using the central repository model, is there an easy way to get the server to run a test suite every time something is checked inot the branch (or merged in, etc) [10:57] * Kinnison uses a pqm for that, perhaps a server-side commit hook? [11:13] Mez: PQM is here: https://launchpad.net/pqm [11:14] *: Is there a way to aggregate multiple changes into a single revision in bzr? [11:14] Background: I was messing around with bzr-gtk (not having used pygtk for a while) and would like to post the patch. [11:15] But I don't think anybody would like to see the debugging code I originally had in there and the bzr misuse I did (created a conflict due to bzr push not updating the working copy). [11:16] Mez: sure use a pre_branch_tip_change_hook [11:16] Mez: (see bzr help hooks) [11:17] Mez: pqm is not easy ;P [11:17] lifeless: but it looks like an interesting concept ;-) [11:17] Bluehorn: it is, and it works well, its just not easy ;) [11:48] lifeless: only through p1m? [11:48] lifeless: never mind, was reading something els.e [11:48] I'm actually looking for a post-hook, but something easy [11:49] mail the list, its late for me, I'll whip one up for you tomorrow [11:49] thanks lifeless [12:41] Hi, I am attempting to follow: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style however, I am unclear about the setting up the shared repository step. I did the setup mentioned at the "Starting a central branch" section a bit higher up, then followed the distributed setup, but after I make my feature branch, and try to merge ../trunk/ to the feature branch, it complains I have uncommitted chang [12:41] es [12:41] the documentation didn't make this clear what I should expect [12:55] ormandj: you haven't committed your changes [12:55] ormandj: you need to commit after you make a change to a branch [12:55] lifeless: the documentation example didn't show the commits that's why i was confused about this [12:55] it shows running the merge *before* committing [12:56] ie: merge from the trunk to my new branch, then commit the merged changes along with my updates [12:57] (i'm doing the distributed style setup described) [13:07] well, the new branch has no changes in it when its just made; if you are getting told you have changes something odd is happening :) === abentley1 is now known as abentley [13:50] Hey. I want to use bzr on my web server to keep web development projects organized. I'd like to have a main branch and a development branch, then my main public_html folder where i would pull from the main branch for deployment. What would this kind of workflow look like? [13:51] it would look like a main branch, a development branch, and your public_html folder a third branch :) [13:51] or you could use bzr-upload for deployment [13:52] so the main folder used to serve web pages to apache would be a bzr branch itself? or a mirror? or something else? [13:53] most people seem to use bzr-upload for that folder [13:53] its a plugin [13:53] that is what I would advise [13:54] cool [13:54] i'll check that out [13:54] thank you [14:37] vila: I've just sent a new [MERGE] request [14:37] vila: which has the other stuff I was muttering about [14:40] lifeless: ok, will have a look (by the way, the tests *were* passing here ;-) [14:41] vila: not with my print intend change [14:41] vila: your write() call wasn't indented [14:41] lifeless: indeed, because I just copy/paste from my branch :) [14:41] see ;) [14:42] lifeless: doesn't really matter, it's just that we talked about it but it was never merged [14:42] sure [14:42] I think you'll like it [14:46] vila: if you wanted to review it now, I could land it immediately ;) [14:46] lifeless: I am [14:47] thank :) [14:50] BB:tweak, I think there is another atexit.register() you may want to get rid off, the one that delete the /tmp dir, plus some tests for done, startTests() :) [14:50] or did I miss the tests ? [14:50] well [14:50] I moved code [14:51] nothing 'new' really :) so existing tests should suffice [14:51] if nothing was testing the output, then I haven't reduced the coverage; if it was tested, then I preserved the behaviour [14:51] nothing 'new' but startTests() and done() just want to be extended/overriden :0) [14:52] what sort of tests would you like to see? [14:52] simplest ones: they are called once [14:53] seeing the modification of InstrumentedTestResult made me think they should be trivial to add [14:53] morning lifeless, shouldn't you be sleeping by now :) [14:54] jam: yes [14:54] vila: cut you a deal :) add some tests, land it ? :) [14:54] deal [14:54] cool - thanks [14:54] More often than not I feel I want to do that for many reviews... [14:55] with this, the output from selftest --parallel=forked looks like normal [14:57] err, I hope you haven't addressed the tracebacks *during* execution :-) [14:57] oh, you'll want https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346 [14:57]