[00:04] jml Just so I have a fuller mental picture, using stacked would be useful in scenarios like a bzr server on a LAN serving repositories for a large project or a pull for an automated build system build system === abentley1 is now known as abentley [00:45] 8262.921 Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1526124] [00:45] 9055.759 Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1592792] [00:45] those are big numbers :( [01:26] jml If you have a bunch of branches in a local repository and you want to remove a branch is it sufficient to just delete that branches' directory or does something more have to be done? [01:26] rasker, you have remove it, but the revisions will still stay in the shared repo [01:26] beuno: hello [01:27] jml, hi there [01:27] so I would have to do a bzr remove? [01:27] how's it going? [01:28] rasker, no, it's not really something easy to do to remove revisions from a shared repo [01:28] beuno: happy and slow :) [01:28] beuno: you? [01:28] jml, I have unaswered emails from you, and I'm ashamed of it [01:29] I'm good actually! my brain is almost non-functional, but it's also de weekend, so it's good timing [01:29] beuno: that's ok. [01:29] beuno actually I just want to remove a branch that is within a repository [01:29] rasker: deleting the directory is fine then [01:30] this doesn't mess with the repository itself (i.e unreferenced stuff left behind)? [01:31] jml, I just realized that I've been thinking your lp-open stuff hadn't landed because bzr doesn't autocomplete it. Do you know why that is? [01:31] rasker: nope [01:31] beuno: not a clue, I'm afraid. [01:32] jml beuno : thanks. This bzr stuff is wickedness [01:32] rasker: np. [01:45] jml this repository I created with all these branches is pretty big (meaning that shovelling everything in a repository has not reduced the disk storage) . Is that because each branch has a working directory? [01:46] jml sry I mean working tree not working directory [01:48] rasker: sorry, but without concrete numbers I couldn't possibly guess. [01:48] rasker: du -sh branch/.bzr [01:48] rasker: du -sh repo/.bzr [01:49] rasker: that should give you an idea of where the data is, aside from the working tree. [01:58] Oh look, sourceforge adding git support. [04:40] jml: lp merge request ok? [04:41] if i wanted to play with bzr-git, which branches of the various things should i get? [04:42] lifeless: sure [04:52] bah, push failure [04:52] can I just send a bundle yet? [04:54] mwh@grond:git-play$ git st [04:54] git: 'st' is not a git-command. See 'git --help'. [04:54] BAD START [04:55] no, thats about normal [04:55] I've seen folk who use git all the time get such messages [04:56] apparently they expect them [04:56] no ci either [04:56] lifeless: I think bundle sending didn't quite make it into the release, due to rollout issues [04:57] lifeless: you can send a merge directive without a bundle [04:57] lifeless: but I'd rather a branch. [04:58] jml: yeah, I've deleted and initted and pushing again [04:58] will look at the cause on monday [04:59] https://code.edge.launchpad.net/~lifeless/testtools/addSkipped/+merge/4031 [05:11] ja1: you don't need len [06:26] jml: so, whaddya think [06:27] lifeless: mostly looks good. some spelling tweaks [06:27] lifeless: will reply when I have more energons. [06:28] jml: if its just tweaks, merge and do? [06:28] lifeless: sure, if you want. [06:28] jml: long as self.skip, and result.addSkip aren't the things being tweaked, I don't care about the rest :) [06:29] lifeless: yeah, it's comments and test method names and the like [06:29] nothing of substance :) [06:29] then I'll start using it [06:29] and put a patch for bzr to meet the same contract [06:47] hmm [06:47] actually subunit first === montywi|zzz is now known as montywi === chx is now known as chx_sleeping [10:02] I have a branch with a loom [10:02] I want to export a single thread as a separate, *non*-loom branch [10:03] so that I can push it to a public location for others (who may not necessarily have loom support) to work with. [10:03] how can I do that? [10:03] bignose: bzr init target; bzr switch thread; bzr push target [10:03] bignose: and after that the last two commands only [10:04] doesn't ‘bzr switch’ need to be done *inside* a branch? [10:04] whats 'a' ? [10:06] you gave me three commands; presumably I type them all in sequence (with appropriate arguments). [10:06] sure, starting in your loom [10:07] okay, so ‘target’ would need to be a branch location *outside* the loom then? [10:07] yes [10:07] I was confused because I've been trying to do this with ‘bzr branch --revision thread:foo orig/ target/’ [10:07] done *outside* any branch, of course [10:07] though not required, you could create the target standalone in a subdir of the loom [10:08] I'm seeing some unicode glyph my terminal can't render [10:08] UTF-8 FTW, baby [10:08] I'm not at all sure of what â means [10:08] probably your terminal isn't set to UTF-8 [10:08] yes, and when I track down the xlib fuckage that means I don't get utf8 when my locale *does* support it, I'll be able to read it [10:09] and sadly IRC has no way of communicating what character encoding is in use [10:09] the only non-ASCII characters I've used, AFAICT, are typographical quotes [10:09] anyhow, I'm seeing 'okay, so XXXXXsomethinghereXXXXXX would need to be ...' [10:10] where XXXXsomethinghereXXXXXis my terminal fail [10:11] its not a big deal, but it does mean I don't know quite what you are referring to [10:11] so, I'll explain more fully and hopefully that will make it clearer [10:12] bzr push URL, when you are in a loom, and URL is the URL of an existing regular branch, pushes the current thread to that branch's tip [10:12] I'm trying it out with the explanation so far [10:12] let me report back when I see how far that gets me [10:12] so the three commands were just saying 'create a branch somewhere', 'push to it from the thread you want to export' [10:13] thanks, that appears to have worked [10:13] for the record, the issue only became apparent when I tried to *bind* to a pushed branch [10:13] and it complained because it was a loom [10:14] oh [10:14] I don't think that would work well, no :P [10:14] also, I was expecting the revision spec to be able to pull oput a specific thread when branching [10:14] would that make sense, as something to add to the UI? [10:14] -r thread:name is possible, but bzr branch LOOM URL creates a LOOM at URL [10:15] I'm not quite sure of the best way to represent the use case, but its definitely something that would be nice to have [10:15] okay, but in that example, if a thread is specified as the revision, does it make any sense to create a loom at the target instead of a single thread? [10:16] bignose: possibly, possibly its in the too-much-magic category [10:16] still getting my head around looms, but I'm just giving feedback on how I expect it to work given my current mental model [10:16] bignose: yeah; what they need is a month or two of dedicated love [10:16] bignose: how are you liking them ? [10:17] they're good; they don't do what I originally expected them to do (have arbitrary interconnections between the threads) [10:17] and I still have no idea when I'm supposed to use the ‘record’ command [10:18] but for managing a *stack* (which isn't what I would expect a *loom* to do), they are quite handy. [10:19] did you say "record" command ? [10:19] I fully appreciate that the namespace of real-world concepts is already stretched thin :-) [10:19] lifeless: yes [10:19] ok, so I saw one character >< [10:20] AFK now, thanks for the help [10:20] my pleasure [10:21] mwhudson: b.l.n is still 1.12 yes? [10:29] jml: areound ? [10:29] lifeless: yes [10:29] code.lp.net is reliable :) [10:29] mwhudson: all this talk of beta and edge servers :) [10:30] I think spiv and I will have some qa to do on stacking on monday [10:32] launchpad fails tests with bzr.dev currently, we'll be trying to fix soon i guess [10:32] cause? [10:33] not completely clear [10:33] transport_server = SmartServer_for_testing [10:33] self.make_branch('.') [10:33] makes a remote branch now [10:33] that was one [10:33] always should have [10:34] its flip flopped, now its fixed with a test to test the test helper that it stays working [10:34] and two, in fact, though that one is really our fault, code and tests not agreeing and passing by fluke [10:34] some other stacking stuff, having debugged yet [10:34] (failing acceptance tests are _so_ fun) [10:35] oh no, some loom stuff [10:35] its possible you're seeing stuff I'm triggering here [10:35] we should talk [10:35] in the meantime [10:35] What will it take to commit some sensible things to unittest.py [10:37] yes [10:37] but not at 23:30 on a saturday :) [10:37] um, i'm not at all connected to cpython development at the moment [10:37] good :P [10:38] it would probably take much arguing on python-dev [10:38] there's no 'its clearly sane jfdi' clause? [10:38] i guess i might see gvr at pycon, i can try to get some preemptive points in [10:38] i'm not even subscribed to python-dev [10:38] I'm talking simple stuff like [10:39] TestResult.done() [the entire set of tests are finished with] [10:39] better still things like the addSkip patch I've put forward to testtools [10:40] I'm not fussed whether gvr agrees or not :) [10:40] well [10:40] i'm not going to commit stuff without getting involved in the community again [10:41] probably wise [10:41] I'm getting quite tired of carrying deltas to unittest.py [10:42] have you submitted patches? [10:43] though i wouldn't be super optimistic about getting them apploed [10:43] jml has had assertRaises-returns-exception rejected [10:43] the cpython developers, on the whole, don't maintain large systems :/ [10:43] I like included batteries to be capable of carrying a charge; [10:44] shipping flat batteries, not so good [10:44] um, the stdlib is good marketing, not much more [10:44] see above :) [10:47] well [10:47] much of it works well enough [10:51] lifeless: http://pastebin.ubuntu.com/124208/ <- that's the loomish failure [10:51] (haven't debugged at all) [10:52] * mwhudson zzzzzzzzzzz [10:52] mwhudson: ah yes loom needs a [trivial] fix to match bzr.dev api changes [11:03] done [12:18] lifeless: did you observe the discussion mid-2008 regarding improvements to Python's unittest? [12:18] on the python-dev forum [12:19] fuzzyman and I worked together for a little while putting forward some PEPs for improvement, in 3.x [12:29] bignose: I'm on TIP, but not python-dev [12:36] bignose: so no, I don't think I saw it === Leonidas_ is now known as Leonidas [13:04] jml: ping [13:04] Hello there, can anybody tell me how to disable these bzr-gtk notifications popping up after I push to a repository? I am using bzr and bzr-gtk under Ubuntu Intrepid. [13:23] solved it myself, many thanks for your help :-/ [13:47] lifeless: [13:47] lifeless: and subsequent unittest threads in that forum === chx_sleeping is now known as chx === montywi is now known as montywi|poker === cprov is now known as cprov-out [21:35] jml: are you subscribed to python-dev?