[00:25] lifeless: is https://code.edge.launchpad.net/~james-w/testtools/discover/+merge/26994 something like what you had in mind? [00:37] morning [00:38] moin moin [01:04] lifeless: on the topic of testtools.run from earlier, [01:04] is there any good reason why it can't just be `python -m testtools` [01:04] hi mgz [01:05] and import the stuff from testtools.run in __name__ == '__main__' in __init__.py [01:05] hey poolie. [01:05] mgz: no good reason either way [01:05] mgz: I will say, I somewhat prefer testtools.run [01:05] grabbing all the possible contexts as the default for testtools seems... crude [01:06] hi lifeless [01:06] mgz: is it functional/aesthetics/other ? [01:06] hi poolie [01:06] moving it is an easy way to fix 501174 [01:06] *bug 501174 [01:06] Launchpad bug 501174 in testtools "Suggest alternative to python -m testtools.run for Python 2.4 (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/501174 [01:06] the actual code can still be in run [01:06] I just want to -m the package root. [01:06] oh [01:06] mgz: yes, I get what you want :) [01:07] and its a functional difference for you [01:07] ah, makes sense to me [01:07] mgz: sure, to make it work on 2.4 the little ugliness is ok [01:07] mgz: uhm, what do you think of [01:08] python -m testtools run [01:08] and [01:08] python -m testtools.run [01:08] both working [01:08] sounds fine to me, should be easy to arg wrangle. [01:10] especially as the james_w branch is making the __main__ code the ideal one line [01:10] I'd be happiest with that [01:10] ...two lines. would fit on one though :) [01:10] because that way when 2.4 finally keels over [01:10] we can do other stuff [01:11] and if we have other front ends to add, they aren't squashed out [01:11] 2.4 can't do -m something.dotted? [01:11] nope, and I was confused too when I tried it. [01:12] it's not something other packages I've wanted to use have gone for, no idea about it till I was trying testtools [01:14] right [01:14] james_w: yes, bug in 2.4, it assumed top level module. [01:18] hm, might just try that now see what it looks like [01:24] urk, that might not be a fix, seems to only want .py not /__init__.py [01:24] ah [01:24] will just have to note in the documentation I guess. [01:24] so really not supporting modules :) [01:30] poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present [01:31] but that wasn't the right test anyway. [01:33] ah, whoops. [01:33] igc1, hi there? [01:33] guess I should repeat that, though not very important [01:34] poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present [01:34] but that wasn't the right test anyway. [01:36] oh ok [01:36] hm, perhaps we should define an inverse feature then [01:36] but that would be ok === oubiwann_ is now known as oubiwann [01:50] hello [01:50] i had revision 20 on repo A, worked on repo B up to revision 40, bound B to repo A and all my revisions past 20 are gone [01:50] how can i get them back? [01:53] hmm, they are on B [01:53] that's odd [02:24] spiv: poolie: I think, on reflection, that any inheritance from Branch/Repository etc in remote.py is actually harmful, not beneficial [02:24] lifeless: hmm [02:24] lifeless: one of those two don't inherit [02:25] yes [02:25] lifeless: and it's increasingly causing problems too [02:25] and we've been muttering that it should [02:25] I'm thinking it shouldn't more and more as I address this loom bug [02:25] So inheriting in remote.py: not great. Not inheriting: also not great. [02:25] I wonder what the solution is. [02:25] consider sprout [02:25] what we want is: [02:25] - no VFS for the default case [02:26] - VFS if the smart server can't do what the branch needs [02:26] - ideally smart in all cases [02:26] sprout is currently a method on e.g. Branch [02:26] we define sprout on RemoteRepository [02:27] not on Branch [02:27] and because of that Branch.sprout doesn't copy loom data across [02:27] I discussed a structured approach with poolie [02:27] but I'm not entirely happy with how it felt [02:27] I think we haven't got sprout right in terms of which objects are responsible for the various parts of it. [02:28] And the trouble with Remote + loom is a symptom of that. [02:28] it might be better with an Inter [02:28] and be on the format object [02:28] so it could do self._format._ensure_real() [02:29] self._format.sprout(...) and that lookup on the ... [02:29] anyhow, I think I'm going to: [02:30] sorry, sec [02:31] lifeless, i think those base classes should become abstract [02:31] many of them iirc have a lot of historical stuff near the top of the class hierarchy [02:31] poolie: I agree but I think that that is perhaps orthogonal [02:31] and that we should look for reuse in the Remote* hierachy through composition or something [02:32] thoughts on moving sprout from Branch to BranchFormat ? [02:32] its only use of self is self.copy_content_into [02:32] which the format could happily call [02:33] and we have [at least for now [02:33] ] established free access to Format objects for bzrdir components [02:34] lifeless: reuse through composition sounds like a very plausible idea to me [02:37] let's say complementary [02:37] i think if you need to make them composable perhaps you need to move them out of the base class [02:37] anyhow, hooray for cleaning it up [02:45] well I don't know how much cleaner it will be [02:46] did either of you have thoughts on the proposed move of sprout ? [02:46] ah [02:46] to the BranchFormat base class? [02:52] from Branch to BranchFormat [02:52] where differences exist [02:53] I propose to put it on appropriate BranchFormat subclasses [02:53] and on RemoteBranchFormat, we can then delegate to the actual Format [02:53] sorry for the lag [02:54] so you'll call effectively source_branch.format.sprout(to_transport)? [02:54] yes [02:55] for compat [02:55] we can leave Branch.sprout in place, deprecated [02:55] and why is this better? [02:55] and it would call that as self._format.sprout(self, to_transport) [02:55] because we know the format of remote branches even if we haven't done _ensure_real on the Branch [02:56] so we can run the right code for looms without triggering VFS for regular branches [02:59] hm [02:59] i kind of see the problem you mean [03:00] i think the public api that makes sense is probably branch.sprout(to_transport) [03:00] i don't see why the caller would want to work in terms of the format [03:00] In short: sprouting needs to take the format into account, and making the format responsible for sprouting takes care of that? [03:00] uhm [03:00] now behind the scenes there are some issues about perhaps not yet knowing the remote format [03:00] so sprout as currently defined sprouts to a to_bzrdir [03:00] which is, I think ok [03:01] ok [03:01] it needs to:\ [03:01] - make a new Branch in the bzrdir, which is a little complex. [03:01] - it might be the same as the source format [03:01] - or there might be some magic kick in to ensure it supports something that the default doesn't [03:01] - it needs to copy the metadata from the source branch across [03:02] if you look at branch.py, at sprout [03:02] you can see that its ~15 lines [03:02] only one of which calls self.* [03:03] thats not a very strong argument, but its data [03:03] secondly, ideally, the copying of metadata would be a multimethod [03:03] on source,target [03:04] right [03:04] and we can for such source, targets either use the Branch objects or the BranchFormat objects [03:04] now, BranchFormats are the unique things on disk [03:05] we guarantee that there are unique network strings for any given format, we don't guarantee that for Branch subclasses [03:05] its possible to use the same Branch class, parameterised, to handle two different Formats [03:05] I don't know if we use that, but that was part of the goals in the early design [03:05] so perhaps it wouldn't work now and we should discount it [03:06] as i've said before there seems imperfect separation between formats and branch classes [03:06] ah [03:06] one could have a branch class that delegates absolutely everything to its format and could be used with every format [03:06] i'm not sure why that would be useful though [03:07] that would be an extreme [03:07] Formats are factoried for Branch objects [03:07] so a BranchFormat can *parameterise* a Branch with appropriate delegated objects [03:07] on construction [03:07] conversely i suppose we could have a branchformat that actually knows nothing about the format other than its name and what Branch class implements it [03:07] right [03:07] right, thats the other extreme [03:08] i don't feel there is a clear principled statement of where we go between those extremes [03:08] now, I guess I'm saying that right now, sprout feels more like an interaction between the formats [03:08] and it's not consistent between the two of them [03:09] poolie: to me, disk management code should go in formats (or in objects the formats supply), and model code should go elsewhere === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it [03:09] (changed pilot->spiv) [03:09] spiv: wearing the pilots-get-interrupted hat, perhaps you could do the followup on the release [03:10] the execution-of-announcements etc, if the binaries are all copacetic [03:10] [the topic change reminded me] [03:10] basically agree about that, though probably i'd like it to be objects that are plugged into the branch [03:10] ah [03:11] so i still think in terms of the public api, the user has a "branch _this_ to _here_" [03:11] poolie: 'it'? 'like it to be' [03:11] " disk management code should go in formats (or in objects the formats supply)" [03:11] poolie: ok, so 'disk management code should be in objects that are plugged into the branch' ? [03:11] poolie: you have an implied 'and not the formats' there, right ? [03:12] i think doing code that amounts to self.format.get_something(self.transport) is a bit weird [03:12] where self is a branch [03:12] I think thats true [03:12] poolie: thanks [03:12] however doing at startup, self.tag_manager = self.format.get_tag_manager(self.transport) feels a bit less weird [03:12] If delegating like that, i'd write it as self.format.get_something(self) [03:13] perhaps you could propose some text suitable for the architecture overview that describes what you think the split should be between branch/repo/wt etc and their formats [03:13] poolie: separate objects for separate concerns is good too - tag manager is a great example of splitting that out [03:13] I sure can [03:13] mm [03:13] I want to get looms working first [03:14] but I'll put a doc refresh right under that on the stack [03:14] for example is all the knowledge about a disk format going to be in the format, or in a class that the format knows about and provides to the branch, or is it going to be in parallel hierarchies, etc [03:14] ok [03:14] so let's talk for a bit about fixtures? [03:14] we might propose a merge into testtools that adds fixtures such that [03:15] the test scope cleans up the fixture [03:15] people are encouraged to put reusable setup into a fixture class, not into setUp() or the test_() [03:16] http://pastebin.com/Nxkpz8Tp [03:16] this is an in progress patch I have [03:16] which uses a fixture concept heavil [03:16] y [03:16] lifeless: Ok, I'll take a look at release followup, although I doubt if I'll get to that today. [03:16] with a focus on composition [03:17] heh [03:17] i'm coming to really dislike Command pattern in python [03:17] i wouldn't veto this just because of that [03:17] poolie: I'd love to see a small patch for testtools to aid with fixture use and definition, though I think its really very small and likely to bikeshed until we have some wider experience with it [03:17] poolie: I don't see this as Command [03:18] poolie: I see it as Composite, if you want to name it [03:18] MirrorProposed, i mean [03:18] oh [03:18] well thats me following suit on the lp plugin style [03:18] it's 90% overhead compared to just having a function [03:18] and it seems to harm refactoring rather than helping it [03:19] other bits of the lp plugin do this, and I wanted to fit with the style in that area [03:19] ok [03:19] but "if not now, when?" [03:19] i'm just mentioning it because i see it now [03:19] when its fully automatically testable ;) [03:19] fair enough [03:19] set a good example rather than following a bad one :) [03:20] I'm not enamoured of it either :> [03:20] i'm glad we agree :) [03:20] igc liked the netflix slides too [03:20] cool [03:20] so, I'd love it if you had a think about what I do with fixtures in that patch [03:20] its not perfect, but I think it communicates where my thinking is at [03:20] hm [03:21] why is manyfixtures useful? [03:21] and thats the sort of thing I'd want to encourage with a testtools patch, wearing my testtools patch reviewer hat [03:21] just faster than calling useFixture repeatedly? [03:21] does testtools have a list? [03:21] testing-in-python [03:21] which is perhaps not appropriate [03:22] jml: ^ we should revisit that [03:22] poolie: I don't know (multifixtures) it seemed like a good idea at the time; because many fixtures might want to group a few bits together. [03:23] i'd like to get my thoughts a bit more straight before posting there perhaps [03:23] poolie: I'm sure its not right, I'm also not sure its wrong. [03:23] back to sprout [03:23] I feel a little hamstrung [03:23] should [03:23] - move it to BranchFormat [03:23] - just accept the VFS overhead of doing it in-place [03:24] this is because you want to have the same RemoteBranch but it will have a different BranchFormat if the remote thing is actually a loom? [03:24] I don't want to move it to BF and leave a forwarding method, because if the *contract* is on Branch, RemoteBranch can't safely forward unconditionally. [03:24] yes [03:24] why not? [03:25] i mean why can't it safely forward unconditionally? [03:25] because SvnBranch.sprout might not forward\ [03:25] so RemoteBranch.sprout, with the real branch being an SvnBranch, wouldn't do the right thing anymore [03:25] sorry, got to go, back in about 60m [03:25] ok I'm going to go drop my PC for repair [03:25] should be ~same [03:25] ciao [06:02] igc, re test fixtures [06:02] * "[Launchpad-dev] New feature in Launchpad TestCase base class" [06:02] * https://code.launchpad.net/~mbp/bzr/testsubjects/+merge/24188 [06:02] * https://code.launchpad.net/~mbp/bzr/fixtures/+merge/25337 [06:02] BZR first-time user question! [06:03] jelmer: you set a merge proposal to Queued. PQM isn't using the queue in LP atm, you need to use the email method. [06:03] http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg03226.html [06:03] spiv it's an easy mistake to make because feed-pqm still lets you queue them [06:03] In git, if I have changes I want to store but don't want to commit to my main branch - I can do git branch mynew branch, work in that branch, then commit that branch to my git server and do a merge later [06:03] we should disable it in the client [06:03] How would I do the same thing in bzr - spawn a new branch, push that branch to the bzr server [06:04] poolie: right [06:04] willmarshall: [06:04] bzr branch . ../otherthing [06:04] cd ../otherthing [06:04] bzr merge --uncommitted ../firstthing [06:04] poolie: Yah - but that's just local branches on my dev box [06:04] or alternatively if you just want to store it temporarily and not commit it, 'bzr shelve' [06:04] I really need to push this branch to the bzr server so others can also work on it [06:05] willmarshall, well, then commit in otherthing and push it to the server [06:05] you need to push them separately [06:05] without pushing it to the branch we're deploying from, cos it breaks stuff [06:05] or as a third alternative use bzr-colo which is more like git colocated branches [06:05] poolie: [06:05] push it somewhere different [06:05] Ah! So bzr doesn't quite work like git, and I am confused? [06:05] it's not quite like git; i'm not sure if you're confused :-) [06:06] The manual for bzr seems to be telling me that if I do bzr branch myrepo ./somedir [06:06] And then work on that branch, commit and push [06:06] My changes won't be in a new branch on the server [06:06] willmarshall, they'll be in a separate branch on the server if you push them to a separate branch [06:06] unlike in git, where branches have names and you can push to different branches in the same place [06:07] Ok [06:07] right, normally in bzr each directory has only one branch [06:07] How do I spawn that branch on the server? [06:07] unless you use bzr-coro [06:07] *bzr-colo [06:07] Oh! So this is is more svn-like? [06:07] a bit, but it's not exactly like svn either [06:07] Ok [06:07] Gotcha [06:07] bzr-colo sounds like what I need [06:07] normally if you have bzr+ssh://server/repo/trunk [06:08] then you can just do "bzr push bzr+ssh://server/repo/otherthing" [06:08] poolie: ah, you're back [06:08] poolie: so, I think I'm just going to move it around and see how it feels [06:08] by all means [06:08] lifeless: +1 [06:08] i really think that document would help [06:08] poolie: I think it will too [06:08] it may help you and it will almost certainly help with review and with making things more consistent in future [06:08] we don't want people moving different aspects at random [06:09] poolie: I'll be thinking about it all the time I'm moving stuff [06:09] oh [06:09] poolie! Awesome. That worked [06:09] and my games machine - cpu heatsink was /way/ loose [06:09] huh, funny coincidence [06:09] Thank you very much [06:09] np will [06:09] attached properly and its apparently fine now [06:09] lifeless, is it scorched? [06:10] poolie: appears not; thermal protection in i7 is pretty good I'm told [06:10] great [06:10] how did they get it to reattach properly? remove it and re-add thermal pad? [06:10] nope [06:10] Hammer? ;) [06:10] just twisted the thumbscrews, pushed firmly till they went clink [06:11] I'd been afraid to really push hard here, and not sure of the mechanics inside the plastic heads [06:11] apparently its like plaster screws [06:11] with a inner than locks open, and the original install [probably] never got it quite open enough to lock in place [06:12] back in .au I had been seeing thermal warnings from time to time, just figured it was linux slackness [06:12] but now, no warnings at all [06:12] likewise [06:12] how strange [06:12] this makes me wonder if my machine could be fixed by just re-seating it, but perhaps at this point it really is scorched [06:13] what cpu was/is it ? [06:13] E6600 Core2 [06:13] so the question would be if intel's thermal protection changed much from there to i7 [06:13] well worth trying, I'd say [06:13] i might call and ask then [06:45] Is there really no solution to the memory problem when branching large subversion repos? [06:45] I need to branch from llvm, which has 105k revs. I'm already on a 64bit machine. [06:50] bac: have you tried doing batches, like - branch -r 5000 source target; cd target; bzr pull -r 10000; bzr pull -r 20000 etc ? [06:50] bah [06:50] Bigcheese: ^ [06:51] sorry bac [06:51] heh [06:51] That's what I'm doing now, and it works, it's just going to take for ever with how small I have to increment. [06:52] what size are you incrementing in ? [06:52] Even one revision uses all 2 gigs of ram... [06:52] 100 right now. [06:52] thats surprising [06:52] are you perhaps using the root of the svn repo, rather than one specific branch? [06:53] I'm checking out trunk. [06:53] So no, just one branch. [06:53] thats very odd [06:53] Well, 1000 seems to work. [06:53] could you file a bug, its not meant to use that much memory :) [06:54] There's already one filed :P And it's talked about everywhere on the internet :P. [06:55] uhm [06:55] memory issues are a hydra [06:55] I find assuming that a previous bug 'x used lots of memory' is rarely a good indicator. [07:04] Searching the bug DB I've found at least 5 of the exact same thing. One even mentions you :P. [07:08] thats likely [07:08] we've had many causes of too much memory [07:08] some are large files [07:08] some are cache misuse [07:08] some are too many strings [07:08] to answer the question about whether there is a fix, we need to figure out what particular 'uses lots of memory' bug you have [07:08] so - for starters, what bzr version and bzr-svn versions do you have? [07:10] how do I check the bzr-svn version? [07:10] bzr plugins [07:11] http://codepad.org/1ToCN8jN [07:13] bzr 2.1.2 reduces memory consumption for some operations [07:13] might be worth trying [07:13] Is that only availible via source? [07:13] what platform? [07:14] Windows 7 x64 [07:14] I can't see a 2.1.2 binary on https://edge.launchpad.net/bzr/+download yet [07:14] so yes, looks like source only [07:15] spiv: ^ btw may be a fast task to do the release - just send email :P === quicksil1er is now known as quicksilver [07:17] Thanks, I may try that if I this breaks again. [07:17] It's finally working 10k at a time, [07:17] So that's not too bad. === radoe_ is now known as radoe === lifeless_ is now known as lifeless [08:22] lifeless: might be fast, but we're done for the day. Will have to look tomorrow. [08:23] lifeless: thanks for the idea [08:23] spiv: sleep well [09:06] mgz: ping [09:07] indeed I did apparently. [09:07] do I bother looking up how to ghost myself on this network... === bouncingzip is now known as mgz [09:09] parthm: hi === jfroy_ is now known as jfroy [09:09] mgz: thanks for the patches :) [09:11] it's your own fault for copying all those loops, 's like waving a red flag to a pedant like me :) === mwhudson_ is now known as mwhudson [09:12] I'll see if I can get to doing unicode support at some point too, though there aren't any great options on that [09:12] mgz: yes. :) performat_output looks good to me. should are apply it or are you planning to change something else. [09:12] if it doesn't regress anything for you, land it [09:13] mgz: ok. i cool. i will try it out. [09:13] I'd be interested in if it's done anything bad to the profile in the cases I mentioned though [09:13] tried to keep stuff doing what it was doing before, but did change a few things [09:14] mgz: yes. i will try that. you patch is well timed, we get bug #590589 fixed as bonus :) [09:14] Launchpad bug 590589 in bzr-grep "UnicodeDecode error with -F -i (affected: 1, heat: 8)" [High,Confirmed] https://launchpad.net/bugs/590589 [09:15] was trying not to make anything slower in that branch so the follow-on speed up was still a win. [09:18] mgz: UnicodeDecodeError for 'bzr grep ff' on mysql repo http://pastebin.com/JGfwXbk5 [09:18] doh! [09:19] mgz: maybe line.decode(file_encoding, 'replace') can fix it? i can do that here. [09:19] did I forget the "replace" on one of the lines? [09:19] you're ahead of me. [09:19] I... forgot it on all of them? [09:21]