| spiv | Oh, hmm, and I should probably take a look at https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/674091 | 00:07 |
|---|---|---|
| ubot5 | Launchpad bug 674091 in bzr (Ubuntu) "bzr crashed with ErrorFromSmartServer (We are missing inventories for revisions) (affected: 1, heat: 12)" [Undecided,New] | 00:07 |
| mkanat_ | Is it OK for me to fix trivial bugs by committing directly to an LP branch of loggerhead, or should I still do a merge proposal? | 00:09 |
| === mkanat_ is now known as mkanat | ||
| mkanat | Just going to do it. | 00:10 |
| nule | hi all | 02:37 |
| nule | quick question if anybody has a second | 02:37 |
| nule | i'm converting a number of open-source projects to bzr from svn and I wondered if there was a way using svn-import to include a number of projects into what should really be one repo - they're currently all seperate svn repos | 02:38 |
| nule | seems like it always inits a new bzr repo with the import | 02:39 |
| nule | stepping away for a few, but i'll hang out for a bit if anybody has some ideas - might just not worry about history in the new repo | 02:42 |
| nule | thanks | 02:42 |
| mwhudson | nule: repositories are boring in some sense in bzr; they're just bags of revisions, an optimization to avoid storing the same revision more than once | 02:44 |
| mwhudson | nule: as branches from separate repos won't share revisions, there's no real point to putting them in the same repo | 02:45 |
| mwhudson | (nothing stopping you doing that after the fact) | 02:45 |
| maxb | nule: It would be interesting to have the specific example of the projects that you want to combine, and would make it easier to offer advice | 02:48 |
| nule | and i'm back, thanks mwhudson and maxb | 03:22 |
| nule | I have a bunch of libraries and utilities that depend on those libraries | 03:24 |
| nule | right now building them depends on having them checked out relative to one another for the paths to work, and since they're not that huge i though it'd make more sense to essentially have them all in one big project | 03:25 |
| nule | here are two of the actual projects: https://svn.thot.us/svn/nule.org_LightHl7Lib/ and https://svn.thot.us/svn/nule.org_IntegrateClientLib/ | 03:25 |
| maxb | nule: OK, the important question you need to ask yourself is: Does it make sense for the combined tree to ALWAYS be checked out, branched, tagged, released as a single unit from now on? | 03:25 |
| maxb | If the answer is no, you don't want to meld them into a single bzr branch | 03:26 |
| mwhudson | what's the plugin for this sort of thing, bzr-scmproj? | 03:27 |
| nule | good advice, maxb, my thoughts are that it's not that "expensive" to check them all out (they're not huge) and then I could include an ant and properties file in the root that would vastly simplify building and bundling new builds for distribution | 03:27 |
| nule | i'm using bzr-svn for this, mwhudson | 03:27 |
| spiv | nule: they aren't mutually exclusive plugins :) | 03:29 |
| maxb | nule: bzr-scmproj is a plugin that has something to do with aggregating multiple bzr branches into a combined work area | 03:29 |
| nule | spiv: i had considered that after i hit enter :) | 03:30 |
| fullermd | nule: So, the nice thing about a VCS is the ability to undo stuff later. But one thing that's very difficult to undo is putting things together in a single branch; breaking them out separate later on requires messy and heroic measures. | 03:30 |
| maxb | nule: OK, different question - does it make sense for the entire tree to have a single version number when you release it - *always* ? Do your projects currently have separately managed version numbers? If so, are you prepared to change that? | 03:31 |
| nule | those are both good points | 03:32 |
| maxb | If you feel that it is meaningful to sometimes release some subset of projects separately from the whole tree, that's a good indication that a single monolithic bzr branch is the wrong approach | 03:32 |
| fullermd | This is a place where bzr-think and svn-think differ; what things you really _need_ to decide before you start. | 03:32 |
| maxb | Instead, there are things like bzr-scmproj (and, I think other related plugins) that can assist with working on a forest of branches in a specific layout, instead of making a single branch | 03:33 |
| nule | i will definitely investigate bzr-scmproj to see if it solves my most pressing needs | 03:33 |
| maxb | Unfortunately, I have no experience with these forest of branches plugins, so I cannot advise on them | 03:33 |
| nule | right now i drag my feet on new releases because making sure I'm releasing everything with a consistent (and working) set of libraries is very timeconsuming | 03:34 |
| nule | in that sense having a unified build number would be lovely | 03:34 |
| nule | but you're right that while I need to rebuild * if the lowest library changes, I don't if the highest application changes | 03:34 |
| fullermd | One good signpost is that if those libraries are ever used (or ever to be used) by something other than this project, that's a good sign they should be separate. | 03:34 |
| nule | definitely good things to think about, there's no real reason I suppose that i can't have a separate build project at the same level as the others to facilitate my release process | 03:35 |
| nule | "process", more like mayhem right now | 03:36 |
| fullermd | Another point is that what I said above about _splitting_ branches doesn't apply to _combining_ branches. You can combine two branches into one easily. | 03:36 |
| fullermd | Just once they're together, breaking them apart is very difficult. | 03:36 |
| nule | i definitely see that, fullermd, you're going to lose history no matter what at that point | 03:37 |
| nule | good stuff to think about, all, appreciate the advice | 03:37 |
| fullermd | So you can start with them separate, and if you decide later on they should all be jumbled together, it's just a few quick, easy, history-preserving operations to roll them up. | 03:38 |
| poolie | jam, don't suppose you're still up? | 03:53 |
| jam | poolie: indeed I am | 03:53 |
| === dash_ is now known as dash | ||
| jdobrien | I accidentially deleted a directory which had a lot of edited files. How can I recover the directory without reverting all the changes I made? | 06:12 |
| poolie | a lot of uncommitted edits? | 06:12 |
| poolie | you probably need to look at using an OS-level undelete tool | 06:13 |
| jdobrien | poolie, yes ...refactoring | 06:13 |
| poolie | sorry, bzr won't have had a chance to store the files if you don't commit them | 06:13 |
| poolie | there is discussion of 'bzr rm' etc optionally moving things to a trash directory, but we don't do that at the moment | 06:14 |
| poolie | i have rdiff-backup setup to run every couple of hours :/ | 06:14 |
| jdobrien | ok | 06:14 |
| jdobrien | i got lucky | 06:17 |
| spiv | Well, 'bzr rm' by default will backup files that changed since the last commit to *.~1~ or whatever, so bzr itself is pretty safe by default. | 06:17 |
| jdobrien | i didn't bzr rm | 06:17 |
| spiv | But there's not much bzr can do about other tools deleting files. | 06:17 |
| jdobrien | yeah...fortunately this tool let me undo it | 06:18 |
| jdobrien | it was a silly mouse slip | 06:18 |
| spiv | That is fortunate. | 06:18 |
| jdobrien | yes | 06:18 |
| spiv | It's so much nicer using tools that let you undo mistakes. | 06:19 |
| jdobrien | i can't believe i made all these edits without a commit..i usually am really good about that | 06:20 |
| spiv | jdobrien: no-one is perfect :) | 06:21 |
| jdobrien | especially after 1am | 06:22 |
| spiv | Hehe. | 06:22 |
| jdobrien | bzr commit ... and bed | 06:22 |
| jdobrien | thx all | 06:22 |
| spiv | Wow ControlDir.sprout is ugly. After several rounds of refactoring it in this branch it it still alarmingly long and complex. | 06:43 |
| spiv | Hmm, I'm getting failures in bb.test_outside_wt with trunk. | 07:03 |
| spiv | But it's 6pm Friday, so I guess I'll just file a bug instead of figure it out :/ | 07:04 |
| vila | hi all | 07:05 |
| vila | spiv: which file between bb and test_outside ? | 07:06 |
| vila | oh, it *is* a file 8-) | 07:06 |
| spiv | vila: https://bugs.launchpad.net/bzr/+bug/674373 | 07:06 |
| ubot5 | Launchpad bug 674373 in Bazaar "test_outside_wt failures on trunk (affected: 1, heat: 6)" [Critical,Confirmed] | 07:06 |
| vila | on a pristine trunk ??? wow | 07:07 |
| spiv | vila: the good news about that bug for me is that it's not the patch I'm working on that is breaking the test suite ;) | 07:07 |
| spiv | vila: yeah, hence why I jumped straight for Critical | 07:08 |
| vila | indeed | 07:08 |
| vila | checking locally | 07:08 |
| spiv | Hopefully nice and shallow. | 07:08 |
| vila | wild guess: you're sure you didn't create a repo in /tmp by some weird side-effect ? | 07:09 |
| spiv | Still occurs with total --no-plugins | 07:09 |
| spiv | vila: it's possible! | 07:09 |
| spiv | Hey look at that. | 07:09 |
| spiv | vila: well done, that was it | 07:09 |
| vila | pfew, good :) | 07:10 |
| spiv | vila: it would be good to isolate the test suite from that sort of strange environment :) | 07:10 |
| spiv | I'll update the bug | 07:10 |
| vila | spiv: like... by switching to in-memory file systems ? :-D | 07:10 |
| spiv | vila: well, the usual TestCaseInTempDir would probably do in this case. | 07:11 |
| spiv | But I haven't looked closely, being post 6pm Friday :) | 07:12 |
| vila | spiv: well, despite having a safety net, there will always be tests that want to check that they don't find a repo up in the hierarchy, which we can't isolate properly by definition | 07:13 |
| vila | well, "can't" because we use an external resource which is the '/' filesystem | 07:13 |
| spiv | vila: the empty unshared bzr repo created by InTempDir takes care of that | 07:13 |
| spiv | But there may be something special about this test and / | 07:14 |
| spiv | Anyway, EOD for me. | 07:14 |
| vila | spiv: nope, it *is* a repo, some tests want no repo at all | 07:14 |
| vila | spiv: yeah, enjoy your week-end | 07:14 |
| poolie | hi there vila, how are things with you? | 07:14 |
| poolie | i might finish up too | 07:14 |
| poolie | barely any code this week :/ | 07:14 |
| vila | spiv: and to peace your mind: full test suite pass here | 07:14 |
| spiv | vila: at worst it could be a feature test | 07:14 |
| spiv | vila: self.requireFeature(NoRepoBetweenMeAndRoot) ;) | 07:15 |
| fullermd | Just start out the test with `rm -rf /`... | 07:15 |
| vila | poolie: fine, I'm becoming impatient to have an updated testtools on pqm to clear up mgz patches that are in the active queue for far too long :-/ | 07:15 |
| vila | spiv: sure, they will always be skipped, no failures ;) | 07:16 |
| vila | fullermd: really ? Let me try that.... | 07:16 |
| fullermd | Mwahaha. My plan progresse.... bah. | 07:16 |
| vila | :D | 07:16 |
| vila | poolie: so, things are fine :) | 07:17 |
| spiv | Ok, really done now. Hopefully I'll finish slaying the sprout monster on Monday! | 07:17 |
| vila | poolie: a couple of pending mps waiting for reviews but I still have more to work on | 07:18 |
| poolie | spiv, feel free to clean up sprout too :) | 07:19 |
| poolie | i'm meant to be pilot next week | 07:20 |
| vila | poolie: there is an interesting discussion about configs in https://code.edge.launchpad.net/~doxxx/bzr/mergetools/+merge/38663 that should help me progress by identifying the next easy steps | 07:20 |
| vila | poolie: well, easy is a bit optimistic but manageable steps at least | 07:20 |
| spiv | poolie: yes, that's basically where I've spent a large chunk of today | 07:20 |
| poolie | i skimmed the mail very briefly | 07:20 |
| poolie | \o/ | 07:20 |
| poolie | i'll try to look at that next | 07:21 |
| vila | 1) interpolation with {option} syntax | 07:21 |
| vila | 2) sections in bazaar.conf | 07:21 |
| poolie | ok | 07:22 |
| poolie | actually s is home so i might go now... | 07:22 |
| vila | but first I should submit my braindump for feedback, I think I'm pretty close to a definition that addresses the main compatibility issues I was fighting with | 07:22 |
| vila | ok | 07:22 |
| vila | poolie: let's try to talk a bit on monday | 07:22 |
| poolie | ok, good night | 07:23 |
| === frakturfreak is now known as frakturfreak[AKF | ||
| === frakturfreak[AKF is now known as frakturfreak|AKF | ||
| vila | AFK maybe ? :) | 08:32 |
| === muffinre1earch is now known as muffinresearch | ||
| === zyga is now known as zyga-food | ||
| === beuno_ is now known as beuno | ||
| === zyga-food is now known as zyga | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| mgz | vila: sorry, the ol' unpushed to lp problem | 15:21 |
| vila | mgz: hey ! | 15:21 |
| vila | mgz: for the uncollected tests ? | 15:21 |
| mgz | yup, those failures. | 15:22 |
| vila | mgz: ok, pulling and retry time it is then ! | 15:22 |
| mgz | I left the tip on lp in a borked state, will add my local changes. | 15:22 |
| vila | I'm sorry for your other patches :( I keep pinging losas to no avail :( | 15:23 |
| vila | hmm, branches diverged | 15:23 |
| mgz | hm, just a sec, need to commit some local changes too | 15:23 |
| vila | ok, ping when it's done | 15:24 |
| mgz | was trying to find a spare evening to try out a version along the lines of what spiv was asking for | 15:26 |
| mgz | okay, push done | 15:26 |
| === Meths_ is now known as Meths | ||
| vila | grr, stupid setup, I know it's based lp:bzr, I do that for be able to review with -rsubmit:, but when I then ask for pull-v ,just FDWIM and pull from the mp branch ! | 15:28 |
| vila | interesting, far more typos when I'm angry... | 15:28 |
| vila | ooops, did I say that publicly ? :D | 15:28 |
| fullermd | Rellay? I hand't noticed... | 15:28 |
| mgz | you're a talented snarker, fullermd. | 15:29 |
| vila | . o O (That's it ! He put *me* in his triggers ! They say I'm paranoid...) | 15:30 |
| fullermd | I gotta stick with my strengths... | 15:30 |
| fullermd | They say? Who say? Are they watching you? How do they know that?! | 15:30 |
| vila | . o O (And why did I put mgz's mp into WIP, where is it now ??) | 15:30 |
| mgz | https://code.launchpad.net/~gz/bzr/cleanup_testcases_by_collection_613247/+merge/38999 | 15:31 |
| vila | ha thanks :) Did *you* put it back to NeedsReview or should I blame... fullermd ! | 15:32 |
| fullermd | Me? I couldn't possibly have done it. I was busy robbing a bank when that happ... wait. Wrong alibi... | 15:33 |
| vila | *MY* bank ! | 15:33 |
| fullermd | Oh. That would explain why I didn't get anything out of 'em... | 15:33 |
| mgz | you never marked it WIP by my email log. | 15:33 |
| vila | mgz: ha, that should explain it then :) | 15:33 |
| mgz | which is probably a good thing, doing the new-giant-diff-by-email too often gets tiring on the thread | 15:34 |
| vila | still a lot of uncollected | 15:34 |
| mgz | I've lost all track of Gordon's mergetools branch | 15:34 |
| vila | trying --parallel first to see | 15:34 |
| vila | mgz: I convinced him to split it up to ease review | 15:35 |
| mgz | lots as in thousands -> update testtools, lots as in hundreds -> list please | 15:35 |
| vila | 5000 so far, checking testtools | 15:35 |
| mgz | there are various tests that don't run or run differently on this box, and I've not tried it on my nix one as it'd probably take years to complete a full test run | 15:35 |
| vila | revno 129 missing only one from jml about deferred tests, unrelated right ? | 15:36 |
| vila | ha damn, I should retry the subset first | 15:37 |
| vila | --parallel almost finished | 15:37 |
| vila | ok, so success for the full run, but all tests uncollected | 15:38 |
| vila | well I didn't check the 26748 ones but my buffer contains 26780 lines so that should be closed | 15:39 |
| vila | s/d// | 15:39 |
| vila | s/d$// | 15:39 |
| vila | grep -n Uncollected test| wc -l => 26751 :) | 15:40 |
| mgz | harumph. | 15:42 |
| vila | mgz: could *you* try to upgrade testtools ? | 15:42 |
| vila | . o O (If I'm right he won't be happy :-/) | 15:42 |
| mgz | I did after Robert merged that change, and didn't think I saw anything else dangerous go past, but will do. | 15:43 |
| mgz | nope, looks good here. will just test that it's not related to the command line given. | 15:45 |
| mgz | hm, some new doctest progress bar junk, but fine otherwise. | 15:46 |
| vila | less uncollected test cases with --parallel | 15:46 |
| vila | ~100/600 so far | 15:47 |
| mgz | it sounds to me a lot like the testtools patch isn't there for whatever reason | 15:47 |
| vila | :-( | 15:48 |
| mgz | I'll try this on my nix box to rule that out as an issue thoug | 15:49 |
| vila | I just checked I'm using trunk | 15:49 |
| vila | testtools trunk that is | 15:49 |
| vila | ~300/4000 | 15:50 |
| breakfast | hi all | 15:53 |
| breakfast | i've been trying to figure out how to make "bzr diff --using=diff" the default behavior, so that when i call "bzr diff" without --using it still does that by default. can you point me to a resource that explains how to do that? | 15:54 |
| mgz | `bzr help alias` | 15:55 |
| breakfast | thank you | 15:56 |
| vila | ~1200/11000 | 15:56 |
| mgz | that's sounding more possible. hopefully this'll finish branching in a sec and I can try here | 15:57 |
| mgz | seems to be taking about a minute for each hundred at 7000/13750 though... | 16:00 |
| vila | mgz: huh, what are you branching ? | 16:00 |
| mgz | bzr. | 16:00 |
| vila | oh, on an out-of-date system you mean / | 16:01 |
| vila | ? | 16:01 |
| vila | (which implies an old bzr too of course) | 16:01 |
| vila | mgz: download a recent one first :D | 16:02 |
| * vila duck | 16:02 | |
| mgz | should be reasonably recent, no way I'd use the lenny bzr. | 16:02 |
| mgz | but it's a very memory-constrained box. | 16:02 |
| mgz | probably should have used smart server this time, but I couldn't branch bzr *at all* initially with the smart server. | 16:03 |
| mgz | as this is just updating the shared repo, it probably wouldn't die. | 16:03 |
| vila | mgz: no way to branch from your local box ? | 16:03 |
| mgz | well, scp. | 16:03 |
| vila | if you're cautious and clean up afterwards, that should work | 16:04 |
| vila | oh, you meant wt or branch ? | 16:04 |
| mgz | I'm trying to branch, but giving in and copying the wt is what I'd fall back to. | 16:05 |
| mgz | this is why I seldom try and run selftest on that box though :) | 16:06 |
| mgz | ooo, estimate jumped from 8500 to Done | 16:06 |
| mgz | will it actually finish? | 16:06 |
| mgz | go go little box. | 16:07 |
| vila | http://paste.ubuntu.com/530767/ | 16:07 |
| vila | so roughly 1800 uncollected tests | 16:07 |
| mgz | thanks! | 16:07 |
| mgz | hm... looks funky. | 16:07 |
| vila | as in ? | 16:08 |
| mgz | at a guess from the test names, one think that creates a cycle on a nix osutils unicode path | 16:08 |
| mgz | s/think/thing/ | 16:08 |
| vila | the bzrlib.tests.test_conflicts.TestResolveContentsConflict series don't involve unicode AFAIR | 16:09 |
| mgz | hmph, and I don't get these problems on my nix both. | 16:11 |
| mgz | *box. | 16:11 |
| vila | hmm, angry huh :) | 16:11 |
| mgz | so, theory #2: you have a plugin that breaks things. | 16:11 |
| vila | nope, BZR_PLUGIN_PATH in effect | 16:11 |
| vila | oh, loom ? | 16:11 |
| mgz | Uncollected test case: bzrlib.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_not_merged | 16:11 |
| mgz | right. | 16:12 |
| fullermd | Yeah, loom could warp things. | 16:12 |
| vila | nope | 16:12 |
| mgz | a weaving joke. | 16:12 |
| vila | .. passing above my head ;-/ | 16:12 |
| * fullermd will be here all week... don't forget to tip your waitress! | 16:12 | |
| vila | and same result with --no-plugins | 16:14 |
| mgz | what's different ;_; | 16:14 |
| mgz | 2.5.2 rather than 2.6.6 perhaps, but that's not much of a theory. | 16:14 |
| mgz | and 2.7 trunk works fine for me here, so would need to be some other factor as well. | 16:16 |
| mgz | 2 from 225 on my nix box so far, and you don't get either. | 16:19 |
| mgz | okay, thanks for your help vila, I'll poke around a bit and see what I can work out. | 16:19 |
| vila | -s bb.test_conflicts 8 tests 8 uncollected | 16:20 |
| vila | mgz: well, if you can't reproduce what will you do ? :-/ Any idea where *I* can poke ? | 16:22 |
| vila | ./bzr --no-plugins selftest -v -s bb.test_conflicts.TestConflict 3 test/ 3 uncollected | 16:22 |
| vila | but hmm, bb may not be the easiest | 16:22 |
| mgz | not only can I not repo your list, but I'm getting a different one. | 16:23 |
| mgz | none of bb.test_filesystem_cicp.TestMove gets collected on my nix run | 16:24 |
| vila | get uncollected you mean ? | 16:24 |
| mgz | right. | 16:25 |
| vila | do we have some tests in common ? | 16:25 |
| mgz | none so far. | 16:25 |
| mgz | oh, maybe three dpush ones? | 16:25 |
| * mgz checks | 16:25 | |
| mgz | I've got an unholy memory crawling function that helps a little, but basically just want to see what's pointing at the test when it should be dead. | 16:26 |
| mgz | sticking a breakpoint on the "Uncollected" print and using gc.get_referrers works | 16:27 |
| vila | get_referrers(case) ? | 16:28 |
| mgz | yup. | 16:28 |
| vila | http://paste.ubuntu.com/530772/ | 16:29 |
| mgz | it's often something unhelpful, like a frame, or a cell | 16:29 |
| mgz | ...or a dict | 16:31 |
| mgz | that's probably the: | 16:31 |
| vila | a frame is part of the calling stack right ? | 16:31 |
| mgz | <bound method TestConflicts._run_setup | 16:31 |
| mgz | ^right | 16:31 |
| mgz | but I should be able to repo bound method cycles... | 16:31 |
| * mgz looks at the case | 16:31 | |
| mgz | where's it coming from... | 16:33 |
| vila | grep says: testtools deferredruntest.py | 16:33 |
| vila | which should be totally unrelated to bzr >-/ | 16:34 |
| vila | ha ! | 16:36 |
| vila | deferredruntests.py depends on twisted which I bet you don't have installed | 16:36 |
| vila | mgz: python -c 'import twisted' | 16:37 |
| mgz | I do, but probably not the same version. | 16:37 |
| mgz | I've got 8.1.0 | 16:37 |
| vila | python -c 'from twisted.internet import defer | 16:38 |
| vila | from twisted.python import log | 16:38 |
| vila | from twisted.trial.unittest import _LogObserver | 16:38 |
| vila | ' | 16:38 |
| mgz | I'll put twisted on my nix box and see if I can then get your list. | 16:39 |
| vila | 10.1.0-2 for python-twisted | 16:39 |
| mgz | and look at the derferred stuff again, don't really see why bzr cases should be involved with that at all | 16:40 |
| mgz | ^thanks | 16:40 |
| vila | err python-twisted-bin | 16:40 |
| vila | me neither, but I chased your _run_setup pointer :) I have no idea if this was relevant ;) | 16:40 |
| mgz | wait wait, what was it you said earlier... | 16:41 |
| mgz | <vila> revno 129 missing only one from jml about deferred tests, unrelated right ? | 16:41 |
| * mgz checks that rev | 16:41 | |
| vila | of course that why I grepped testtools | 16:41 |
| mgz | ooo, and I just got per_branch collection failures. | 16:42 |
| mgz | so that's tractable at least. | 16:42 |
| vila | mgz: does that mean you can progress from there ? | 16:43 |
| mgz | okay, rev 130 may well fix some of those bb issues | 16:43 |
| mgz | and I've got some other things to look at too. | 16:44 |
| vila | -s bb.test_conflicts 8 uncollected still (I pulled it circa 17:14 | 16:45 |
| vila | i.e. 30 minutes ago | 16:45 |
| mgz | gra. | 16:45 |
| mgz | okay, was probably a red herring. twisted shouldn't be involved. | 16:50 |
| vila | looking at -s bt.test_version_info 4 uncollected out of 8 tests which seem to be the simplest of the lot | 16:57 |
| vila | gc_referrers mentions <bound method TestVersionInfo._run_test_method of <bzrlib.tests.test_version_info.TestVersionInfo.test_custom_version_text id=0x21edbd0>>, | 16:57 |
| vila | also from testtools :-/ | 16:58 |
| mgz | if there are also lots of frames like before, it's probably from a exception raised there. | 16:58 |
| mgz | I think I just need to look more closely at the recent testtools changes. | 16:58 |
| vila | ok | 16:58 |
| vila | Just a remark though, this itches again about innocent devs introducing cycles which.... sounds wrong | 16:59 |
| mgz | well, this is mostly test structural stuff which needs to be right, otherwise we risk leaking the world which is what broke me in the first place | 17:00 |
| mgz | but I agree that avoiding that without also burdening normal test contributors looks... challenging | 17:00 |
| vila | may be I still need to be lectured on the cycle topic... so, again, if you could send some failing tests like we tried to find some time ago, this could help me | 17:01 |
| mgz | testtools rev 129 I'm looking at now and could be problematic | 17:01 |
| vila | would you like me to revert to 0.9.7 instead ? (But that would still not explain why we get different failures) | 17:02 |
| mgz | if you want a vanilla cycle, the definition of bzrlib.errors.HookFailed.__init__ | 17:03 |
| mgz | ^thinking about it, I never updated the testtools on my nix box, just this one. | 17:04 |
| vila | mgz: 0.9.7 : some failures for test_vesion_info | 17:04 |
| vila | same | 17:04 |
| mgz | I've had failures in test_version_info for ever | 17:05 |
| vila | about uncollected ? | 17:05 |
| mgz | no, actual failures. | 17:05 |
| vila | meh | 17:05 |
| mgz | it looks outside its tempdir | 17:06 |
| vila | argh, use a real wt | 17:07 |
| mgz | are you on bt or bb for that? | 17:08 |
| vila | bt | 17:08 |
| vila | 10 tests 4 uncollected | 17:09 |
| mgz | hm, I'm clean on that, except on windows: | 17:09 |
| mgz | While running: bzrlib.tests.test_version_info.TestVersionInfo.test_python_version | 17:09 |
| mgz | Unable to remove testing dir ersionInfo.test_python_version | 17:09 |
| vila | ETOOMANYBUGS :( | 17:10 |
| mgz | yeah. | 17:10 |
| vila | so back to my earlier suggestion there I think: can you make this control conditional so we can land something that helps you ? | 17:11 |
| mgz | okay, looking at the source, I see potential problems | 17:11 |
| mgz | but... I'm not seeing the fallout | 17:11 |
| mgz | so, I'll fiddle. | 17:12 |
| mgz | but yeah, I could make this a -E flag for landing. | 17:12 |
| vila | ... one more on the pile waiting for testtools that is :-( | 17:13 |
| mgz | the other option is what spiv said and only doing once generic warning at the end, but this means it's more likely a change will totally break me later. | 17:13 |
| vila | nah, I didn't want to say that ! | 17:13 |
| vila | not at the end the week :-/ | 17:13 |
| vila | mgz: as opposed to still not un-breaking you until this lands you mean ? | 17:14 |
| mgz | well, with the flag it wouldn't even need the pqm update... if I version check in the new tests | 17:15 |
| vila | my problem with mps that took too long to land is that a lot of energy is lost without positive feedback for the submitter | 17:15 |
| mgz | yeah, and it's hard for all involved to hold the review in their head | 17:15 |
| vila | well, lp helps a lot there, I was thinking about keeping the patch up-to-date | 17:16 |
| vila | so, about HookFailed, the bactrace includes references to the test instance so storing it as an attribute creates the cycle right ? | 17:19 |
| vila | why not just clearing the backtrace and keeping only the class and the exception object then ? | 17:21 |
| mgz | yup. | 17:21 |
| mgz | right, that would be fine. | 17:21 |
| vila | mgz: trying to find alternate ways, not rebutting your approach here | 17:21 |
| mgz | in that particular case, not only is storing exc_info not needed, but the whole exception class could probably now be deleted | 17:21 |
| vila | at least that could be explained to all devs and *can* be avoided | 17:22 |
| mgz | I think these things are generally easy to avoid like that, the problem is just that if it's not the person writing the code that notices | 17:22 |
| vila | right, so we need some better cycle detection | 17:23 |
| mgz | and mostly it's obscure and shouldn't really matter, so just allowing the cycle would be an option... bar the fact that then a change that leaks thousands of tests goes unnoticed till my machine starts swapping | 17:23 |
| mgz | so, it's lots of total trivia, to be able to avoid the occasional thing that really hurts | 17:24 |
| vila | mgz, well, I could add a low-memory slave on babune or add a run with ulimit or something | 17:24 |
| mgz | would be nice to just ulimit the lot of ~200MB | 17:25 |
| vila | wow | 17:25 |
| mgz | the suite runs within ~100MB with this branch | 17:25 |
| vila | Wow | 17:25 |
| vila | my slaves are ~2GB to allow --parallel because I never had the time to check whether this was needed | 17:26 |
| vila | except freebsd that is 4G, but I blame fullermd here | 17:27 |
| * fullermd . o O ( One more blame, and I get a bingo! ) | 17:27 | |
| vila | truth is fullermd can also write some nice docs and do some nice reviews :D | 17:28 |
| mgz | parallel does complicate things a little, as python eats cows, but 200 * fork should be more than enough | 17:29 |
| fullermd | Ack! Be careful! You say things like that, next thing you know I'm a productive and useful member of the community. Then it's nothing but work, work, work, all the time :( | 17:29 |
| vila | hmm, and --parallel doesn't provide any means to let subprocess reports more data to the spawner like how much memory they consume | 17:29 |
| === oubiwann-away is now known as oubiwann | ||
| vila | mgz: hehe crossed on the wire, we're talking about two different things, giving Gs to slaves is not a problem, *checking* what is consumed is what I was after ;) | 17:30 |
| vila | fullermd: I'm not holding my breath (shouldn't count as a blame right ?) :-P | 17:31 |
| mgz | RUSAGE_CHILDREN should work. | 17:31 |
| mgz | and wait4. | 17:32 |
| vila | oh yeah | 17:32 |
| vila | especially if we don't care *too* much about being overly precise | 17:32 |
| vila | mgz: should we file a bug about implementing this for selftest ? | 17:33 |
| mgz | well, you have to hack subprocess is the pain | 17:34 |
| vila | mgz: or should we just keep discussing it ? (I'm about to EOD with a headache due to paint odors :-/) | 17:34 |
| vila | ordors ? smells ? | 17:35 |
| exarkun | fumes | 17:35 |
| vila | right odor is in my dict | 17:35 |
| mgz | exarkun has the common idiom | 17:35 |
| vila | fumes is likely to be more precise yeah | 17:35 |
| mgz | hm, wouldn't need hackage just for --parallel=fork | 17:36 |
| vila | exarkun: thks, appreciated (still along way to go to be fluent there :) | 17:36 |
| mgz | but do get outside before you expire from lack of oxygen vila, I'll continue playing | 17:36 |
| vila | ok | 17:36 |
| exarkun | vila: :) | 17:39 |
| vila | fullermd: my last remark was truly a joke to make you fail your bingo (just realized it could me mis-interpreted) | 17:46 |
| * vila really off | 17:46 | |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| GaryvdM | Hi mgz | 19:16 |
| mgz | hey GaryvdM | 19:16 |
| GaryvdM | Hay - I'm very excited about this. Take a look at http://198.54.202.195/ | 19:17 |
| lifeless | mgz: hi | 19:17 |
| GaryvdM | Hi lifeless | 19:17 |
| lifeless | GaryvdM: hi | 19:17 |
| mgz | will this be more exciting qlog-online stuff when it loads? | 19:18 |
| mgz | hey lifeless. | 19:18 |
| GaryvdM | mgz: yes - Is my router not setup correctly? | 19:18 |
| lifeless | mgz: curious what you think of the latest testtools changes | 19:18 |
| mgz | just doing tracert now... | 19:18 |
| mgz | hm, I arrive, but at wblv-ip-pcache-5-vif1.telkom-ipnet.co.za | 19:19 |
| GaryvdM | Ah - I think that is a proxy. Try http://41.242.164.81/ | 19:19 |
| mgz | I need to go over the last few revs still lifeless, but the raises matcher I'm a little concerned about | 19:20 |
| mgz | it's potentially good as it can solve the thing where you need the exception returned to check extra aspects of it | 19:21 |
| mgz | and also my expectError thing. | 19:22 |
| mgz | I think? With Not at least. | 19:22 |
| mgz | would still be confusing to spell. | 19:22 |
| mgz | that's pretty fancy Gary. I've got some wrapping-related spacing issues, but can possibly think of a cunning svg hack that'll make life easier there. | 19:25 |
| GaryvdM | Yes - I can figure out how to tell the svg to layout relative to the hight of the table row with out javascript | 19:26 |
| GaryvdM | *can't | 19:26 |
| GaryvdM | mgz: what hack? | 19:27 |
| mgz | well, you can stretch the image rather than setting a height in px, which would also make your nice circles oval | 19:27 |
| mgz | so you'd then need to do something else there as well. | 19:27 |
| mgz | ideally you'd not be breaking the lines up into bits, but laying a complete graph over the table would be complicated | 19:29 |
| GaryvdM | Yes | 19:29 |
| GaryvdM | Anyway - I'm quite excited about it :-) | 19:31 |
| GaryvdM | lifeless: Did you take a look? | 19:32 |
| lifeless | its shiny | 19:33 |
| lifeless | a little slow | 19:33 |
| GaryvdM | lifeless: Probably my bandwidth. | 19:33 |
| mgz | having js disabled makes life so much nicer :) | 19:34 |
| GaryvdM | mgz: I could have one svg element for then dot, and one for the lines, so that I can size then lines separately from then dots. But there is not a way to make a img/svg hight=100% in a table row :-( | 19:36 |
| GaryvdM | Without js | 19:36 |
| mgz | hm, I think I had one... | 19:36 |
| * mgz checks his note | 19:36 | |
| mgz | s | 19:36 |
| mgz | http://float.endofinternet.org/progress/shader.xml | 19:40 |
| mgz | browsers certainly have some issues, at any rate :) | 19:42 |
| GaryvdM | Hi mkanat. Take a look at http://41.242.164.81/ :-) | 19:51 |
| mkanat | GaryvdM: OH COOL!! | 19:52 |
| GaryvdM | :-) | 19:52 |
| mkanat | Wow that is awesome. | 19:52 |
| mkanat | GaryvdM: It doesn't do any work until I click on a +, right? | 19:54 |
| mkanat | GaryvdM: I mean, any extra work. | 19:54 |
| GaryvdM | Well - It has to load the whole graph on first load, but it caches it. | 19:56 |
| mkanat | GaryvdM: That's no different from what we do now, though, is it? | 19:56 |
| GaryvdM | To recalculate a new layout is very quick. | 19:56 |
| mkanat | GaryvdM: We can't have any performance or memory-use regressions in loggerhead right now--Launchpad won't be able to live through it. | 19:56 |
| GaryvdM | mkanat: Sure - I understand that. | 19:57 |
| mgz | lifeless: so, I don't like that assertRaises becomes assertThat + lambda, but apart from that it all seems reasonable. | 19:57 |
| mgz | really it's a python problem that it's hard to write declarative code prettily. | 19:58 |
| GaryvdM | mkanat: I do have alot of overlap of what is cached, and so I need to do some work there. | 19:58 |
| mgz | mostly assertThat seems like extra typing and worse error messages so far to me. | 19:58 |
| mkanat | GaryvdM: Okay. | 19:58 |
| mkanat | GaryvdM: But the UI looks very cool. | 19:58 |
| GaryvdM | mkanat: Are you using history_db on launchpad yet? | 19:58 |
| mkanat | GaryvdM: Not on Launchpad, no. | 19:58 |
| mkanat | GaryvdM: Are you using history_db for your work? | 19:59 |
| GaryvdM | mkanat: No - It dose not help much if you still have to load the whole graph. | 19:59 |
| mkanat | GaryvdM: I'm pretty sure that that's its purpose. | 20:00 |
| mkanat | GaryvdM: Is to cache the graph. | 20:00 |
| GaryvdM | mkanat: If I can get my code to work with only portions of the graph, the using it would help. | 20:01 |
| lifeless | mgz: hmm, I find the errors better | 20:02 |
| mgz | I'll paste you an example ina sec... | 20:03 |
| mgz | I think the problem is generally that assertThat is less specific so knows less about what can safely be ignored, unlike the old function versions | 20:03 |
| lifeless | mgz: really? the reverse seems true to me | 20:04 |
| lifeless | the matchers can be very specific | 20:04 |
| lifeless | mgz: or do you just mean how far up the stack trace goes? | 20:04 |
| mkanat | GaryvdM: Okay. | 20:05 |
| mkanat | GaryvdM: Perhaps by making it walk the graph when the + is clicked? | 20:06 |
| GaryvdM | mkanat: Yes | 20:06 |
| mkanat | GaryvdM: Okay. :-) | 20:07 |
| mgz | lifeless: example -> http://paste.ubuntu.com/530860/ | 20:07 |
| GaryvdM | mkanat: Do you have any methods that you use to benchmark the memory usage? | 20:07 |
| mkanat | GaryvdM: Well, to figure out what's actually using memory, I use meliae. But otherwise, I just run load tests on it and see how big it gets, usually using a bunch of copies of the launchpad-itself branch. | 20:08 |
| lifeless | mgz: so, there are two differences | 20:08 |
| lifeless | mgz: one is the stack - I like the full stack (because I work on the test code itself) | 20:08 |
| GaryvdM | mkanat: ok | 20:08 |
| lifeless | mgz: the other is the formatting, which seems pretty much a wash in this case | 20:08 |
| mgz | the first there is duplicative | 20:08 |
| exarkun | The latter formatting is better. | 20:09 |
| mgz | you get 'text/x-c++src' and None twice, and it's not really any clearer what's up. | 20:09 |
| exarkun | It's easier to read and lets you copy/paste into a repl | 20:09 |
| mgz | it does tell you (or should do if the test is written right) which is the result and which is the expected, but is much more verbose | 20:10 |
| lifeless | exarkun: the assignment 'a =' is useful for you? | 20:10 |
| exarkun | lifeless: yes | 20:11 |
| exarkun | when the values are more complicated and it's not obvious how they differ | 20:11 |
| exarkun | although I'd rather the output highlight where the differences are so I don't have to grope around to find it myself ;) | 20:11 |
| lifeless | exarkun: right, thats the point of the interface actually. | 20:11 |
| lifeless | exarkun: have you seen what soupmatchers does? | 20:12 |
| exarkun | no | 20:12 |
| lifeless | it looks for the difference and shows it | 20:12 |
| lifeless | not as a diff, but semantically. | 20:12 |
| exarkun | lifeless: but I just want to use assertEquals | 20:12 |
| mgz | lifeless: so I get the theoretical benefits of assertThat style, but at the moment I mostly see the downsides in practice | 20:13 |
| mgz | they're small, but could do with some polishing love. | 20:13 |
| mkanat | abentley: You know what else I don't like about looms? I actually don't like having to write commit messages every time I commit to a thread. | 20:14 |
| abentley | mkanat: you mean a normal commit? Or "record"? | 20:14 |
| mkanat | abentley: I mean an actual commit, like when I'm working on a loom. | 20:15 |
| mkanat | abentley: Since I have to commit in order to switch threads. | 20:15 |
| lifeless | mkanat: you do ? | 20:15 |
| mkanat | abentley: And I have to commit to make a new thread on top of this one. | 20:15 |
| mkanat | lifeless: Yes. | 20:15 |
| mkanat | bzr down-thread upstream | 20:15 |
| mkanat | bzr: ERROR: Working tree has uncommitted changes. | 20:15 |
| abentley | mkanat: Well, you *could* shelve them. | 20:16 |
| lifeless | mkanat: what does [bzr switch upstream' say? | 20:16 |
| lifeless | mkanat: its meant to carry changes across for you. | 20:16 |
| mkanat | lifeless: I want this working tree to stay with this thread. | 20:16 |
| lifeless | mkanat: then yes, shelve or commit is appropriate. | 20:16 |
| mkanat | lifeless: I had no need or desire to commit to the thread, I just wanted to back and update upstream to the actual current upstream. | 20:16 |
| lifeless | mkanat: aaron's shelve-in-developing-patch-context is very nice in this regard. | 20:17 |
| mkanat | lifeless: I'm not familiar with that. | 20:17 |
| lifeless | mkanat: pipelines have a shelve context in the 'thread' equivalent (in the branch, a single pipe) | 20:18 |
| mkanat | lifeless: Ah, yeah. | 20:18 |
| lifeless | this is something that would benefit looms too, poolie has some ideas on unifying the should-be-common aspects of pipelines and looms | 20:18 |
| lifeless | pipelines have much more polish | 20:19 |
| mkanat | Cool. One thing that I really would like is a simpler path to do "rebase to upstream and delete all the threads that are now identical to upstream". | 20:19 |
| lifeless | mkanat: I think loom prompts you for that doesn' it? | 20:19 |
| lifeless | mkanat: whats your loom version | 20:19 |
| mkanat | lifeless: 2.1 | 20:19 |
| mkanat | I can try updating. | 20:19 |
| lifeless | thats your problem | 20:19 |
| lifeless | 2.1 won't even push properly to launchpad | 20:20 |
| mkanat | Okay. Will trunk work with bzr 2.1.1? | 20:20 |
| lifeless | should do | 20:20 |
| mkanat | Okay. | 20:20 |
| abentley | mkanat: I'm not a fan of rebase, but I'd be happy to make "bzr remove-pipe --auto" remove pipes that have been merged. | 20:21 |
| mkanat | abentley: I was using "rebase" in the loose sense, not in the sense of the command. | 20:21 |
| mkanat | abentley: That sounds like a good solution. | 20:22 |
| mkanat | I think I may start using pipelines in looms. Another example of a bad situation is when I screw up upstream somehow, and then up-thread. | 20:24 |
| mkanat | Then it's very difficult to go back and fix upstream. | 20:24 |
| mkanat | Okay, loom trunk is broken in some way that I do not now want to spend time debugging. | 20:26 |
| mkanat | AttributeError: type object 'InterLoomBranch' has no attribute 'unwrap_format' | 20:26 |
| abentley | mkanat: You could use looms in pipelines, but I don't recommend it. Your head could explode. | 20:30 |
| mkanat | abentley: Hahahaha. | 20:30 |
| mkanat | abentley: I meant "instead of". | 20:30 |
| dash | you got your tubes in my loom! | 20:30 |
| mkanat | Just typed "in" by accident. | 20:30 |
| mkanat | It's not a trunk, it's more like a series of looms. | 20:30 |
| abentley | mkanat: Ah. | 20:31 |
| mkanat | BTW, the Internets ^^^^^ | 20:31 |
| mkanat | Oh, and heaven forbid that what gets checked into upstream is slightly different than what was in your loom. | 20:37 |
| mkanat | Then you're in for a fun time called "re-creating every thread". | 20:37 |
| mkanat | (Or a separate fun time called "resolving spurious conflicts in every thread".) | 20:38 |
| lifeless | mkanat: I don't see how that is different in looms vs pipelines | 20:55 |
| mkanat | lifeless: I haven't used pipelines yet. | 20:55 |
| lifeless | (either of the upstream workflows you describe) | 20:55 |
| mkanat | lifeless: Yesterday you wanted me to say what I didn't like about looms, and I'm using them in actual practice right now, so I figured I'd just mention what I was running into. | 20:56 |
| lifeless | mkanat: I value the feedback | 20:56 |
| lifeless | mkanat: better if you file bugs :) | 20:56 |
| mkanat | lifeless: Okay. | 20:56 |
| lifeless | mkanat: I'm just noting that the specific workflow I don't see a different in loom vs pipelines | 20:56 |
| mkanat | lifeless: Okay. | 20:56 |
| lifeless | mkanat: particularly for that unwrap_format error | 21:02 |
| * mkanat nods. | 21:02 | |
| GaryvdM | mgz: I've now separated the nodes and lines. But I can't get it to link the height of the svg to the height of the row. | 21:37 |
| GaryvdM | mgz: I'm not sure which part of that page you sent me I should be looking at? | 21:38 |
| * GaryvdM has another idea to try... | 21:38 | |
| ovnicraft | hi folks, what this means bzr: ERROR: [Errno 1] Operation not permitted: 'some_file' ? | 22:17 |
| poolie | probably you don't have permission to write to it | 22:17 |
| EdWyse_Office | Is there any way to fix this error: http://bzr.pastebin.com/RpbtF5gt | 22:20 |
| ovnicraft | poolie, there is anyway to commit ignoring conflicts | 22:24 |
| GaryvdM | mgz: Got it working \o/ | 22:30 |
| poolie | ovnicraft, sorry, not at the moment | 22:30 |
| poolie | EdWyse_Office, that looks like a bug that we fixed in a recent release, are you on the most current one? | 22:31 |
| GaryvdM | Hi poolie. Check this out http://41.242.164.81/ :-) | 22:31 |
| ovnicraft | poolie, i was researching about multi-branch support is that in your roadmap? | 22:31 |
| EdWyse_Office | 2.1.1-4 from the epel repo. | 22:31 |
| GaryvdM | ovnicraft: Are you maybe think of colocated branches? i.e. having more than one branch in a folder? | 22:32 |
| GaryvdM | *thinking | 22:32 |
| EdWyse_Office | It looks like it was the image that was messed up somehow. I was able to fix it be reverting that file (which hadn't been changed or added) and committing. | 22:33 |
| ovnicraft | GaryvdM, yes | 22:33 |
| GaryvdM | ovnicraft: There is a plugin: bzr-colo | 22:34 |
| ovnicraft | GaryvdM, yes but we need support in lp | 22:35 |
| GaryvdM | Goodnight all | 22:39 |
| mgz | night Gary, well done for getting the svg joined up. | 22:42 |
| awilkins | How long does it usually take after you upload sources to a PPA for them to show up? | 22:55 |
| awilkins | And does it still work if the sources are not part of the distribution? | 22:55 |
| poolie | awilkins, normally you will at least see them being queued to build within a few minutes | 23:11 |
| poolie | you should get an 'accepted' email | 23:11 |
| poolie | the time for them to actually build varies a lot depending on lead | 23:11 |
| poolie | *load | 23:11 |
| poolie | what do you mean by 'not part of the distribution'? | 23:11 |
| poolie | it's fine to build packages that are not already in ubuntu | 23:11 |
| awilkins | poolie, Aha, rejected email | 23:13 |
| awilkins | That's what I get for not keeping a notifier open | 23:13 |
| awilkins | This packing malarkey really needs clearer docs or tools, but I do appreciate it's not exactly simple | 23:15 |
| mgz | lifeless: testtools r128.1.6 is problematic, it's not valid Python 3 syntax and stores an exc_info in locals. I think examining the premise that it should be possible to assert non-Exception subclasses should be re-examined. | 23:24 |
| lifeless | mgz: grah. sory | 23:27 |
| lifeless | mgz: uhm, we can fix the locals thing | 23:27 |
| mgz | yeah, I'm more worried about Python 3 | 23:27 |
| lifeless | we can't self host on this without the facility though | 23:27 |
| mgz | I think the only way of reraising with a stored traceback there is setting in on the exception instance | 23:27 |
| mgz | which is All New so... can't also work for pythons people actually use | 23:27 |
| mgz | both KeyboardInterrupt and SystemExit can be raised outside the control of the thread running tests, so you can't ever write a proper unittest for raising one | 23:29 |
| mgz | this is admittedly a pretty academic objection. | 23:29 |
| mgz | ...maybe I should be in the testtools review group... though not sure I'd have had time to look at this before today anyway | 23:30 |
| mgz | hm, not coming up with any genius ideas for different spelling keeping the current semantic | 23:32 |
| mgz | (it's wrong on Python 2.4 too, but that's probably less important) | 23:32 |
| poolie | awilkins, i agree | 23:34 |
| poolie | hi mgz | 23:34 |
| mgz | hey poolie | 23:34 |
| mgz | I shall file some bugs lifeless. Think this is a good change, just wants some more minor pokes. | 23:36 |
| lifeless | mgz: we'd be delighted to have you as a reviewer/committer | 23:38 |
| mgz | the thought of fixing the expectError case particularly interests me, especially as we've got some backwards expectFailure/assertRaises currently. | 23:39 |
| poolie | mgz: ? | 23:39 |
| lifeless | mgz: we have a fairly nonblocking review process, trying to keep things agile | 23:40 |
| awilkins | Darn. Only the "dev" package has the library in it. Something is wrong there.... | 23:42 |
| mgz | it's a good thing, and jml has also put out some feelers on wider version testing as testtools tries to have such a wide support net | 23:42 |
| mgz | (which would help prevent releasing with 2.4/3 borked) | 23:44 |
| mgz | poolie: I was thinking of -> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/tests/per_workingtree/test_smart_add.py#L304 | 23:47 |
| mgz | which is hard to read, but makes an unexpected success | 23:47 |
| mgz | have a branch fixing that silence problem, but spelling the intention of that test correctly is currently hard, and Robert just added some new fancy to testtools that should make it possible in future. | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!