[00:02] Hmm... when I view the output of building the "survival" docs locally all I get is a blue page [00:02] Title headers are there but the content seems to be missing [00:02] Same for the other pages so I know it's not just me [00:14] awilkins: Sorry, that means you don't get to survive :( [00:15] Bah, pushed it up anyway, the text is still PURE GOLD, I tell you. [00:15] Only someone who hates VSS as much as I do could document how it differs from decent version control systems at all thoroughly. [00:16] Because by definition, anyone who knows a lot about how VSS works, hates it. [00:18] * mwhudson hasn't used VSS for 9 years, didn't use it much then and still hates it [00:19] * fullermd never used VSS, and still hates it :p [00:20] I used to have to run the "analyze.exe" tool [00:20] I figured the document would look something like "unlike VSS, bzr actually stores your history and can retrieve it later" [00:21] I tried to stay away from making it a "why Bazaar is just Soooooooo much better than VSS" document and stuck to "Why you may find Bazaar, or indeed, any decent VCS, a bit confusing after using VSS" [00:21] But it's far from complete and I need sleep. But slashdot beckons [00:21] Bah [00:24] Is Karmic going to have GNOME Shell? [00:25] awilkins: why do you care? rxvt-unicode, man! [00:25] Oh, is that what people use who don't have xterm? :p [00:25] Yeah, but it's nice to have a window manager to move your terminals around [00:26] You can fit more on the screen with overlapping windows [00:26] Pfft. Who wants to waste CPU cycles on frills? [00:26] awilkins: oh, wait, I'm confused with GNOME Terminal [00:26] I guess I may have been using Windows too much lately? [00:26] also, some people are liking Xmonad, though it's configuration file be written in a most arcane script ... [00:27] This was prompted by the announcement that Fedora 12 has a preview of it in the distro [00:27] gnome-shell is available in karmic [00:27] it's slightly neat [00:27] who needs a desktop? [00:27] SamB_XP_: who needs a computer? [00:27] Who needs a computer? [00:27] * dash hgh fives awilkins [00:27] :-D [00:28] How else would I heat my house? [00:28] dash: well, the desktop is a lot less necessary than the WM [00:28] if you'd seen my homedir, you would understand ;-) [00:28] They replaced my machine at work with one that only drives one monitor [00:28] That sounds like it should be a country song. [00:29] What the *hell* are they smoking in ICT [00:29] I'll just have to get one of those USB graphics adapters [00:29] huh, my school's ITS is really crappy and I don't think we *have* any computers that can only drive one monitor ... === davidstrauss_ is now known as davidstrauss [00:29] Or work at home a lot more... I neeeeeed my dual 22" widescreens [00:30] It's painful enough being trapped in tiny resolutions like 1280x1024 at work... [00:30] ... of course, none of them are really set up to take advantage of the second output, except some of the ones hooked up to projectors :-( [00:33] Blimey, gnome-shell is going all "Mac" in terms of menu === BasicPRO is now known as BasicOSX [01:16] I'm being pushy here, but: could someone send my branch to PQM? :D https://code.edge.launchpad.net/~mnordhoff/bzr/statictuple-pickling [01:18] Let's just agree too assume I've found the perfect time for the 'sounds like a real pickle' joke, and save me the trouble of coming up with it, and you the trouble of hearing it. [01:22] Peng_: hmm, I don't see your name on the list people that have signed contributor agreements... would you mind doing so? http://www.canonical.com/contributors [01:28] spiv: Yeah, I never did, cuz I don't like copyright assignment. :P I liked being in the grey area of "hasn't written enough code for it to be copyrightable". [01:28] spiv: Anyway, I'll do it now. [01:28] Crap, it's a PDF? [01:28] Google cache++ [01:29] Oh, that's a problem? I could have sworn this was 2009, not 1999 ;) [01:29] No way. Then I'd have to stop partying like this. [01:29] Haha [01:33] spiv: Or...I'll do it soonish. My brain isn't up to deciphering legal documents rightn ow. [01:33] spiv: Who do you want me to CC it to, you or poolie? [01:34] Peng_: poolie [01:50] spiv: 'kay [01:53] spiv: Is it supposed to be GPG-signed? [01:54] Peng_: I don't think it's required (whatever that link says is the rule), but it wouldn't hurt. [01:55] Peng_: and I know if I was the sender it would make me feel better ;) [02:29] hrm, where do i install plugins such that loggerhead will run them on writes? [02:34] the bzr plugins dir [02:34] how are you running loggerhead? [02:37] lifeless: the init script... runs as loggerhead user [02:37] lifeless: so ~loggerhead/.bzr/plugins ? [02:37] * jdub doesn't like the loggerhead package [02:37] you may also need to be sure you are running 'bzr serve --http', not 'serve-branches' [02:37] the former will load all plugins, the latter *may*, and I'd need to check to be sure. [02:38] s/bzr/bazaar/ <- oops ;) [02:39] lifeless: hrm, then using loggerhead as a plugin? [02:40] lifeless: serve-branches does load plugins [02:41] spiv: good to know [02:42] jdub: I hope to convince beuno to delete serve-branches soon [02:42] only need one 'serve' command. [02:42] spiv: so my expectation that it'd load them from ~/.bazaar/plugins of whatever user loggerhead is running as would be right? [02:42] yes [02:42] or the global python install dir [02:43] and you can add paths via BZR_PLUGINS_PATH [02:43] whihc makes the loggerhead package SPECIAL [02:43] It does? [02:43] jdub@whitlam:~$ getent passwd loggerhead [02:43] loggerhead:x:109:117::/:/bin/false [02:43] \o/ [02:43] jdub: put them in e.g. /var/lib/loggerhead/plugins [02:43] and export BZR_PLUGINS_PATH=/var/lib/loggerhead/plugins [02:44] perhaps the best thing to do would be BZR_PLUGINS_PATH=/var/lib/loggerhead or whatever in the init script [02:44] ha ha [02:44] we are FHS TO THE MAX, man [02:44] submit a package patch to do that ;) [02:44] yeah, but now i'm looking more closely at bzr serve [02:45] does --http only work when bzr finds loggerhead? [02:45] yes [02:45] loggerhead provides --http [02:45] right [02:45] svn should provide --svn, but I don't know if its glued in yet [02:46] will other parameters be passed through automagically? ie --use-cdn [02:46] It would perhaps be nice to have something simple builtin for --http, but if loggerhead is easy enough to install then it's probably not a big deal. [02:46] spiv: I'm very keen on not building in a non-loggerhead http [02:47] spiv: I think discussions about doing that have been missing the point :) [02:47] lifeless: that wold be nice [02:47] jdub: No. [02:47] AfC: --svn? [02:47] jdub: That's basically the reason to still keep serve-branches around for now. [02:47] lifeless: non loggerhead --http [02:47] [battery change [02:47] AfC: why? [02:48] Peng_: particularly since the use of libjs-yui doesn't actually work ;-) [02:49] Peng_: ah, plus, no way to provide a prefix [02:50] jdub@whitlam:~$ bzr serve --http --allow-writes --port 8000 --directory /srv/whitlam.crikey.com.au/code/ [02:50] ... [02:50] File "/usr/lib/python2.5/site-packages/bzrlib/registry.py", line 183, in get_prefix [02:50] Hi, I was wondering if someone could help me with a small bzr problem. I merged 2 branches. There was a conflict in 1 file. I bzr rm'd the folder that contained that file, and now I can't commit (bzr says conflicts still exist). [02:50] if fullname.startswith(key): [02:50] AttributeError: 'LocalTransport' object has no attribute 'startswith' [02:50] jdub: please file a bug on that [02:51] bzr resolve gives an error saying: "bzr: ERROR: The file id "....." is not present in the tree cszikszoy: bzr resolve --all [02:51] lifeless: will do [02:51] cszikszoy: and file a bug please [02:51] lifeless: against? [02:51] bzr itself [02:51] jdub: loggerhead, for now. [02:52] ok [02:52] lifeless, great, thanks very much! [02:55] lifeless: yeah, I'm certainly not keen on bringing yet another underpowered, buggy HTTP server into the world :) [02:56] lifeless: I can see how it might be convenient from time to time... but I think I'd rather put effort into making loggerhead smoother. [02:56] same [02:58] http://code.google.com/p/magnum-py/ ? [02:58] god no [02:59] -1 point, terrible pun name [02:59] oh, liux specific :-(, not really embeddable [02:59] (I'll get my coat) [03:00] for starters, python 2.6 minimum [03:00] and multiprocessing is *slow* [03:00] (the module) [03:00] is it? I was curious about that [03:00] we already have http servers in the code base too, for testing [03:00] there is a tolerable http server in the standard library [03:01] lifeless: looked at unicorn? [03:01] nope [03:01] lifeless: http://unicorn.bogomips.org/ (ruby, but interesting to read) [03:02] * mwhudson keeps meaning to investigate spawning seriously for loggerhead [03:04] mwhudson: please don't, I've seen one have lots of fallout from spawning [03:05] lifeless: btw, here's something a bit amusing [03:05] yeah, spawning sucks. looking at you, spiv. [03:06] jdub: 'serve fast clients on low-latency, high-bandwidth connections' [03:06] lifeless: we recently pointed out an error in the way our mortgage interest was being calculated by our bank (they weren't applying an offset account the way we had asked them to) [03:06] jdub: e.g. 'unsuitable for use on the internet' [03:06] lifeless: it also says that. :-) [03:06] spiv: nice catch [03:06] lifeless: the bank checked their records and agreed, so they had to fix the history of our account [03:07] lifeless: unicorn is designed to sit behind nginx [03:07] lifeless: it turns out they don't rebase ;) [03:07] (or something else, but they're close cousins) [03:07] spiv: so you got a single adjustment ? [03:08] lifeless: so the statement for the mortgage now has all the original interest and payment transactions, plus a bajillion new transactions, backdated, that undo those individually, and individually reapply the right amounts [03:08] jdub: squid won't [without a rather ugly hack I don't think I landed in trunk] buffer full responses [03:08] lifeless: on top of the existing history [03:08] jdub: unless they are tiny [03:08] lifeless: which certainly makes for a confusing read, but the original history is intact ;) [03:08] spiv: nice [03:08] spiv: they can't rebase, its the law :) [03:09] Right. [03:09] Still, it would be nice to have a view of the history "as it should be" as well as "how it ended up being recorded" [03:09] But they don't provide the tools for that. [03:10] true [03:10] jdub: spawning is certainly slow~! [03:11] [======= ] download in progress [03:11] there is a maternity t-shirt with that on it [03:11] lifeless: from thinkgeek, yeah :) [03:11] spiv: yeah, i think about starting, but "want! now!" impatience gets in the way [03:12] it would rock if they sold three or four versions [03:12] jdub: and thus, Po [03:12] lifeless: or a little extendy piece of fabric [03:12] hmm. [03:12] probably going to have shirt size problems. [03:12] separate shirts == better. [03:13] howdy. i'm trying to "bzr svn-import https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd", but it crashes bzr [03:13] yes [03:13] lifeless: adult size, puppy brain! [03:13] he's 23kg now [03:13] 6 when we got him [03:13] jdub: nice [03:13] piem: with a memory error, or something else? [03:13] piem: details are needed, my telepathy is broken [03:14] ok, i'll reproduce again. got than on osx, now back on debian unstable, and got the same [03:14] he's currently chasing horse flies in the loungeroom... chaos. [03:15] $ dpkg -l bzr | tail -1 | awk '{print $3}' [03:15] 2.0.1-1 [03:15] $ dpkg -l bzr-svn | tail -1 | awk '{print $3}' [03:15] 1.0.0-1 [03:16] now running the import, it will take a while... [03:16] piem: a pastebin of the error would be helpful [03:17] spiv: yep, preparing that... [03:17] jdub: Waitwaitwait, I just fixed that LocalTransport bug in the trunk a couple days ago. [03:17] Peng_: oh! loggerhead trunk? [03:17] jdub: Yah. [03:17] Peng_: win! :-) [03:18] jdub: also, loggerhead trunk has my fix from yesterday I think [03:18] looks like i'll have to start running loggerhead trunk ;) [03:18] yayayay [03:18] jdub: (and bzr trunk now has the fix for the other issue I bumped into too) [03:18] spiv: whats a test that will run only_raises [03:18] spiv: Yes, it does. [03:18] not quite so interested in running bzr trunk ;) [03:19] http://pastebin.com/d47582967 [03:19] jdub: Why not? [03:19] (it appears this loggerhead adventure has been fruitful!) [03:19] lifeless: test_decorators has unit tests for it [03:19] Peng_: happy to run 2.0 on production machine via ppa, but not quite so keen on bothering with trunk ;) [03:19] jdub: Bazaar's trunk is just as reliable as the releases. [03:19] piem: either a sf operation issue, or a bzr-svn bug; start by filing a bug on bzr-svn please [03:19] jdub: Plus, there's a nightly PPA, so you don't even have to build it yourself. [03:19] lifeless: or if you mean indirectly, any test that invokes unlock on a Repository or Branch [03:20] Peng_: mmm, our trunk is pretty damn good [03:20] Peng_: but even so it's not *quite* as reliable as releases [03:20] lifeless: https://bugs.launchpad.net/bzr-svn/+filebug ? [03:21] spiv: The only major breakage I remember is all of the fallout back when packs were added, and that made it into the releases. :P [03:21] piem: yep [03:21] spiv: But you're right. Still, it's pretty damn close. [03:22] spiv: I sent the contributor agreement email, btw [03:22] Peng_: there have been a few regressions in trunk from time to time that we've been careful to catch and fix before releases [03:22] spiv: Hmm. The 2a fallout? [03:22] Peng_: and occasionally stuff like hpss verbs in one revision of trunk incompatible with an earlier revision of trunk [03:23] spiv: Oh, that's a good point. That did bite me once. [03:23] The main problem with running bzr.dev is keeping all of your plugins compatible. [03:23] piem: The "bzr init" is pointless. [03:23] All the majorest hiccups I remember ended up happening with releases too. [03:24] Peng_: why? [03:24] So maybe it's safer to avoid them and stick with .dev ;) [03:24] Yeah, plugins are really the main practical issue, much more so than our rare regressions. [03:24] Peng_: import does init too/ [03:24] ? [03:24] Peng_: i use bzr-svn quite a bit (working with wordpress stuff) [03:24] just submitted a bug [03:24] https://bugs.launchpad.net/bzr-svn/+bug/457813 [03:24] Launchpad bug 457813 in bzr-svn "bzr svn import crashes" [Undecided,New] [03:25] piem: Well, first of all, teh command you were looking for was "bzr init-repo", not "bzr init". And yes, it does create its own repo. [03:25] jdub: You only have to keep a copy of bzr.dev's bzrlib around for Loggerhead. You don't need to install it globally. Well, you'd have to hack get it into sys.path somehow, but... === Sam__ is now known as SamB_XP [03:25] Just sayin'. [03:26] Peng_: wait, loggerhead trunk requires it? [03:27] jdub: Err, no, not what I meant. I meant that if you wanted to run Loggerhead against bzr.dev, you don't need to install bzr.dev globally. [03:27] jdub: Loggerhead trunk is supposed to be compatible back to...1.13, I think? [03:27] jdub: I don't know if anyone tests it regularly, but... [03:29] right [03:29] yeah, if i don't need to run bzr.dev, i'm not going to bother :) [03:30] Peng_: right. reproduced, the right way :-) [03:30] piem: exact same error? Or does the SVN revision number change? [03:30] and bug report updated [03:32] spiv: exact same error it seems [03:33] jdub: If you want .bzr/smart to work with shared repos, you'll need bzr.dev. Or to backport the patch. [03:33] Or use the monkeypatch I gave him yesterday [03:34] yeah [03:34] Or that! [03:34] Heh. [03:34] I don't want to add the monkeypatch to Loggerhead; there's not a good way to test if the version of bzr.dev being used has the bug or not. [03:35] Peng_: version < 2.1.0b2 would be approximately right [03:35] lifeless: one as in u1? [03:37] in any case, good to know [03:39] spiv: Eh. [03:39] Peng_: I'm not for or against adding the monkeypatch to loggerhead anyhow [03:39] Peng_: just saying :) [03:39] spiv: :) [03:40] I don't _want_ to add it, but I also want Loggerhead to seem less buggy. I'm going with the lazy choice for now. :P [03:40] +1 lazy [03:42] piem: not that it matters a lot, but I don't see your update to the bug report? [03:45] Stupid question: does interning objects keep them around forever or can they still be GCed? [03:48] interning strings doesn't keep them around forever [03:50] spiv: editing the first entry actually failed, resubmitted now [03:51] ISTM _static_tuple_py's interning makes them immortal, though. It just does "adict.setdefault(self, self)" [03:52] Peng_: hmm, perhaps that should be a weakref dict of some sort. [03:53] _static_tuple_c OTOH uses a SimpleSet, and does a decref and has a comment about making sure they're not immortal, so I guess it doesn't? [03:54] static tuple's aren't weakrefable [03:54] though maybe the python version is [03:54] mwhudson: the pure python one is a non __slot__ted subclass of tuple, so it probably is [03:54] (Hmm, adding __slots__ to that is probably a good idea though) [03:54] spiv: i don't think it is actually [03:55] because you can't weakref subclasses of variable sized types i think [03:55] (i tried to fix this once) [03:55] mwhudson: apparently you're right [03:55] That seems like an odd restriction. [03:56] spiv: it's because the location of the weakref list is stored as an offset into the structure [03:56] in something like tuples you'd have to interpret a negative offset as an index from the end of the object [03:56] Ah, hmm. [03:57] (which is how dict is done) [03:57] i can't remember why i didn't fix this, i guess i just ran out of steam [03:57] Another reason perhaps to make the pure python StaticTuple not inherit from tuple [03:58] or make interning a noop [03:58] (the other is that you can't make tuple + StaticTuple give you a StaticTuple) [03:58] (which is an unfortunate difference in behaviour from the C version) [04:00] I don't think it's hugely likely that we'll right code that accidentally depends on "foo = (prefix,) + a_static_tuple; foo = foo.intern()" [04:00] There are probably other subtle differences, features that tuple doesn't implement but StaticTupleC does. [04:00] s/right/write/ [04:00] mwhudson: yes, u1 [04:00] (I'm sure if wrote it we'd right it sooner or later ;) [04:01] lifeless: ugh :( [04:01] lifeless: oh well, i'm glad i can take advantage of their pain [04:02] mwhudson: they may have gotten all the glitches out by now [04:03] but its got a tonne of too-much-magic in it [04:03] such as watching sys.modules contents, which is a terrible idea (apt-get dist-upgrade FAIL) [04:03] E.g., StaticTuplePy.from_sequence supports arbitrary iterables; C requires sequences. [04:03] StaticTuplePy can be subclassed, C cannot . . [04:04] The very basic issubclass(StaticTuple, tuple). [04:33] AfC: why? [04:34] lifeless: you talking about aspiration for a loggerhead-less embedded web server? [04:34] yes [04:35] I said 'we don't want it' and you piped up with 'it would be desirable'... [04:35] so why is it desirable? [04:36] lifeless: well (and this is just my subjective experience, but) LoggerHead has been unbearably slow. [04:36] lifeless: It's user interface is ghetto. [04:36] lifeless: It is almost impossible to find the revisions [and their detailed commit messages] that actually contributed changes as instead presents almost exclusively to the useless left hand edge merges. [04:37] AfC: so, an embedded http server in bzr core would be likely be slower and even more primitive [04:37] lifeless: and I am quite embarrassed that my code is presented by it on the branches that launchpad mirrors. [04:37] lifeless: as may be [04:37] AfC: these are 'things wrong with loggerhead' not 'why there should be an embedded http server in bzr core' [04:38] AfC: For the former, I encourage bug filing! [04:38] lifeless: I've been hacking on a kludgy workaround just using GNU source-highlight locally and then rsyncing up [04:38] for the latter, I'm still at a loss [04:38] lifeless: but a straight forward [a la darcsweb, gitweb] branch navigator would have been lovely. [04:38] I _loath_ gitweb [04:38] its terrible [04:39] lifeless: or whatever they're running on git.gnome.org — people can effortlessly refer to a branch + revision + file + line number combination. [04:39] a Transport should expect to get paths that are utf-8 plain strings and urlencoded, right? [04:39] mwhudson: yes [04:40] mwhudson: or rather no [04:40] mwhudson: urls and relative urls [04:40] lifeless: i mean a transport method like "rename" [04:40] mwhudson: url encoding is not uf8; its a specific defined encoding itself. [04:40] verterok: I got things building, I'll try to package tomorrow [04:40] utf8 is outside the permitted codepoints for urls [04:41] lifeless: yes, it's a succession of things: unicode --(utf-8)--> str --(urlencode)--> ascii-only str [04:41] AfC: you can do that in loggerhead too [04:41] mwhudson: urls don't imply unicode or utf8 at all [04:41] mwhudson: std66 is sadly clear about it being useless this way. [04:41] AfC: I honestly don't see any of that being harder with loggerhead than with what git.gnome.org is running [04:42] lifeless: i'm not talking about urls, i'm talking about bzrlib.transport.Transport methods [04:42] mwhudson: the generator of a url is responsible for getting it into url form, and noone else is permitted to try to decode it. [04:42] mwhudson: so am I [04:42] except *perhaps* the browsing for branches part [04:42] mwhudson: they take relative url references [04:42] spiv: I couldn't say why, to be honest. I'm just giving you the result of my experience working with both that cgit is a) not slow and b) way easier to use. [04:43] But certainly once you're looking at a branch it's essentially the same, except it takes me one less click with loggerhead [04:43] AfC: its fast, I'll give you that. Thats something loggerhead can improve at - it should be faster with 2a branches anyhow. [04:43] AfC: can you describe /how/ cgit it easier to use? [04:44] I know I find 'blob' links a bit of a mindfuck [04:44] lifeless: the concrete problem i have is that "bzr push bzr+ssh://bazaar.launchpad.dev/~mark/+junk/bé" causes a server side exception [04:45] (that was a utf-8 string if irc's unhelpfulness on this topic defeated things) [04:45] mwhudson: ok. So the client should be encoding that, and here is where std66 fucks us, we guess at utf8 for the native encoding of the far end [04:45] lifeless: right [04:46] so you'll have argv[2].decode(console_encoding).encode('utf8').urlencode() [04:46] and then pushed over the wire [04:46] whats the server side exception? is there a bug? [04:46] lifeless: the bug is https://bugs.edge.launchpad.net/launchpad-code/+bug/449528 [04:46] Launchpad bug 449528 in launchpad-code "lp: resolution for non-ASCII name oopses" [High,Triaged] [04:46] well, ish [04:46] AfC: hmm. Well, if you figure out why it feels nicer to you at some point then please do file a bug or post about it. From what I can see loggerhead's UI actually is simpler for this, but I realise UI issues can be pretty subtle. [04:46] the exception in that report is in the lp-resolution [04:47] mwhudson: is there a stock test double for launchpad, for using in code that wants to talk to launchpad [04:47] lifeless: no [04:47] it would be hard to make a generically useful test double that was much less complicated than launchpad i think... [04:48] a fixed definition of apis would allow that to be programmtically generated [04:49] lifeless: the exception is actually in the implementation of the xml-rpc method that we call to interpret paths [04:49] spiv: I don't know. I've just spent the last 5 minutes trying to find loggerhead of bzr on launchpad. I really don't have any more time, so I'm sure you'll dismiss this feedback as whinging. Pity I can't be more specific. At least my objection to Bazaar Explorer is simpler to articulate. [04:49] mwhudson: it would help to have a backtrace in the bug [04:49] lifeless: basically, i think there's a lack of understanding of unicode paths all through the code, so i want to figure things out starting at the beginning [04:49] AfC: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ [04:50] mwhudson: we try for crunchy shell there [04:50] spiv: [thanks; that wasn't anywhere obvious on the bling new website] [04:50] AfC: now, if your problem is with Launchpad's UI for browsing branches rather than loggerheads, that makes more sense to me :) [04:51] spiv: aren't they the same? [04:51] AfC: bzr lp-open lp:bzr, and click on 'view the branch content' [04:51] lifeless: i'm implementing a transport, i'm part of the shell, surely? [04:51] AfC: god no. [04:51] AfC: I mean, for browsing through the set of branches that are available [04:51] mwhudson: gimme a backtrace, I'll try to help :) [04:51] really? Well, launchpad is what everyone I talk to thinks loggerhead is [04:52] s/launchpad/launchpad's pathetic attempt at branch, revision, and code browsing/ [04:52] AfC: the url spiv gave you is loggerhead [04:52] lifeless: you've already answered my question enough i think [04:52] AfC: as opposed to what loggerhead provides to Launchpad, which I just gave you a link to [04:52] AfC: (And is where the "browse the source code" link on https://code.launchpad.net/bzr will take you) [04:52] mwhudson: ok, well I'm happy to look more closely if you like. [04:52] it would be a pleasant distraction from deciding how untested I can bear this ppa watcher to be [04:53] lifeless: thanks, i'll come back if i have more questions [04:53] Crap, I just let a traceback get word-wrapped by my email client. :( Should I resend a fixed version, or do you guys usually just suffer through mangled tracebacks? [04:53] AfC: so if the difficulty you have is with finding a branch in the first place, that's purely Launchpad. [04:53] So here I am, trying to find the revisions that led to revno 4753. Click on the expander, and all I get is more details about some guy named "Canonical.com Patch Queue Manager" who write some code [04:53] Peng_: they are generally decipherable anyway [04:54] oooh [04:54] bleeping xmlrpclib strikes again [04:55] i expect [04:55] AfC: ah, fair enough. The link "(4752.2.1 integration)" with the crossed arrows icon takes you to the other parent revision [04:55] Four pages later I finally find my way to a page that has a link that turns out to be http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4752.1.1 that finally has the commit message that Vincent wrote. [04:56] AfC: but I think a way to see all the revisions that were merged into mainline at that point is lacking [04:56] abentley, I see you're away and stuff... but I'll be in Toronto this weekend for OLF. We're going out for dinner on Friday if you're interested. [04:56] in little itty bitty type [04:56] * spiv takes some notes [04:56] (Everyone else is invited too... if you can make it up to Canada) [04:56] spiv: yeah, you know, like, say, `bzr viz` [04:56] aaaaaaaaaaa [04:57] * spiv nods [04:59] oh, that's brilliant... from that page, click on "view branch changes" which is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/4752.1.1?start_revid=4752.1.1 and then get another useless left hand edge history. Squint hard, and we'll see our revision at the top. [04:59] * emmajane chuckles. [04:59] spiv: so... here I am, having spent about 4 times longer on evaluating this than most people, [and lord knows I'm predisposed to at least try and figure it out] only to be frustrated, puzzled, and then ultimately profoundly depressed. [05:00] spiv: maybe this makes perfect sense to someone who understands the Zen Of LoggerHead [05:00] AfC: Thanks, this is useful feedback. [05:01] So, I think Loggerhead currently does a very good job with the left-hand history. [05:01] spiv: but I've got to admit as someone who has a reasonably sophisticated (if outsider) knowledge of Bazaar and it's culture [and more to the point, basis] that I have absolutely no idea what that tool is presenting, other than knowing that it's [05:01]