[00:10] poolie: Hey there. Did you want to talk about loggerhead now? I'm available. [00:10] mkanat: hi, i'm back [00:11] btw i'll be offline tomorrow, and possibly not on irc friday [00:11] i mean thursday [00:11] australian time [00:11] Okay. [00:11] Ah, well, removing the revision data by default from the file inventory. [00:11] what does that mean? [00:11] poolie: So, one thing that I have pending is the raw view. [00:11] poolie: That's something that will probably benefit LP, somewhat. [00:12] poolie: Ah, when browsing a branch using /files, it shows you the revision and last-modified date of every file. [00:12] poolie: I believe (although I'd have to check) that we're generating that data from the branch history cache. [00:12] the raw view would be nice [00:12] poolie: If we don't have to use a branch history cache at all on the most common page views, we should be able to get an impressive performance and scalability improvement. [00:12] right [00:13] it's kind of useful, but not necessarily worth it [00:13] could we put make that configured off, rather than just deleted? [00:13] poolie: Yeah, I'd put a link on the page to show the info. [00:13] hi, wiki.bazaar.canonical.com/MacOSXDownloads points to a wrong place fort the 2.2.2 stable download [00:13] poolie: So people who wanted to browse with it could, but wouldn't get it by default. [00:14] poolie: It'd be "show revisions and timestamps" as a nav button. [00:14] poolie: Then after that I think there may be additional optimizations I can do on the View controller. [00:14] poolie: And with all of those things, I think that would be the ideal project size for this retainer. [00:14] poolie: I can see all of those going into LP. [00:16] i agree, i think they're really useful and just a good size [00:16] poolie: Okay, great. So the first thing I'd need is a review on the MP for the raw view. [00:16] poolie: BTW, I don't know if you saw my comments here or in the bug, but the raw view renders in about 0.05 seconds. [00:16] poolie: So it's not bzr that's slow. [00:17] i hadn't seen it [00:17] that is interesting [00:17] poolie: Yeah, I didn't email you about my work on the raw controller, because I figured you would have noticed due to the review request. [00:22] * mwhudson wants revert -i [00:22] mwhudson, shelve --destroy IIRC [00:22] james_w: huh! [00:23] ta [00:24] james_w: i'm writing some crazy matchers for linaro-image-tools btw :) [00:24] nice [00:24] you say that before you've seen them [00:24] :-) [00:31] that'd be nice [00:34] poolie: This is the MP I'm blocked on right now: https://code.launchpad.net/~mkanat/loggerhead/raw-controller/+merge/42675 [02:51] thanks mkanat, i'll look now === ubot5` is now known as ubot5 [03:57] poolie: then I'll look at reviewing any loggerhead bits mkanat has that still needs reviewing [03:58] ok [03:58] i was going to pass through that, then restore /home onto my laptop again :/ [04:10] spiv i don't see any other fresh lh mps [04:10] there are stale ones but i think that should wait til someone wants to handle this in batch [04:10] if you have anything to add on xss prevention please do [04:39] Hmm, we have a test that verifies that bzrdir.sprout(url) will copy all revisions in the source repository, even if most of them aren't referred to by the branch at that bzrdir. [04:39] spiv: no [04:39] spiv: thats the branchless case [04:40] lifeless: no, there is a source branch in this case [04:40] hmm [04:40] (at 0/null:!) [04:40] 'odd' :) [04:40] test_sprout_bzrdir_repository_branch_only_source_under_shared [04:40] Yes, I think it's probably a behaviour to change, but it seems intentional :/ [04:40] what did my commit message say ? :) [04:40] gotta run [04:41] lifeless: see you, try not to think about work :P [07:21] hi all ! [07:27] spiv: wow, thanks for mentioning that bug #637821 has been back ported to maverick, I was chasing my tail trying to reproduce it :-} [07:27] Launchpad bug 637821 in python2.6 (Ubuntu) "Unconnected SSLSocket.{send,recv} raises TypeError: 'member_descriptor' object is not callable" [Undecided,Fix released] https://launchpad.net/bugs/637821 [07:29] http://savannah.gnu.org/maintenance/UsingBzr <-- Is the initial import method in multi-branch v2.1 wrong? I think the first command should be bzr init-repository bzr+ssh://YOU@bzr.sv.gnu.org/YOUR_PROJECT [07:39] echo-area: instead of testyten ? Yes, that looks like a typo [07:40] echo-area: If you're able to update this page, it would be nice to mention that the 'bzr new' command is from the bzr-explorer plugin, not part of bzr core itself [07:40] hi vila, bye vila [07:41] vila: Unfortunately I can't update that page. Btw, is bzrtool in bzr core? [07:41] echo-area: no, it's a plugin too [07:41] poolie: hi there poolie :) [07:41] Did I just repeat myself or did I just repeat myself ? [07:41] vila: Is there a command in core that behaves the same way as the branches command in bzrtools? [07:42] vila: Yes. I mean no. [07:43] echo-area: wow, the tricky ones now.... I don't think so, but there are discussions about providing the same sort of facility in core, no ETA for this though [07:44] vila: Oh I see. Thanks for the info :) [07:51] * vila starts reviewing fullermd's upgrade mp [07:55] fullermd: This doesn't take stacked-on branches into account right / [07:55] ? [08:12] In what way? [08:15] I guess you mean branches in the repo that are also stacked on something elsewhere? No, I don't think it takes any cognizance of that. [08:22] No, I meant stacked branches that suddenly are unusable because their stacked-on repo has been upgraded [08:22] fullermd: let me find the relevant bubg [08:22] Oh. Well, there's not much we can do about that one way or another, since who knows what might be out there. [08:23] I don't mean upgrading them automatically but provide a way to upgrade them knowing that they are in a broken (but identifiable) state [08:24] bug #682719 [08:24] Launchpad bug 682719 in Bazaar "bzr upgrade should accept a --stacked-on parameter" [High,Confirmed] https://launchpad.net/bugs/682719 [08:25] No, I don't expect this touches it one way or another. [08:25] fullermd: thanks, I thought so but wanted confirmation [08:26] Wouldn't you want reconfigure --stacked-on? [08:27] (or some alteration thereof. Though, what with Launchpad Black Magic(tm) being involved, who knows...) [08:27] fullermd: haha, wanting to re-introduce leaks you are ! from bzrlib.transport import get_transport is evil ! (There is a workaround in place against it though, mgz, look at that ;) [08:28] You give me way more "knowing how anything works" credit than is deserved :p [08:28] fullermd: hmm, and I suspect reconfigure would blow up encountering a broken branch, but that's worth checking [08:28] All I did was merge it up to date with bzr.dev changes and try filing off one or two corners seemingly unaddressed from poolie's review. [08:29] fullermd: hehe, no, my secret plot is to drag you into writing failing tests using our new shiny facility ;-P [08:29] Oh, you want to make things BREAK! I can do that! [08:32] . o O (Pfew, here I was pesting against myself about leaking secret plots... It turns out it could be good idea finally ;) [08:53] what a shame, I missed all the australians. [08:54] mgz: no worries ;) [09:40] Hmm, I only have 2000 lines of diff in the review queue. Still not beating garyvdm... [09:43] :_) [09:45] Hi, I'm trying to set up tarmac to run in a chroot and I'm getting bzrlib.errors.SSHVendorNotFound: Don't know how to handle SSH connections. Please set BZR_SSH environment variable. [09:46] What do I set that env var to, or is there a better fix [09:46] that var doesn't seem to be set outside of the chroot either, but bzr works fine [09:51] lamalex: hmm, this probably means you neither paramiko nor openssh available in the chroot ? [09:51] s/you neither/you have neither/ [09:52] vila, ah! yeah probabl [11:14] maxb: looks like python-testtools is now in main for natty, it's only 0.9.2 but that should be enough for bug #659590 no ? [11:14] Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590 [11:22] vila: erh, no [11:22] Because 2.3b4 requires 0.9.5, no? [11:23] !info python-testtools unstable [11:23] rhaaa, grrr, damn [11:23] right, so how do we get there ? [11:23] python-testtools (source: python-testtools): Extensions to the Python unittest library. In component main, is optional. Version 0.9.4-1 (unstable), package size 52 kB, installed size 320 kB [11:24] We need to ask lifeless to do ASAP the python-testtools update in sid he has indicated he will do [11:24] ha right 0.9.*4* is available (bzr-2.2.2 requires 0.9.*2*), my bad [11:24] then we get 2.3b4 into sid [11:25] and get both of them synced into natty [11:28] maxb: right [11:33] and then we finally get on with a 2.2.2 SRU [11:34] see this is why I like PPAs :-) [11:34] indeed :-} [11:34] I don't see why testtools 0.9.5 is a requirement for a 2.2.2 release, but maybe my drop was at a bad moment for the context [11:35] 0.9.2 only is required for 2.2.2 but 0.9.5 is required for 2.3b4 [11:36] but why is 2.3b4 anything to do with 2.2.2? [11:36] wow, I stopped my matching at the first nick letter and wondered why maxb was repeating himself :) [11:36] mgz: Because Ubuntu SRU policy says you need to fix a bug in natty before you SRU it to older releases [11:37] mgz: sooo, SRU requires that the bug is fixed ... He's so quick :) [11:37] okay. yeay for policies. [11:37] Fundamentally, what we're seeing here is yet more friction from the SRU process really not being intended to be driven by upstream releases [11:40] maxb: will you upgrade the beta ppa for 2.3b4 anyway ? [11:48] spiv: lp:~spiv/bzr/fetch-integration not proposed but still a pre-requisite ? [11:49] vila: yes, it is just a merge of two prerequisites. [11:49] vila: no interesting conflict resolution or anything :) [11:49] oh, lp:~spiv/bzr/sprout-does-not-reopen-repo and lp:~spiv/bzr/fetch-spec-everything-not-in-other ? [11:49] Yes, as the MP says :P [11:50] ha, sorry :( Was just checking thoroughly [11:50] trying to see in which order they should be reviewed [11:51] vila: currently the order they have been submitted should work well :) [11:52] yeah, but the +activereviews order is different :-/ [11:52] hence my confusion [11:52] Oh? On my +activereviews page my branches waiting to be reviewed are in the order I submitted them, at least atm. [11:52] got it [11:53] * spiv -> zzz [11:53] lp:~spiv/bzr/fetch-spec-everything-not-in-other is targeted at jam instead of bzr-code hence it appears last to me in the 'Other reviews I am not actively reviewing' [11:53] vila: oh! [11:53] I'll fix that, *then* zzz [11:54] . o O (There should be a way to make him do even more while he sleeps....) [11:54] vila: thanks for spotting that, I should file a bug on how resubmit works. [11:54] But, not while I sleep :) [12:01] Am I supposed to be able to use bzr join to pull a hitherto-unrelated tree into another tree? I read bzr help join, but I thought I could do this anyway. I get the error saying the two trees have the same root. [12:03] dlee: I think you need the tree to be inside the targeted one [12:04] Oh, I previously moved the source tree there, something like mv ~/bzr/srctree ~/bzr/desttree, so now it's ~/bzr/desttree/srctree. [12:04] My command, from ~/bzr/desttree, would be bzr join srctree [12:05] yes, and this fails ? [12:05] yes [12:05] bzr 2.2.0 [12:05] bzr info ? (repo format in particular) [12:06] of both [12:06] I had to do bzr upgrade in the dest, and I even tried upgrading the source also, no change. (This project started two years ago in a non-richroot format) [12:06] meh, and bzr doesn't tell you it needs richroot ? [12:07] Both currently say format 2a (standalone because I unbound them before starting all this). [12:07] :( [12:07] It did say that so I did bzr upgrade. Hmm... did it upgrade to the wrong format? [12:08] 'bzr info' will tell you [12:08] The relevant bzr info line says exactly Standalone tree (format: 2a) [12:09] * vila scratches head, the exact message is 'Trees have the same root' ? [12:10] Yes. And I believe the format I had before the bzr upgrade was pack-0.92 [12:11] Exact message for bzr join srctree: bzr: ERROR: Cannot join srctree. Trees have the same root [12:13] and the only occurrence of this message is after 'if other_tree.get_root_id() == self.get_root_id()' [12:13] and you're sure 'bzr info' in srctree also says 2a ? [12:14] It does now, though I tried first while srctree was pack 0.92 [12:15] Exact command sequence was bzr join srctree (in desttree) (fail), bzr upgrade (dest), bzr join srctree (fail with same-root message), cd srctree, bzr upgrade, cd .., bzr join srctree (fail with same root). [12:15] could add a 'import pdb; import.set_trace()' after this test and pastebin the root ids ? It's in bzrlib.workingtree.py search for 'def subsume' [12:15] s/could add/could you add/ [12:17] I'll keep that suggestion for reference and do it when I get a chance. I'm on the clock for a project now, was just trying to reorganize three subprojects that turned out to relate more closely than expected into one tree. [12:18] dlee: ok,sorry about that :-/ [12:18] This means what I'm trying is supposed to work though, which is nice to know. :) [12:18] Oh np and thanks very much for your time and assistance. [12:18] dlee: np, thanks for updaing gentoo to 2.2.2 ;) [12:20] Lol if that's a suggestion I get it, but if not... different dlee? [12:20] ha, may be then :) [12:20] Doug Lee here, blind developer of assistive technology stuff mostly. [12:21] oh, not it was fauli, why did I associate you with gentoo... aren't you involved there ? [12:21] I know someone from there (Deedra - someone you know?), but not really otherwise. [12:22] I used to hang out in the Freenode channel #wopn years ago. [12:23] no, I think it's related to bzr... sorry for the confusion [12:23] np but thanks all the same :) [12:23] :D [12:28] vila: URL for preferred paste manager here? [12:29] !paste [12:29] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-lunch [14:30] babune having a history page each node of the test tree is pretty neat. [14:31] bzr having so many random failures on windows is less so... === Ursinha-lunch is now known as Ursinha [16:00] I had a brilliant idea this morning [16:01] hi dejj [16:01] I thought I could use bzr to keep track of a large archive of my photographs [16:01] hi [16:02] large, like 1 gb [16:02] dejj: bzr doesn't do very well with large files at the moment, though there have been a lot of requests to improve that [16:03] it would work nicely, if there was some repository format that only keeps track of, say a checksum instead the whole file [16:03] is there something like that? [16:03] dejj: Then where would it get the file? [16:04] there would be only the file. most operations like revert and even commit wouldn't work. however... [16:05] since I keep another branch on an external harddisk, I could push and pull to/from there [16:05] does this make any sense to you? [16:05] dejj: that sounds like what rsync does [16:06] ^.^ [16:06] I should probably look this up now [16:08] is there a TortoiseRsync? [16:09] not as far as I know, but I'm not really involved in rsync development [16:15] shouldn't it be possible to have a bzr-rsync repository format? [16:18] dejj: I don't think that would help much. rsync is a tool for syncing files efficiently. [16:19] it doesn't help when dealing with those large files inside of bzr, and that's where the real problem is at the moment [16:20] it's functionality would be almost trivial. it would simply transmit the whole file if it was changed [16:20] for me, the archive is 1gb, but each file is about only 5mb [16:21] (though the limitation you mentioned would be trouble if I had the brilliant idea to also sync my movies) === Meths_ is now known as Meths [16:24] is there some place where I can find out about repository format development? === beuno is now known as beuno-lunch [16:31] dejj: if the files themselves are pretty small (e.g. 5 Mb) then the current formats should work fine. [16:32] dejj: Implementing a new repository format is non-trivial, see bzrlib.repository and bzrlib.versionedfiles [16:35] it seems so. maybe I can start with some existing format and slash out most functionality [16:36] Hi there, I'm using bzr thought Apache + mod_python, but it is reaaaaaally slow [16:36] any thoughts? [16:36] I just need it to not keep any revisions, including the current. some sort of even lightweighter-lightweight [16:37] fabio_kreusch: try using bzr+ssh to ensure that bzr is indeed the culprit [16:37] fabio_kreusch: and make sure you're using the 2a format too [16:38] my bzr server resides on a windows server =\ [16:39] before switching to apache + mod_python, I was using the bzr server, which was ok [16:39] fabio_kreusch: well, so you did the experiment before :) Why do you blame bzr then ? [16:39] I had to switch to apache + mod_python because it was the only way I found to integrate with active directory [16:40] I'm not blaming bzr, I'm just trying to know if someone else has seen this before [16:41] fabio_kreusch: oooh, my bad, I misinterpreted 'is' :-/ [16:41] ...as I've recorrected myself on bug 686611 twice now I'm probably honour bound to fix it too. [16:41] Launchpad bug 686611 in Bazaar "`bzr add file1 file2` in non-ascii folder fails, but `bzr add file1` works" [Low,Confirmed] https://launchpad.net/bugs/686611 [16:42] fabio_kreusch: from the top of my head, I would say you want to get in touch with awilkins [16:42] fabio_kreusch: also he doesn't seem to be online , so may be trying the mailing list will get you a broader feedback [16:44] mgz: I was wrong when I said I was right, but right when I said I was wrong ? [16:44] that's about it. [16:45] was green mac buildbots too? [16:45] s/was/want/ [16:45] vila: thanks! [16:50] vila: what in practice does your mac do if you do `open('\xe4','w')`? [16:51] it opens a file named a with a weird accent [16:52] that emacs lists as %E4 as does the finder [16:52] if you then do `os.listdir()` what do you get? [16:53] okay, so it is a semi-reversible mangling. [16:53] 'locale' says LANG= LC_ALL= the rest is C [16:53] os.listdir says %E4 too [16:54] great. [16:54] invalid NFD ? [16:54] mgz: note that my locale is unsual, let me try from a terminal [16:54] if only pathconf actually covered all this stuff [16:55] ha different [16:56] whaddya get instead? [16:56] open says '?' all the others agree on '%E4' [16:56] Hello all. I've just tried to push a branch to LP and have hit http://paste.pocoo.org/show/301863/. Any suggestions as to what's going on? [16:57] that's fine, thanks vila. [16:57] Odd_Bloke: upgrade your bzr version. [16:57] mgz: and the locale in the terminal is en_US.UTF-8 [16:58] Odd_Bloke: aren't you running bzr behind an http server on windows ? [16:59] Odd_Bloke: known bug, fixed in recent versions, related to a proxy [16:59] Odd_Bloke: my question was unrelated to your problem by the way [17:00] mgz: thanks for the review ! === deryck is now known as deryck[lunch] [17:10] Anyone have any suggestions for http://buildbot.twistedmatrix.com/builders/openbsd-current-sparc64/builds/4/steps/bzr/logs/stdio ? [17:14] nothing I've seen, file a bug against bzr-svn exarkun. [17:14] hi exarkun [17:14] Hi jelmer [17:15] On a separate topic, as I was going to file a bug, I noticed on https://launchpad.net/bzr-svn that bzr-svn is licensed GPLv3? [17:15] exarkun: that should be GPLv2+ [17:15] Makes a big difference, I hope you'll update the page soon :) [17:16] svn is apache? [17:16] mgz: yeah [17:16] might have to be v3 then? [17:16] exarkun: fixed [17:16] depends how you use their code. [17:17] mgz: run-time link against it; bzr-svn itself doesn't include any svn code [17:17] exarkun: just curious, is there a particular issue with gplv3? [17:18] exarkun: any chance you can set BZR_PDB=1 and inspect the value of dirents ? [17:18] A few. The one on which there is the least flexibility that some large companies with large legal teams have a policy forbidding the use of any GPLv3 software. [17:19] Apple :-/ [17:19] what a lucky guess :) [17:20] I can ask the person whose host that is to try BZR_PDB=1, not sure if he's around right now though [17:20] exarkun: it's not reproducible locally? [17:21] no, nor on any of the other 5 - 8 machines that are running slaves for Twisted's buildbot [17:21] exarkun: I'm an upstream developer of Samba, and GPLv3 is apparently the reason they've stopped shipping newer versions of Samba. [17:21] This is the first OpenBSD machine === Meths_ is now known as Meths [17:21] exarkun: ah. Is it running the Samba subversion version as the other hosts? [17:22] heh, samba. ;) I'm not sure what version of svn it is running, I'll check on that too. === beuno-lunch is now known as beuno [17:25] Urgh, the language center in my brain is thoroughly confused today. Sorry. [17:25] As you might've guessed I meant "same" [17:25] indeed :) [17:28] Can I commit just a chunk of a file vs. the whole fine [17:28] file [17:28] a la git commit --patch [17:29] lamalex: only by "bzr shelve"-ing the other changes first [17:29] jelmer, ok [17:29] lamalex: I think there might also be some "git add -i" like stuff in bzr-interactive, but I'm not sure. [17:38] exarkun: it'd also be interesting to know which subvertpy is in use on that machine [17:38] exarkun: it seems to be a problem in a lower layer, as bzr-svn is requesting the 'kind' info of all entries but not receiving it [17:39] jelmer: I filed https://bugs.launchpad.net/bzr-svn/+bug/686663 and pointed the operator of the machine to it, so hopefully he'll add some more details. [17:39] Ubuntu bug 686663 in Bazaar Subversion Plugin "bzr: ERROR: exceptions.KeyError: 'kind'" [Undecided,New] [17:39] exarkun: thanks [17:51] vila: to answer question about 2.3b4 in PPA from some time ago. Yes, I'll do that. I was confused by the topic here. To me, "frozen" implies revision decided upon but no tarballs yet [17:51] s/frozen/feature frozen/ ? [17:52] maxb: no, frozen here means the tarball is out, yup as jelmer said [17:52] 2.3 can be feature frozen, 2.3b4 is rather more than just feature frozen :-) [17:52] not only feature frozen in fact, commit frozen [17:55] How do I revert the changes made by a single that is not necessarily HEAD [17:57] lamalex: Reverse that patch and do another commit? [17:58] merge -r10..9 will revert the change that went from 9 -> 10 [18:00] really? [18:00] weird [18:00] what an odd syntax [18:01] lamalex: that's a cherrypick, see 'bzr help merge' [18:02] bzr: ERROR: Server sent an unexpected error: ('error', 'requested revno (670) is later than given known revno (652)') [18:02] ? [18:02] bzr revno says 674 [18:04] what command did you type ? [18:04] bzr merge -r671..760 [18:05] er [18:05] bzr merge -r671..670 [18:05] Are you using an up-to-date checkout ? [18:06] bzr st /bzr info would help understand your setup [18:06] ~paste [18:06] !paste [18:06] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [18:07] http://pastebin.com/uc2n52nS [18:07] vila, and my working tree is not changed so st gives nothing [18:07] but thanks for that shortcut [18:08] meh, where is a server involved there >-/ [18:08] yeah [18:08] that's what I'm wondering [18:08] it should all be working locally [18:09] ha ! silly me ! 'bzr merge' use submit_branch by default [18:10] so add a final '.' to your command to tell bzr you're merging from your local branch [18:13] ahh [18:14] thank you :) [18:14] not a very nice error message there [18:15] lamalex: indeed, file a bug explaining how you went into it (including the submit_branch trick) [18:16] yah [18:16] lamalex: and don't forget about the submit_branch trick... I keep falling into this trap after years of use :) [19:29] How can I show the log entires for revisions that are part of a pending merge? [19:52] It's rather annoying. In Openstack, I've added a unit test that checks if everyone who has a commit anywhere in the revision history is listed in the authors file, but right now the revision has to be committed before the check sees it. [19:53] So someone new can get a commit in without adding themselves to Authors, but the following attempt to merge somthing will fail, because now the previously merged branch is part of the "bzr log" output and thus lists the new contributor who isn't in Authors. [19:59] soren, you want "bzr log" to include those things, or you are happy with querying for them separately? [19:59] james_w: bzr log would be simplest, but whatever does the trick is fine. [19:59] Simplest to consume, that is. [20:00] I don't know about implementation. [20:00] it's possible to do it with some combination of "bzr st --show-ids" and "bzr log" I think [20:00] IIRC there's no revspec for the pending merge(s) [20:00] bzr st --show-ids doesn't show the id's of the merge reivsions. [20:00] It shows the id's of the changed files. [20:01] oh, I was pretty sure it showed the merge tips too [20:01] Not even with -v, no. [20:01] I'm not sure how to get them without bzrlib then [20:01] http://pastebin.com/XxDT3pkF [20:01] jam, any ideas? [20:03] james_w, soren: well, you can do "bzr status -v" to get more details, but I don't believe we expose that well outside of bzrlib [20:03] jam: that pastebin above is from bzr st --show-ids -v [20:03] jam: So no. [20:03] What I do now is just call subprocess.Popen(["bzr", "log", "-n0"]) and parse the output. [20:04] soren: well, you can see that Ryan Lucio did all of those pending merges, but it would only give you one author, etc. [20:04] Maybe someday when I grow up, I'll use bzrlib, but this works for now. [20:04] jam: It just doesn't solve my problem at all. [20:06] tree = bzrlib.workingtree.WorkingTree.open('.'); tree.lock_read(); parents = tree.get_parent_ids(); g = tree.branch.repository.get_graph(); for p in parent_ids[1:]: rev_ids = g.find_unique_ancestry(p, [parent_ids[0]]); revs = tree.branch.repository.get_revisions(rev_ids); for r in revs: r.get_authors() [20:06] something like that in bzrlib [20:06] not super terse, but if you are writing a plugin, it works well in a function [20:08] Bloody hell. It works. [20:09] With a few adjustments, but wow. [20:09] That's awesome. [20:09] s/find_unique_ancestry/find_unique_ancestors/ [20:09] and [20:09] s/get_authors/get_apparent_authors/ [20:09] and [20:09] s/parent_ids/parents/ [20:10] (Just in case someone stumbles on this in an irc log and can't get it to work) [20:10] jam: Awesome, thanks so much! [20:10] That's just what I needed. [20:10] soren: happy to help [20:11] Is there a simple change to make it include not just the pending merges, but the entire history? [20:11] If not, that's cool. I just have to check both, so if they could easily be collapsed into one, that'd be even better. [20:12] I already have working code for the existing history, so I'm really fine. [20:12] soren: what do you mean entire history? I think you might want g.iter_ancestry(parents) but I'm not positive [20:14] jam: What I do now is parse the output of "bzr log -n0". [20:14] jam: The stuff it tells me about is what I call "the entire history". [20:15] soren: graph.iter_ancestry() is probably what you want then. Check the output format (gives tuples of (rev, parent_ids) [20:15] but it will give you the entire ancestry [20:15] including the pending merges [20:15] Fantastic. [20:15] though eventually that's going to get pretty slow [20:16] jam: Sorry, I'm completely new to bzrlib. Roughtly where does g.iter_ancesty() go here: http://pastebin.com/U6d95PvY ? [20:16] Line 6-ish? 8-ish? [20:17] 6-ish, /me thinks. [20:17] soren: http://pastebin.com/e0Cg9dWn [20:18] well, that should be rev_ids = ... [20:18] * soren takes it for a spin [20:20] bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/soren/src/openstack/nova/.bzr/repository/') has no revision null: [20:27] Hm... The 1787th entry in rev_ids is 'null:'. [20:28] Filtering it in the list comprehension works. [20:28] jam: Is "null:" supposed to be there, or is that a symptom of something? [20:29] soren: 'null:' is the end [20:29] the root-of-all things [20:29] jam: Ok. I'll just filter it out. [20:29]