[00:04] poolie, spiv: call on today? [00:05] igc, yes, but i can't get in [00:06] still trying [00:06] poolie: I'll hang up in case that helps [00:07] * spiv hangs up too [00:07] jelmer: ping [00:08] poolie: I got straight back in ok [00:08] is it your local phone maybe? [00:12] it might be my phone [00:12] when i tried i got through to varying extents [00:12] anyhow [00:13] let's just catch up here on irc? [00:13] Sounds good. [00:13] me too [00:13] so i think the PPA stuff is all settled now [00:14] today, I'm planning to review patches, particularly the xml8 serializer one [00:14] i'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking [00:14] I need to learn more about that so reviewing that patch will help me [00:15] i'd like to suggest the whole project do a bug day tomorrow, will send mail about that [00:15] also i seem to have some Ubuntu bugs atm [00:15] so will file them [00:16] poolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak [00:16] i'll do that [00:16] thanks [00:17] also when lifeless is back i'll call him re his conference submission [00:17] and i owe thumper a call or sketch of the branch listing page [00:17] if you get a chance, I'd like some feedback on my hook patch/rfc too [00:18] I've sent off the core bits of the fix for bug 207558. I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done. [00:18] Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/207558 [00:18] ok [00:18] i'll try to read that for you spiv [00:18] what is next for you? [00:18] So today will be mainly server-side hooks. [00:20] poolie: another thing for me today - kill & resume the OOo import [00:21] it's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow [00:22] I took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps [00:31] ok, good [00:39] igc: We should find what the cache was masking and fix it. [00:44] igc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer [00:45] igc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist. [00:46] lifeless: maybe. commit-builder currently does things much slower than the importer does [00:47] it simply can't make some of the assumptions than an importer can [00:47] which make big differences to speed [00:48] igc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be. [00:48] igc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :> [00:48] I'm going to do a couple of spikes today [00:48] and get back to VF this afternoon [00:50] I chatted with benno last night about python performance [00:50] and he concurred with my import analysis, gave some commentary on os call performance readdir etc [00:50] so I'm going to do this long threatened import hook [00:53] lifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time). I'll be interested to see if the reality is different. [00:55] spiv: strace doesn't show how much time python spends marshalling [00:55] spiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook [00:59] holy cow 'import bzrlib' hits a lot of shit [00:59] 34 modules [00:59] yes, i know [01:00] many are demand load stubs I think [01:00] or something strange [01:01] -weird [01:01] >>> type(sys.modules['bzrlib.struct']) [01:01] [01:02] That's expected. [01:03] When a module inside the bzrlib package tries "import struct", python first treats it as a relative import. [01:03] And when an import fails, it caches misses as well as hits in sys.modules. [01:03] ah good [01:04] (Bring on python 2.5...) [01:04] 12 real modules imported then [01:20] lifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev. (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...) [01:21] (as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)") === mwhudson_ is now known as mwhudson === kiko is now known as kiko-zzz [01:27] spiv: what does your faster-startup branch do ? [01:27] spiv: (I am only planning to alter the behaviour of bzrlib specific imports) [01:28] lifeless: basically, various hackery to defer unnecessary imports [01:28] (or avoid) [01:29] lifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get. [01:30] has anyone tried running freeze on bzr ? [01:30] Oh, and specifically also reducing the amount of the universe that "import bzrlib" imports :) [01:30] e.g. making *everything* import and running freeze [01:31] spiv: so my thesis is that we should make importing everything fast === bigdo2 is now known as bigdog [01:31] because in the general case most of the code is needed [01:46] spiv: what do you mean about 2.5? [01:46] i don't think he meant 2.5 [01:47] at some point, imports written the normal way will be absolute [01:47] which means less looking for things like bzrlib.struct [01:49] I meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html [01:49] 2.5 introduces "from __future__ import absolute_import" [01:50] oh, heh [01:50] shows when i stopped paying microscopic attention to python development [01:54] damn, pkgutil doesn't exist in 2.4 [02:08] so, I'm saving 130/4900 open calls [02:08] all of which look like failures [02:18] question, how do I change the "parent branch" of a branch? [02:19] igc, is there a BB enttry for the patch from james_w you mentioned before? [02:20] igc, i take it you were referring to the one to give a warning when getting a readonly transport? [02:20] poolie: that's right [02:21] * igc looks [02:21] http://bundlebuggy.aaronbentley.com/request/%3C1205831646.7247.295.camel@flash%3E [02:21] poolie: ^^^ [02:22] thanks [02:23] LaserJock: pull --remember [02:26] lifeless: awesome [02:35] * igc lunch [02:46] * mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes [02:51] mwhudson: there was a thread about that on the list recently [02:51] mwhudson: it shouldn't complain, IIRC [02:51] there was? must have missed that in my catchup [03:04] mwhudson: it should tell you, and take your changes as part of the merge [03:04] mwhudson: IMO [03:06] i guess that makes sense [03:14] ok, I now have my code being called consistently [03:21] lifeless: well, I'm not convinced. [03:21] It's not a very accurate preview that way. [03:21] abentley: why is it less accurate? [03:23] because merge won't make any of those changes. It will barf. [04:07] abentley: thanks for the review ofthe help change [04:07] np [04:08] Something else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca [04:09] Even though those algorithms handle criss-cross better. [04:10] So perhaps it should say not to remerge if you're already using --lca or --weave. [04:10] so would you overall suggest using remerge, or revert and merge again? [04:13] back in a few minutes; getting lunch [04:24] poolie: I'd suggest revert and merge. [04:25] Fewer commands to learn that way. [04:29] abentley: when is remerge a good thing to learn and use then ? [04:30] I generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can. [04:31] If there are basic, intermediate, and advanced commands, I'd consider it intermediate. [04:31] ok [04:31] one thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down. [04:31] I think we may have something similar here. [04:32] that is basically when i use remerge too [04:32] rarely on the whole tree [04:33] could we at least make it fail safe on looms - like give an error rather than mess things up? [04:34] lifeless: are you familiar with the problem? [04:35] abentley: no, I've never used remerge like that [04:35] oh, you mean with looms - I've seen the bug report [04:36] So the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent. [04:37] but with up-thread, it is actually the rightmost parent. [04:37] I think the things are about-face for performance [04:37] I didn't want to transform; then merge [04:38] I'm not sure your approach is wrong. A different approach might lead to more conflicts. [04:39] its on my long todo to teach bzr's merge the ability to be told different file suffixes [04:40] so we can drop the 'right files' in the right places [04:40] and give better herringbone labels [04:40] You'd also want to swap the conflict markers. [04:40] :-) [04:40] I'd actually like to call them by their thread names [04:40] Speaking of merge, did --reprocess stop doing its thing sometime? Or did it just never really cut things down a lot? [04:40] Sure. [04:41] fullermd: I think it became default [04:41] abentley: could you suggest some better help text? [04:41] should we say "use remerge FILE, or revert and merge again?" [04:42] Let's say "revert and merge again". [04:42] lifeless: So we understand the problem-- is there a short-term fix we can do like poolie suggested? [04:43] fullermd: I don't think it became the default. But it only helps a narrow class of merges, and only applies to --diff3 [04:44] lifeless: The problem so far is that we can't even tell that the merge was different. [04:45] I've got kernel configs in bzr to easily merge upstream changes, and every time I do (last was some months ago), I get hyuge spurious conflicts that it doesn't help. === mw is now known as mw|out [04:53] fullermd: line endings? [04:53] No, but changes in single lines ended up resurrecting giant blocks that I'd deleted. [04:53] Imagine we pushed some changes for April Fools day. Like, 4 revisions. What would the easiest way, hypothetically, to check an older revision to head? [04:54] I guess it's some artifact of the diff hunk for the revs where I whacked the blocks. [04:55] awmcclain: bzr push -r NNN --overwrite [04:55] awmcclain: (NNN == -4, I guess...) [04:55] spiv: And if it's a bound branch, can we do bzr ci -r NNN --overwrite? [04:56] fullermd: I'd normally offer to help, but I'm behind already. [04:56] awmcclain: ah, with a bound branch, use uncommit [04:56] spiv: 4 times? [04:56] awmcclain: which also takes a -r arg. [04:56] Or just run it 4 times, sure. [04:56] spiv: Gotcha! [04:56] Or just pull -r-4 --overwrite . [04:56] fullermd: heh. [04:56] fullermd: pull overwrite affects master branch :) [04:57] abentley: *shrug* It's not that big a deal. Bugs me for 30 seconds or so a couple times a year when I do it. Hasn't been a high enough priority for me to build up a test case for it. [04:57] fullermd: You might try --lca. It's kinda got --remerge built in. [04:57] s/--remerge/--reprocess [04:58] Last time I tried was probably pre-lca; I tried both diff3 and weave, with/out reprocess; came up the same every time. [04:58] But if I want to commit _over_ the current changes, not remove them.. could i bzr revert -r NNN then ci? [04:58] I'll try getting creative next time it comes up. [04:58] awmcclain: right [04:59] abentley, BB seems to be stuck, can you whack it? [05:00] poolie: did it give you a lock error? [05:01] abentley: I'm currently getting 502 Proxy Error [05:02] "Reason: Error reading from remote server" [05:04] abentley: me too [05:04] " The proxy server could not handle the request GET /." [05:05] I have increased the database timeout to unreasonable levels. [05:05] So there's an active lock, but I'm not sure whether it will resolve itself. [05:06] The last time I got a 502, it did. [05:07] same [05:07] you're using sqlite right? [05:07] Okay, whacked. [05:07] lifeless: right [05:08] there is something funny in the python bindings AFAICT [05:08] sqlite3? [05:08] abentley: how about this: [05:08] In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give [05:08] better results. You may wish to `bzr revert` the working tree and merge [05:08] again, or use `bzr remerge` on particular conflicted files. [05:09] i feel kind of reluctant not to mention remerge because it's what i usually run myself [05:09] i see your point though about involving less commands [05:09] Okay, fair enough. [05:09] and if they did help criss-cross just after the failure they will not lose anything [05:09] Perhaps we should omit the revert; remerge thing. [05:09] Pardon? [05:10] lifeless: Any suggestions on a band-aid for up-thread? [05:11] abentley: w.r.t remerge ? [05:11] Yes. [05:11] I don't think there is a good band-aid; I think it just needs the bzrlib work done. [05:11] """In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give [05:11] better results. You may wish to `bzr revert` the working tree and merge [05:11] again. Alternatively, use `bzr remerge` on particular conflicted files. [05:12] "'" [05:21] * poolie reads fix for 207558 [05:23] poolie: call ? [05:23] in 6m? [05:23] sure [05:38] poolie: re that TT bug, it's due to adding a file to a deleted directory, when the deleted directory was the root directory. [05:39] ! [05:39] ok [05:40] spiv: ping [05:40] Anyhow, now that I can reproduce it, it shouldn't be a hard fix. [05:40] I have a 'wtf' moment with my import hook [05:41] lifeless: your phone's engaged? [05:41] its trying to import 'debian_bundle' from '' in the Numeric path path_hook object [05:41] poolie: no?? [05:44] lifeless: pong [05:44] does Numeric do crack? [05:59] lifeless: I don't know if Numeric does crack or not. [06:00] beuno: around? [06:13] spiv: you have mail [06:13] spiv: should be self evident if you want to apply it to bzr.dev and play [06:14] spiv: I get quite reduced syscalls with this but its buggy :/ [06:38] lifeless: bzr-gtk has now been updated so that it functions correctly with my bzr-dbus patches, btw [06:39] they're waiting on you for review though. [06:40] thanks [06:51] abentley: bb seems to be wedged again === mwhudson_ is now known as mwhudson [07:34] lifeless: regarding loom-specific conflict markers, please be sure you won't break external tools that are looking for them (i.e. may be *add* thread name after the usual markers instead of replacing MERGE-SOURCE and/or TREE) [07:52] Want to make $$$ just by clicking? Sign up on http://bux.to/?r=eg0trip, and begin recieving checks! [07:54] no thanks [07:54] yes you do [08:04] lifeless: still around? [09:03] dunno who egotrip was, but we don't want spam here. [09:08] He didn't explain himself very well, certainly. I kept clicking, but I got @@@ instead of $$$ :| [09:15] and I'd prefer to receive cheques rather than checks [09:30] Hmm, how can I force a baseless merge with bzr? [09:32] jelmer: ping [09:32] schierbeck: I second that: ping jelmer [09:32] :) [09:32] schierbeck: what's it for you? In my case bzr-svn seems to have forgotten about branch relationships ;( [09:33] tough luck [09:33] nah, i just want him to give his 2 cents before i send in a merge request [09:34] yacc: merge -r1..-1 [09:35] james_w: is that a good idea, considering that the branch contains the same revisions as the remote one? (bzr just seems to think that they are unrelated) [09:35] yacc: probably not [09:35] how did you create your local branch? [09:35] bzr branch svn+https://... [09:36] from the same branch you are trying to merge now? [09:37] Look at: https://bugs.launchpad.net/bzr-svn/+bug/210705 [09:37] Launchpad bug 210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] [09:37] james_w: but basically yes. [09:38] james_w: => it remembers where it pulled from, and pushed to in the past. [09:38] james_w: just when doing a merge it complains about being unrelated. [09:38] Oh, bzr missing lists all revisions as missing on both sides, plus the one that I did commit locally, which is only listed on one side. [09:39] but the merge did not help anything, it still misses 3/4 revisions ;( [09:40] james_w: despite the above merge -r1..-1, it still claims that the branches are diverging. [09:40] yacc: can you pastebin a bzr missing --show-ids [09:40] james_w: just a moment, first I'm curious ;) [09:42] james_w: they don't match :( [09:42] http://rafb.net/p/a1aZXh19.html [09:43] james_w: guess that is what jelmer meant with the ids can change? [09:43] jelmer!!!!!!!!!!!!!!! [09:43] they don't match is the reason that you are seeing this issue. [09:43] calm down, he's been highlighted, if he's around he'll see it [09:44] james_w: yeah, BUT: I had to change the scheme to include new trunks [09:44] revision-id: svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56 [09:44] revision-id: svn-v3-list-QlpoOTFBWSZTWYDqAEcAADdRgAAQAAK3r94gIABISkMo0zUaemoEkkaZMAm1IM83f4FQYGxfzVWsvATONoa96yIoS8IEx1BxVRIGB_MCYIMwX5NxaET_F3JFOFCQgOoARw..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:56 [09:45] see the base64 encoded list of paths <= I had to change that to accomodate a new branch. [09:45] you changed the svn branching scheme? [09:45] james_w: list-path1-path2 => list-path1-path2-path3 <= I had to add path3 because it's a new branch I need access to? [09:47] james_w: basicaly the revids for branch X contain the a list of all other branches that I'm accessing in the given SVN repo. [09:48] james_w: Hmmm, I think the fix would be to make bzr-svn use svn-v3-list-$PATH_USED_IN_THIS_CASE instead of svn-v3-list-$PATH_OF_THE_COMPLETE_SCHEME? [09:50] james_w: Any explanation what the different branching schemes are good for? [09:53] yeah, so it's caused by the change to the branching scheme [09:54] the scheme is to tell bzr-svn which paths in svn to consider branches [09:56] yeah, but the problem is, appending one new "path" in the repository is a quite expected thing to do. [09:56] It should not break all branches/checkouts in the wild, just because I need to track one additional location? [09:57] yacc: add this information to the bug report. [09:57] Already done so. [10:00] james_w: single would mean that I can only access exactly one path inside the svn repo? [10:00] I think so [10:01] Hmmm. [10:01] So basically I would need to parametrize the "schema name for property name" lookup thing. [10:02] It basically needs to take the URL being accessed into account ;( [10:06] * yacc wonders what the schemes are good for at all? [10:10] james_w: I'm hoping to review that gnome bug tracker patch tomorrow [10:10] if you put through abentley's tweak tonight, that would be nice ... [10:10] though I realise you may not have time [10:10] I'm heading off now [10:10] night all [10:11] igc: thanks, I'll try and get to it. [10:11] night [10:13] lifeless: ping [10:22] jelmer: ping [10:27] jelmer: would it be ok by you to implement a "EveryPathIsABranchScheme"? [10:40] Hello, when using bzr, can't I checkout just a single folder instead of the whole branch ? [10:41] right, you can't [10:41] bzr can only work with whole branches [10:42] unlike svn [10:43] svn doesn't have branch :) [10:43] *branches [10:44] luks: and branches is (almost) all that bzr has ;) [10:44] How do I make bzr send my local commits as a patch to the maintainer? [10:45] bzr send [10:46] I just discovered that just switching schemes won't work => the svn repos contains pointers to the old scheme name, ... [10:47] My only hope for a sane scheme is rapidly crashing. [10:51] jelmer: ping [11:05] I am trying to convince a colleague to use bzr for our collaboration. However, he has a mac OSX 10.4 intel. Is there a ready to use disk image for that machine ? [11:13] there's a macport I think [11:18] New bug: #210665 in bzr-svn "bzr svn-import fails" [Undecided,New] https://launchpad.net/bugs/210665 [11:20] New bug: #210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] https://launchpad.net/bugs/210705 [11:21] New bug: #210723 in bzr "Some tests failed when selftest is invoked with -v" [Low,Confirmed] https://launchpad.net/bugs/210723 [11:22] yacc: pong [11:23] yacc: EveryPathIsBranchingScheme will be incredibly slow [11:24] jelmer: why? [11:25] jelmer: and it misses to_list, which makes --set break, but I guess it breaks for other schemes too. [11:25] yacc: When searching for revision ids, bzr-svn checks every possible branch path for properties [11:26] Well, it seems the that list paths get embedded in the properties somehow, so just doing a fresh branch with the ammended paths is not an option either. [11:26] in the case of EveryPathIsBranchingScheme that means one call per file/directory in the remote repository [11:27] And let me guess it does not cache the results in any way ;) [11:27] it does cache the results [11:27] but that's still too slow [11:28] brb [11:32] so how to fix the list scheme then? [11:34] how do you mean? [11:52] Well, the list scheme embeds the paths in the revision stuff. [11:53] Meaning that when somebody adds a new path (because a new path got added), bzr-svn implods. [11:53] jelmer: : #210705 [11:54] jelmer: easy to demonstrate: with a branch that uses a list scheme, add another path to the list => et voila, bzr thinks that the svn remote branch and your local bzr branch do not share any history. [11:54] Which is wrong. [11:55] Considering the fact that some svn users use very very creative directory setups, ... [11:55] yacc: that's correct because they have a different branching scheme [11:55] Ok, so how do I handle the case that my upstream project just got a new subproject? [11:55] yacc: What you really want is a fix for bug 130372 [11:55] Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 [11:55] yacc: you can use wildcards in listbranchingscheme [11:56] jelmer: Only if I would have started with wildcards. Take a look at the later comments in 210705 and you'll notice that it seems impossible to switch the scheme for a given repo and recreate the bzr branch [11:57] yacc: yes, that's correct [11:57] yacc: that's why there's bug 130372 [11:57] Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 [11:58] so what do I do? write myself scripts that replace ~/.bazaar/subversion.conf based on the directory I'm in when calling bzr? [12:00] yacc: The error fetching after changing branching schemes is a bug [12:01] So I open up a time loop window, and go studying the source code to fix that bug? <= I mean the scheme is part of the revision IDs? [12:05] Serious, new bug or known bug? [12:06] yacc: the branching scheme is part of the revision id [12:06] yacc: that's bug 130372 I mentioned earlier [12:06] Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 [12:07] jelmer: 130372 is not about a bug fix, it's about joined branches, right? Meaning that you could drop to supporting only trunk/none for bzr-svn and make the people use split out parts of these repositories, right? [12:08] yacc: no, it's about abandoning branching schemes completely [12:08] as soon as by-value branches are supported [12:09] well, replacing branching schemes with a "repository layouts", which are not included in the revid [12:11] So nothing simple for a newbie that has only a limited understanding of bzr internals might want to tackle ;( [12:13] yacc: not really, though it should be possible to get that "not present in "... error fixed [12:13] I'll see if I can fix that [12:14] hey everyone, the docs on this function are a little bit unclear in what order the branch and tree objects are returned [12:14] http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_tree_or_branch [12:14] I think it is mentioned at the end, but I am still unsure [12:15] rexbron: tuple with tree and branch [12:15] jelmer: K, it mainly that the other funtions make that more clear [12:16] the first sentence should be fixed then [12:17] How do I undo local commits? [12:17] yacc: bzr uncommit? [12:17] or revert [12:18] bob2, jelmer: I think it should be changed to something like the method below: Returns (tree, branch) [12:18] famen [12:18] tr -d f [12:19] yacc: in bzr.dev, "bzr uncommit --local" [12:19] I don't think that's in a release yet, though :( [12:19] spiv: Well, uncommit seems to have worked :) [12:19] rexbron: tree will be None if there isn't one if you hadn't figured that out yet. [12:20] yacc: oh good :) [12:20] james_w: I think I need to refresh exactly what the difference between a branch on the file system and a workingtree (beyond different methods for those objects) [12:20] rexbron: i see ":return: (tree, branch)" for that method [12:20] rexbron: you can have a branch with no tree [12:20] i.e. you have .bzr/branch/ [12:21] but there are no files in the working directory, and there will be no .bzr/checkout/ [12:21] james_w: My comment was that it could be more clearly stated, like in the other functions [12:21] james_w: ok [12:21] you can get this with bzr remove-tree, or with a treeless repository [12:21] james_w: the furst sentence says the opposite, and I don't think it's unreasonable to assume that it should be correct also :-) [12:21] and it will also happen for remote trees. [12:21] bob2: that's true [12:21] rexbron: that is markup that used to denote the return value. [12:22] james_w: is the doc system supposed to format it differently that it currently is? [12:22] ah, it appears to be spelt wrong, as other functions have it formatter === mrevell is now known as mrevell-lunch [12:23] see open_containing_from_transport [12:24] http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_repository seemes to also have a formatting issue [12:24] for :param _unsupported: [12:26] now that I look for it, I see a lot of method docs that are (perhaps) not formatted correctly [12:26] yeah, they do seem to be a bit bad. [12:27] the API documentation is very hit and miss [12:29] james_w: what system is being used, as I would be happy to submit patches [12:30] ok, looks like pydoctor [12:31] is mail from the bazaar list getting doubled up? [12:32] :) [12:33] sabdfl: I don't see it, you mean you receive multiple copies? [12:34] Is there a page which documents the syntax for pydoctor? or is it the same as something else? [12:34]