[00:58] <KhaZ> Hi!  Quick question here.  I've historically ran one large depot in svn, with multiple projects inside of it.  I'm thinking of splitting them each into their own repositories - is there a 'smart' way of doing this, so as to keep revision history?
[00:58] <lifeless> bzr svn-import will may just do the right thing
[00:59] <lifeless> it will depend on how your svn repo is structured
[00:59] <KhaZ> Sorry, I should have specified - I've currently bulk imported them into a bzr repo
[00:59] <lifeless> using svn-import ?
[00:59] <KhaZ> Yes.
[00:59] <lifeless> and it didn't identify the branches for you ?
[00:59] <KhaZ> So I've got one giant repo with allm y changes from svn (Yay svn-import!), and I'd rather not lose them as I break them into smaller repos.
[01:00] <KhaZ> Well, I didn't do my svn repo as branches.  It was more just a series of directores inside of 'trunk'.
[01:00] <lifeless> ok
[01:00] <lifeless> well you can tell bzr-svn where the branches should be
[01:00] <lifeless> then svn-import again, and it will split appropriately
[01:01] <KhaZ> lifeless: Is there any thing I can do the bzr depot?  I've grown rather smitten with bzr and have been doing changes against it, instead of svn.
[01:01] <lifeless> KhaZ: well, you can use bzr split, but it will still keep the older history as being one-big-depot
[01:02] <lifeless> so if you're splitting for size reasons it won't help you, but if you'resplitting just for clarity it will do what you need
[01:02] <KhaZ> lifeless: So, say I have directories A, B, C, and I want to split them into their own depot.  Are you saying it'll keep all the histories, but only branch the contents?
[01:02] <KhaZ> (i.e., I'll have branch 'A' with only contents from A, but histories from B and C as well?)
[01:02] <lifeless> yes
[01:02] <lifeless> because one commit back would be the big tree
[01:03] <lifeless> what split does is essentially bzr branch your depot, delete everything except the named directory (e.g. A) and then commit
[01:04] <KhaZ> And there's no way to obliterate history in bzr?
[01:04] <lifeless> not directly no
[01:05] <lifeless> you could fast-export your depot then fast-import-filter it back in
[01:05] <KhaZ> Hrmm.  I guess I'll have to think about this.
[01:06] <lifeless> the fast-export approach soundslike its the closest fit to what you're asking for
[01:06] <lifeless> (its a bzr plugin)
[01:07] <KhaZ> lifeless: Ah, neat.  I'll have to check that out.
[01:07] <KhaZ> Thanks for spitballin' with me lifeless .
[01:08] <lifeless> np
[01:30] <lifeless> jml: around?
[04:25] <jml> lifeless: am now.
[04:28] <lifeless> what would you like to see in subunit before an announcement to tip
[04:28] <lifeless> or alternatively
[04:29] <lifeless> what things are 'it really should have' for subunit that it doesn't
[04:37] <lifeless> jml: ^
[04:38] <jml> lifeless: a web page with some friendly guff + documentation.
[04:39] <jml> lifeless: not sure what else
[04:40] <jml> lifeless: some kind of effort to integrate with nose, maybe
[04:40] <lifeless> what would that do?
[04:40] <jml> lifeless: get nose to print subunit output
[04:41] <lifeless> ah, tell it to use a subunit TestResult?
[04:41] <lifeless> https://edge.launchpad.net/subunit isn't sufficient guff?
[04:46] <lifeless> bug 332770
[04:52] <lifeless> jml: with pycon coming up it seems worth trying to get a 'release' done
[04:54] <jml> lifeless: I think a more friendly "how to" style document would be a good idea
[04:55] <lifeless> jml: do  you have any interest in writing it ?
[04:56] <jml> lifeless: yes.
[04:57] <lifeless> cool
[04:57] <jml> lifeless: but before pycon? ... we'll see.
[06:58] <lifeless> jml: what would you expect the commands 'subunit-filter' and 'subunit-ls' to do
[07:31] <lifeless> abentley: the --no- option stuff - was that exposing something optparse does anyway, or custom for bzr?
[09:26] <scode> I would like to use bzr with a workflow similar to what is often used with e.g. darcs/git, where I have my 'upstream' repository that I have branched on multiple places. I then want to commit and periodically push from all these places, but I do not want to do a bunch of merges all the time.
[09:26] <scode> I have vague recollection of there being a way to do a "flat" merge that does not track the merge history to accomplish this, but I cannot find it now.
[09:27] <scode> I.e., the problem isn't that I have to use "bzr merge", but rather that I do not want to litter the history with a lot of bogus merges that do not actually represent merges frmo the perspective of the workflow.
[09:29] <luks> by flat merges you mean joining multiple commits into one?
[09:29] <luks> or re-applying the patches from the merge branch?
[09:29] <lifeless> scode: well, if you actually have flat history there won't be merges at all
[09:36] <lifeless> scode: so if its just you on many machines
[09:36] <scode> I want to merge the changes into my wc without bzr actually treating it like a merge.
[09:37] <scode> Example workflow:
[09:37] <scode> * branch to A and B
[09:37] <lifeless> scode: you can just sit down, bzr pull, commit push etc
[09:37] <scode> * add file in A, commit, push
[09:37] <scode> * add file in B, commit push -> bork because I need to merge, merge, push -> upstream now has a merge in the history
[09:37] <lifeless> scode: so if you have committed in A and B concurrently, you need to merge
[09:37] <scode> lifeless: Yes, but it's very easy to forget to push , and sometimes I may not have access to do so.
[09:38] <lifeless> scode: you ahve two choices, don't actually commit in B until you pull, or rebase
[09:38] <scode> Using the rebase plugin?
[09:38] <lifeless> yah
[09:39] <lifeless> its how many git users avoid merges
[09:39] <lifeless> I don't think merges are an issue myself - if you have actually done concurrent changes they just reflect reality after all :)
[09:39] <scode> Well, in git I don't end up with having to merge by default at all, assuming no conflicting changes.
[09:39] <scode> And definitely not with darcs.
[09:40] <scode> lifeless: Well, in this case it's not very useful and just confusing to be keeping all that merge info in the history.
[09:40] <scode> lifeless: Especially since the branches are not really branches workflow wise, and have no identification.
[09:40] <scode> Just n random branches.
[09:40] <scode> Anyways.
[09:40] <scode> lifeless: Thanks!
[09:41] <lifeless> scode: so you can also
[09:41] <lifeless> merge --pull
[09:41] <lifeless> (or just pull)
[09:42] <lifeless> git doesn't have magic here - a fast forward pull is either an exact match, or a rebase, or an implicit merge
[09:42] <lifeless> (where it merges for you)
[09:42] <scode> lifeless: Yeah, but since git doesn't track merges it doesn't really matter :)
[09:43] <luks> it does
[09:43] <scode> In the case of darcs there's definitely no difference at least, I could be wrong about git.
[09:43] <lifeless> scode: you mean in log? (git does track merges, exactly the same as bzr - a list of N parents to a commit object)
[09:43] <scode> In the sense of not affecting revision numbers, etc since your branch is just a sequence of hashes.
[09:44] <scode> Though I guess it doesn't look too nice if you ever want to check out the branching history.
[09:45] <scode> I suppose what I really want in this case is simply darcs semantics.
[09:59] <lifeless> scode: yes, darcs semantics are quite nice in some respects
[10:02] <lifeless> jml: if you're around, I have a subunit-ls too; pondering same-branch/different-branch
[13:02] <nabob> hi
[13:33] <abentley> lifeless: The hidden, automatic nature of the no- options is custom.
[17:47] <pisi> Stupid question but something that always pisses me off with web based VC viewers: how could I checkout http://bzr.tensixtyone.com/pytikitag/files ? which is the URL for bzr ?
[17:49] <james_w> it's not clear
[17:50] <james_w> unfortunately there is no way to know, as it is possible to set up access to the branches in many ways
[17:50] <pisi> is there some standard or something that I could try?
[17:51] <james_w> well, using the same URL often works (without the "/files" bit)
[17:51] <james_w> but in this case it doesn't seem to
[18:55] <Peng_> Loggerhead trunk can now serve bzr, and gives the URL for it.
[21:00] <alf> Hello, in my new job I have to use svn for revision control. Being very fond of bzr I have been thinking of using bzr-svn to interact with the subversion repository.
[21:01] <alf> I am whether this can cause any problems for other using the svn repository (through normal svn)?
[21:01] <alf> + wondering
[21:02] <alf> eg the file/revision properties that bzr-svn uses
[21:03] <beuno> alf, I don't think so, I know many people who use bzr-svn to interact with svn at work
[21:06] <andresj> hello, whats the difference between `mkdir one; cd one; bzr init .; bzr pull /some/path;` and `mkdir two; cd two; bzr branch /some/path .`
[21:06] <andresj> ?
[21:07] <alf> beuno: Well, I am going to give it a try and hope for the best!
[21:08] <alf> Is there a way for bzr-svn to record merges in logs?
[21:09] <alf> I mean, to also include the logs of the merged revisions in the svn log entry
[21:10] <beuno> alf, I don't really know, i haven't used it myself
[21:10] <james_w> andresj: doesn't the second create two branches?
[21:11] <james_w> andresj: ah, misread, the second puts the branch in ./two/path/, the first in ./one/ I believe
[21:11] <james_w> hey beuno
[21:11] <lifeless> andresj: the second will probably error, as branch creates a branch
[21:12] <lifeless> andresj: other than that they are essentially identical
[21:12] <lifeless> andresj: the latter can be spelt 'bzr branch /some/path two'
[21:12] <james_w> hey lifeless
[21:12] <lifeless> hi james_w
[21:12] <lifeless> alf: apparently some svn servers have a commit hook that includes diffs to file properties; bzr-svn can create noise there, but thats all
[21:13] <andresj> lifeless: wait what about an error with the second one?  `bzr branch /some/path .` should make the current directory the branch
[21:13] <lifeless> andresj: 'mkdir .' -> fail
[21:13] <lifeless> andresj: 'bzr branch foo bar' does a mkdir bar
[21:14] <andresj> hum, really? oh but i see what you mean---so they basically do the same thing. thank you, lifeless :)
[21:14] <beuno> huya james_w!
[21:14] <lifeless> andresj: the major difference is that the format won't be preserved
[21:15] <andresj> hold on a second, please, lifeless
[21:15] <andresj> (stupid old router ;P)
[21:16] <andresj> ok im back :)
[21:16] <andresj> what format wont be preserved, lifeless?
[21:16] <lifeless> andresj: e.g. if /some/path is something non-default, like a loom, 'bzr branch' will preserve that, but doing a manual init won't.
[21:17] <andresj> hum... i see, i see---so ill be sure to branch instead of init, pull from now :P
[21:17] <lifeless> andresj: http://paste.ubuntu.com/121561/
[21:21] <andresj> lifeless: http://paste.ubuntu.com/121562/ ;P
[21:22] <lifeless> andresj: heh
[21:59] <igc> morning
[22:00] <mwhudson> hi igc
[22:01] <igc> hi mwhudson
[22:23] <lifeless> jml: when you get a chance, after work or so; subunit - new branch to review
[22:23] <jml> lifeless: ahh right.
[22:23] <jml> lifeless: so, in answer to your earlier question....
[22:23] <jml> lifeless: I'd expect subunit-filter to be a thing like grep that used higher-level subunit concepts, rather than regexen
[22:24] <jml> lifeless: and I don't have a clear idea of what subunit-ls would do -- discover tests in ... what?
[22:24] <ronny> subunit?
[22:25] <lifeless> jml: it outputs just their names
[22:25] <lifeless> jml: like lsdiff outputs the files altered in a patch
[22:25] <jml> ronny: https://launchpad.net/subunit
[22:26] <ronny> looks usefull
[22:26] <ronny> does the python child support things like nose?
[22:27] <lifeless> bug 332770
[22:28] <lifeless> ronny: the python child is a unittest.TestResult
[22:28] <ronny> oh, sad
[22:28] <lifeless> ronny: so anything that honours that protocol will work with subunit
[22:28] <ronny> i really dislike unittest tho
[22:28] <lifeless> nose is basically unittest, last I looked
[22:28] <lifeless> though they seem to be going slowly mad
[22:28] <ronny> well, it hides away the pain
[22:29] <ronny> lifeless: i could use a tool that can set up different envs with different versions of a tool
[22:30] <ronny> so i can run anyvc's unittests against all supported versions of hg, bzr, dulwich, subvertpy
[22:31] <lifeless> jml: does testtools have load_tests support yet? or scenarios?
[22:31] <jml> lifeless: spiv has a patch up for scenarios
[22:31] <lifeless> ronny: bzr has interface tests for this purpose; we write tests to an interface and parameterise the tests
[22:31] <jml> lifeless: I'm a bit suspicious of load_tests, partly due to ignorance.
[22:32] <ronny> lifeless: thats what i do in anyvc, too
[22:32] <spiv> jml: API xenophobia?
[22:32] <lifeless> jml: its my third attempt at that problem, I think its the right one
[22:32] <ronny> currently i run against one version of each tool
[22:32] <ronny> i'd prefer to be able to run against multiple versions
[22:33] <lifeless> jml: I'd be happy to discuss
[22:33] <lifeless> ronny: right, so test parameterisation setting python paths; and subunit to get a fresh interpreter for each, ftw
[22:33] <jml> lifeless: it's possible. everything else in testtools (IIRC) is things that have been used in more than one project.
[22:33] <jml> [modulo grammar]
[22:34] <jml> lifeless: but likewise, am happy to talk about it later.
[22:34] <lifeless> jml: load_tests is simply a hook for TestLoader, between implicit discovery and actual use.
[22:34] <ronny> lifeless: i'd like to have a way to pass the parameters as something like pkg_resource requirements or something, and setting up a custom virtualenv for each
[22:35] <lifeless> ronny: yes, that would be trivial glue on top
[22:35] <lifeless> the parameters would be in your scenario definitions
[22:36] <lifeless> your external test case proxies would turn those into virtualenv however you want to do that
[22:39] <ronny> lifeless: sounds nice
[22:39] <ronny> lifeless: hmm, the protocol seems confusing, does it have any base?
[22:42] <ronny> lifeless: got a bnf gramar or something like that?
[22:42] <lifeless> spiv: ping
[22:43] <lifeless> ronny: not really, it was designed to be primarily human readable
[22:43] <ronny> oh :(
[22:43] <lifeless> ronny: I can whip up a BNF at some point; its nearly a BNF anyhow in the README
[22:43] <spiv> lifeless: pong
[22:44] <lifeless> spiv: what is the mechanism by which pack-names is refreshed when the autopack rpc is used?
[22:44] <lifeless> spiv: streaming push needs the same thing
[22:44] <spiv> lifeless: bzrlib/smart/packrepository.py
[22:45] <spiv> lifeless: the verb just relies on _pack_collection.autopack() to DTRT
[22:45] <lifeless> spiv: I mean on the client
[22:45] <spiv> Oh, right
[22:45] <lifeless> self._real_repository - how does it see the new pack
[22:45] <lifeless> is there a 'refresh thyself' method I can call from RemoteSink ?
[22:45] <spiv> self._real_repository._pack_collection.reload_pack_names()
[22:46] <lifeless> I die a little every time
[22:46] <spiv> That line in remote.py is preceded by a comment saying that perhaps the automatic retry logic will make that unnecessary...
[22:47] <lifeless> spiv: it doesn't
[22:47] <lifeless> spiv: for streaming push
[22:49] <lifeless> spiv: because no file IO errors occur, we just have a new pack that the real repo does not know about
[22:49] <spiv> Ah, yeah.  Unless an autopack did occur, of course.
[22:50] <spiv> But not in the general case.
[22:51] <lifeless> :!./bzr --no-plugins selftest branch_implementations.*Remote
[22:51] <lifeless> passes
[22:51] <ronny> lifeless: another thing i dont get is that obsession with xunit
[22:51] <lifeless> ronny: reusable code is good
[22:52] <ronny> lifeless: but xunit isnt exactly nice in python
[22:53] <lifeless> unittest is somewhat fugly
[22:53] <lifeless> but that was barely even a transliteration of xUnit
[22:53] <lifeless> py.test makes my want to cry
[22:54] <ronny> 1:1 transliterations never end well :(
[22:54] <ronny> lifeless: dont ever support it
[22:54] <lifeless> doctest has caused enough grief that we should sue the author
[22:54] <lifeless> 'crimes against humanity'
[22:54] <ronny> these insane fuckers dont deserve support ;P
[22:54] <mwhudson> i think when it comes down to the ugly details of testing "real" code things like "xunit offends my sensibilities" go flying out of the window
[22:55] <ronny> py.lib and py.test are damn messed up
[22:55] <lifeless> spiv: so coordination call?
[22:55] <spiv> lifeless: sounds good
[22:56] <lifeless> skype or pots
[22:56] <spiv> either's fine with me
[22:56] <ronny> i wouldnt mind unittests so much if unittest keept the tests more readable and used pythonic patterns
[22:56] <ronny> eh unittest i mean
[22:57] <ronny> the problem is, it works, so we are stuck with it
[23:02] <santagada> I really enjoy py.test... but doctests drives me crazy
[23:03] <ronny> santagada: py.test is only fun till it breaks things
[23:03] <ronny> then it wil lbe impossible to debug it cause of the insane things in it
[23:03] <santagada> ronny: I only used it in pypy, so it never broke anything...
[23:04] <santagada> ronny: I got I little insane trying to learn how to write a plugin for it
[23:04] <santagada> but after you get the hang of it it is quite straightforward
[23:04] <santagada> I think the biggest problem is lack of real docs, about internals and all
[23:05] <ronny> i ditched it for nosetest
[23:05] <ronny> less magic more docs
[23:05] <ronny> lifeless: btw, how are the nose devs starting to go insane?
[23:05] <santagada> ronny: nosetest is cool, but less magic also mean less cool features
[23:05] <ronny> santagada: what do you think is missing?
[23:06] <ronny> the more magic is involved the harder debugging real breakages gets
[23:06] <santagada> specially when you assert something py.test has much more information about the variables involved
[23:06] <ronny> nosetest -d enables assert introspection
[23:06] <santagada> this is probably new
[23:06] <ronny> been there since ages
[23:07] <ronny> afair its also allmost ported to jython, ironpython and python3
[23:07] <santagada> either I didn't notice it or it doesn't work like py.test
[23:07] <ronny> it doesnt do weird magic onless you ask it to
[23:08] <santagada> ronny: have you tried the one from twisted?
[23:08] <santagada> trial I think
[23:09] <ronny> yeah, behaved weird, no idea if it was my fault
[23:09] <ronny> im kinda allergic to the crimes twisted generates
[23:09] <spiv> abentley: bundlebuggy
[23:09] <spiv> abentley: bundlebuggy is 502ing
[23:11] <abentley> spiv: restarted
[23:11] <ronny> santagada: im thinking about writing an own one later
[23:12] <ronny> lifeless: why is the stream like test: thelabel\nresult: thelabel [...]
[23:13] <ronny> wouldnt it be enough to just pass the results
[23:13] <mwhudson> ronny: you seem very opinionated :)
[23:13] <ronny> mwhudson: yeah
[23:13] <santagada> ronny: please don't do it... create a plugin for py.test or nose
[23:13] <ronny> most likely for nose
[23:13] <ronny> i'd like it to report to a dbus location
[23:14] <spiv> abentley: thanks!
[23:14] <santagada> see, something easy to do with py.test, probably the same with nose
[23:14] <santagada> gtg
[23:14] <ronny> lifeless: it would be nice if there was a way to track extra stuff like tracebacks or stdout/stderr for the tests
[23:16] <lifeless> ronny: the nose devs seem to be slowly adding py.test magic
[23:16] <lifeless> ronny: I should track it more closely, because thats as accurate and precise as I can be at the moment
[23:16] <lifeless> ronny: re: trial, trial is largely sane now thanks to jml
[23:17] <lifeless> ronny: re: the duplication, its to catch interrupted streams
[23:17] <lifeless> ronny: and hung tests
[23:17] <lifeless> start, finish catches hung tests
[23:18] <lifeless> start THING, finish THING -> catches interrupted tests (start FOO, start BAR, finish BAR, and similar)
[23:19] <lifeless> spiv: down to 63 calls for non-stacked
[23:19] <jml> lifeless: trial has been improved now by many people since I was actively working on it.
[23:19] <lifeless> jml: I credit you with unfucking it when it was at its worst
[23:19] <lifeless> jml: the rest is just folk understanding that it can be good
[23:20] <lifeless> jelmer: ping
[23:21] <ronny> lifeless: do you see any reasonable way to hook into getting extra data like timings, stdout/stderr produced by each test and others?
[23:23] <lifeless> ronny: sure, as long as its in the test comment area of the protocol its captured and put in the RemoteBacktrace
[23:23] <lifeless> timings -> use the time: tag
[23:23] <ronny> ah, k
[23:23] <ronny> i'll have to get more into it
[23:23] <lifeless> I need to add builtin generation of time: tags in the python client
[23:23] <lifeless> for now its just defined in the protocol, for folk doing benchmark work
[23:24] <lifeless> ronny: one of my main uses today is:
[23:24] <lifeless> bzr selftest --subunit > tests.log
[23:24] <ronny> lifeless: btw, why do you leave many ways to spell some things like test vs testing?
[23:24] <lifeless> subunit-filter < tests.log | subunit-ls > failing.list
[23:25] <lifeless> bzr selftest --load-list failing.list
[23:25] <lifeless> and loop
[23:25] <lifeless> (with hacking in the middle)
[23:25] <ronny> woot
[23:25] <lifeless> only loads tests that failed the previous time around
[23:26] <lifeless> ronny: test|testing|etc etc - generous in what you accept, strict in what you emit :)
[23:26] <lifeless> ronny: some folk are funny about what they want to see
[23:28] <ronny> hmm, i wonder if there is a reasonable way to deal with generator-tests
[23:28] <lifeless> do you mean factories that create many tests?
[23:28] <ronny> yeah
[23:29] <ronny> their test id's are a bit messy in nose
[23:29] <lifeless> for subunit it doesn't care - it doesn't require unique ids
[23:29] <lifeless> but its the same really as bzr's test scenarios
[23:29] <lifeless> have you seen our ids ?
[23:29] <ronny> no
[23:29] <ronny> i guess you guys just rerun the full generator?
[23:30] <lifeless> test_merge_sorted_range_stop_include_forward(BzrBranchFormat5)
[23:30] <ronny> (or do you have a way to figure what part to rerun)
[23:30] <lifeless> for loading tests do you mean ?
[23:30] <ronny> yeah
[23:30] <lifeless> we generate all the scenarios and filter
[23:32] <spiv> It'd be possible to do better than that with the load_tests hook, if we cared.
[23:32] <spiv> (I think)
[23:33] <ronny> ie skip scenario generators that completely passed?
[23:33] <lifeless> ronny: pass the filter into the generator
[23:33] <spiv> Right.
[23:34] <lifeless> spiv: be difficult to balance filter generalism with actual skipping though
[23:34] <spiv> At the moment generating a scenario is sufficiently cheap that we don't care.
[23:34] <spiv> lifeless: yeah
[23:34] <spiv> lifeless: see also "if we cared" ;)
[23:34] <ronny> wouldnt i have to manage filtering myself then?
[23:35] <spiv> Well, I'd imagine we'd provide filtering by default in our TestScenarioApplier or whatever its called.
[23:35] <lifeless> ronny: you could ignore the parameter if you didn't care
[23:35] <lifeless> myself, I think the current solution is simple and sane
[23:35]  * spiv agrees with lifeless
[23:39] <ronny> lifeless: are there any conventions for the result metadata?
[23:39] <ronny> (ie the comment block)
[23:39] <ronny> just want to know it it would make sense to even try parsing
[23:40] <lifeless> ronny: the python client writes the stacktrace in a way that can be reconstituted
[23:40] <lifeless> ronny: but other languages may not - e.g. the C client could just 'SEGFAULT' :P
[23:40] <lifeless> spiv: heh:     self.assertEqual(1, autopack_calls + streaming_calls)
[23:40] <lifeless> AssertionError: not equal:
[23:40] <lifeless> a = 1
[23:40] <lifeless> b = 4
[23:40] <lifeless> spiv: yay for tests eh what
[23:41] <ronny> hmm
[23:41] <spiv> lifeless: :)
[23:41] <ronny> i really wish things like self.assertEqual(a,b) would go away for assert a==b
[23:42] <lifeless> ronny: I like my tests to work with pyo files :)
[23:45] <ronny> lifeless: i kinda hate that optimazion - also - who the heck tests that way (bzr selftests are an exception thi)
[23:46] <lifeless> spiv: I want remember_remote_is_after()
[23:47] <lifeless> ronny: it is an odd optimisation :P
[23:48] <spiv> ronny: not all assertions are about equality, though...
[23:49] <spiv> lifeless: (not that I doubt you do want that) what for?
[23:50] <spiv> lifeless: the existing infrastructure for coping with different client/server versions is definitely a bit too simple.  At least it isn't a bit too complex, though ;)
[23:50] <ronny> spiv: i dont see any reason why most of those self.assertFoo couldnt go away for just assert
[23:51] <lifeless> spiv: after I know that streaming push works
[23:51] <lifeless> spiv: or perhaps medium.verb_exists(verb)
[23:51] <spiv> ronny: grep for "def assert" in bzrlib/tests sometime
[23:52] <spiv> ronny: the base assertion methods on TestCase aren't so interesting
[23:52] <lifeless> spiv: 60 and 85 now
[23:52] <lifeless> spiv: bzr search -s assert
[23:53] <lifeless> spiv: much more useful :)
[23:53] <spiv> ronny: it's the domain-specific ones that any sizeable project starts growing that really interesting.
[23:55] <jml> (and actually, assert methods are kind of lame)
[23:55] <ronny> spiv: the ones i have seen so far use only self.assertEqual
[23:55] <ronny> hmm
[23:56] <lifeless> jml: I'm thinking of dropping subunit.RemotedTestCase from the id of RemotedTestCase's
[23:56] <lifeless> jml: thoughts
[23:56] <jml> lifeless: I manually drop it in Tribunal
[23:59] <lifeless> jml: ok, I'll nuke it tonight
[23:59] <jml> lifeless: cool.