| 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:58 |
| 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. | 00:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| lifeless | what split does is essentially bzr branch your depot, delete everything except the named directory (e.g. A) and then commit | 01:03 |
| KhaZ | And there's no way to obliterate history in bzr? | 01:04 |
| lifeless | not directly no | 01:04 |
| 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:05 |
| lifeless | the fast-export approach soundslike its the closest fit to what you're asking for | 01:06 |
| lifeless | (its a bzr plugin) | 01:06 |
| KhaZ | lifeless: Ah, neat. I'll have to check that out. | 01:07 |
| KhaZ | Thanks for spitballin' with me lifeless . | 01:07 |
| lifeless | np | 01:08 |
| lifeless | jml: around? | 01:30 |
| === thumper_laptop is now known as thumper | ||
| jml | lifeless: am now. | 04:25 |
| lifeless | what would you like to see in subunit before an announcement to tip | 04:28 |
| lifeless | or alternatively | 04:28 |
| lifeless | what things are 'it really should have' for subunit that it doesn't | 04:29 |
| lifeless | jml: ^ | 04:37 |
| jml | lifeless: a web page with some friendly guff + documentation. | 04:38 |
| jml | lifeless: not sure what else | 04:39 |
| 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:40 |
| lifeless | ah, tell it to use a subunit TestResult? | 04:41 |
| lifeless | https://edge.launchpad.net/subunit isn't sufficient guff? | 04:41 |
| lifeless | bug 332770 | 04:46 |
| ubottu | Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770 | 04:46 |
| lifeless | jml: with pycon coming up it seems worth trying to get a 'release' done | 04:52 |
| jml | lifeless: I think a more friendly "how to" style document would be a good idea | 04:54 |
| lifeless | jml: do you have any interest in writing it ? | 04:55 |
| jml | lifeless: yes. | 04:56 |
| lifeless | cool | 04:57 |
| jml | lifeless: but before pycon? ... we'll see. | 04:57 |
| === davidstrauss_ is now known as davidstrauss | ||
| lifeless | jml: what would you expect the commands 'subunit-filter' and 'subunit-ls' to do | 06:58 |
| lifeless | abentley: the --no- option stuff - was that exposing something optparse does anyway, or custom for bzr? | 07:31 |
| === scode_ is now known as scode | ||
| 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:26 |
| 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:27 |
| 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:29 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| lifeless | scode: so you can also | 09:41 |
| lifeless | merge --pull | 09:41 |
| lifeless | (or just pull) | 09:41 |
| 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:42 |
| 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:43 |
| scode | Though I guess it doesn't look too nice if you ever want to check out the branching history. | 09:44 |
| scode | I suppose what I really want in this case is simply darcs semantics. | 09:45 |
| lifeless | scode: yes, darcs semantics are quite nice in some respects | 09:59 |
| lifeless | jml: if you're around, I have a subunit-ls too; pondering same-branch/different-branch | 10:02 |
| === beaumonta is now known as abeaumont | ||
| nabob | hi | 13:02 |
| abentley | lifeless: The hidden, automatic nature of the no- options is custom. | 13:33 |
| === mark1 is now known as markh | ||
| 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:47 |
| james_w | it's not clear | 17:49 |
| 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:50 |
| 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 | 17:51 |
| === abadger_afk is now known as abadger1999 | ||
| Peng_ | Loggerhead trunk can now serve bzr, and gives the URL for it. | 18:55 |
| === eaumontab is now known as abeaumont | ||
| 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:00 |
| alf | I am whether this can cause any problems for other using the svn repository (through normal svn)? | 21:01 |
| alf | + wondering | 21:01 |
| alf | eg the file/revision properties that bzr-svn uses | 21:02 |
| beuno | alf, I don't think so, I know many people who use bzr-svn to interact with svn at work | 21:03 |
| 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:06 |
| alf | beuno: Well, I am going to give it a try and hope for the best! | 21:07 |
| alf | Is there a way for bzr-svn to record merges in logs? | 21:08 |
| alf | I mean, to also include the logs of the merged revisions in the svn log entry | 21:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| andresj | hold on a second, please, lifeless | 21:15 |
| andresj | (stupid old router ;P) | 21:15 |
| 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:16 |
| 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:17 |
| andresj | lifeless: http://paste.ubuntu.com/121562/ ;P | 21:21 |
| lifeless | andresj: heh | 21:22 |
| igc | morning | 21:59 |
| mwhudson | hi igc | 22:00 |
| igc | hi mwhudson | 22:01 |
| 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:23 |
| 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:24 |
| 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:25 |
| ronny | looks usefull | 22:26 |
| ronny | does the python child support things like nose? | 22:26 |
| lifeless | bug 332770 | 22:27 |
| ubottu | Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770 | 22:27 |
| 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:28 |
| ronny | lifeless: i could use a tool that can set up different envs with different versions of a tool | 22:29 |
| ronny | so i can run anyvc's unittests against all supported versions of hg, bzr, dulwich, subvertpy | 22:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| lifeless | ronny: yes, that would be trivial glue on top | 22:35 |
| lifeless | the parameters would be in your scenario definitions | 22:35 |
| lifeless | your external test case proxies would turn those into virtualenv however you want to do that | 22:36 |
| ronny | lifeless: sounds nice | 22:39 |
| ronny | lifeless: hmm, the protocol seems confusing, does it have any base? | 22:39 |
| ronny | lifeless: got a bnf gramar or something like that? | 22:42 |
| lifeless | spiv: ping | 22:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| === Daviey_ is now known as Daviey | ||
| 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:46 |
| lifeless | spiv: it doesn't | 22:47 |
| lifeless | spiv: for streaming push | 22:47 |
| 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:49 |
| spiv | But not in the general case. | 22:50 |
| 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:51 |
| ronny | lifeless: but xunit isnt exactly nice in python | 22:52 |
| 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:53 |
| 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:54 |
| ronny | py.lib and py.test are damn messed up | 22:55 |
| lifeless | spiv: so coordination call? | 22:55 |
| spiv | lifeless: sounds good | 22:55 |
| 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:56 |
| ronny | the problem is, it works, so we are stuck with it | 22:57 |
| santagada | I really enjoy py.test... but doctests drives me crazy | 23:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| santagada | ronny: have you tried the one from twisted? | 23:08 |
| santagada | trial I think | 23:08 |
| 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:09 |
| abentley | spiv: restarted | 23:11 |
| ronny | santagada: im thinking about writing an own one later | 23:11 |
| ronny | lifeless: why is the stream like test: thelabel\nresult: thelabel [...] | 23:12 |
| 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:13 |
| 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:14 |
| 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:16 |
| 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:17 |
| lifeless | start THING, finish THING -> catches interrupted tests (start FOO, start BAR, finish BAR, and similar) | 23:18 |
| 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:19 |
| lifeless | jelmer: ping | 23:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| spiv | It'd be possible to do better than that with the load_tests hook, if we cared. | 23:32 |
| spiv | (I think) | 23:32 |
| ronny | ie skip scenario generators that completely passed? | 23:33 |
| lifeless | ronny: pass the filter into the generator | 23:33 |
| spiv | Right. | 23:33 |
| 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:34 |
| 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:35 | |
| 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:39 |
| 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:40 |
| 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:41 |
| lifeless | ronny: I like my tests to work with pyo files :) | 23:42 |
| ronny | lifeless: i kinda hate that optimazion - also - who the heck tests that way (bzr selftests are an exception thi) | 23:45 |
| lifeless | spiv: I want remember_remote_is_after() | 23:46 |
| lifeless | ronny: it is an odd optimisation :P | 23:47 |
| spiv | ronny: not all assertions are about equality, though... | 23:48 |
| spiv | lifeless: (not that I doubt you do want that) what for? | 23:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| lifeless | jml: ok, I'll nuke it tonight | 23:59 |
| jml | lifeless: cool. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!