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