[00:00] mwhudson: yeah [00:01] still imports the one from site-packages [00:02] cyberix: what exactly are you doing? [00:02] can you pastebin a session? [00:03] Just trying to run selftest on a vanilla "checkout" from lp:bzr [00:04] mwhudson: it seems to be true for bzr+ssh:// as well [00:04] cyberix: that's weird. try removing/not using your current PYTHONPATH, i.e: PYTHONPATH=/path/to/branch [00:04] mathrick: i'm not surprised there [00:05] why not? [00:05] http://pastebin.com/d73a21e3 [00:09] mathrick: because the code for bzr:// and bzr+ssh:// is basically the same at this level [00:09] Verterok: That doesn't change anything [00:09] cyberix: hm, seems to be loading the system plugins [00:10] which is wrong, but less wrong than what you first said [00:12] oh [00:14] Any further suggestions? [00:15] cyberix: you can use the --no-plugins option [00:15] ./bzr --no-plugins selftest [00:16] cyberix: also there is the BZR_PLUGIN_PATH env var, in the case that you want to include some plugins in the selftest [00:24] mwhudson: ok, do you see a fix? [00:25] I need to know if I should invest into making it work, or rather take care of the reading part of my app [00:25] mathrick: not really looked yet [00:25] aha [00:25] mathrick: i wonder if i can trick spiv into fixing it [00:25] hehe [00:25] spiv: https://bugs.edge.launchpad.net/bzr/+bug/175570 [00:25] Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed] [00:26] I think he should feel morally obliged to fix it, he knew the bug number instantly when I mentioned it :) [00:26] smart server/remote branches is something he knows more than most about [00:27] * mathrick wonders if that is a good thing [00:28] thanks that helped [00:29] mathrick: "instantly" is a bit of an exaggeration :) [00:29] going to sleep now [00:29] good night [00:30] I had to search Launchpad, but happily searching bugs.launchpad.net/bzr for "cat ObjectNotLocked" found exactly 1 bug. [00:34] excuses [00:51] spiv: do you know about the locking thing off hand? [00:59] locking thing? [01:00] spiv: the bug I ran into [01:00] spiv: http://pastebin.ubuntu.com/27148/ [01:03] mwhudson: that has the same root cause as 175570, I believe [01:04] There's another related bug report or two, as well. [01:04] spiv: well, i was more thinking that it could be the root cause for that bug [01:05] mwhudson: well, that's a symptom, not a cause ;) [01:05] spiv: ok [01:05] The cause is roughly that RemoteBranch.lock_read doesn't call lock_read on its repo. [01:05] But just simply doing that breaks other things. [01:06] There's a discussion of this on the list and/or this mysterious other bug report I'm alluding to. [01:06] hm [01:06] mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/237067 [01:06] Launchpad bug 237067 in bzr "RemoteBranch.lock_read() doesn't lock the underlying repository" [High,Confirmed] [01:07] spiv: yay google [01:07] (i just found that too) [03:49] Aha! I was going to ask a good-ole' stupid question, but I found the answer! sftp://myuser@domainname.com/~/svr/bzr/ works, sftp://myuser@domainname.com/svr/bzr does not :) Silly little ~ === spiv_ is now known as spiv [05:28] woo, 1.6Million key btrees , no memory _explosion_ [05:29] (and thats not the limit, that was just disk spilling when it blew up cause it exceeded the header size) === elmo_ is now known as elmo [09:25] megarepo test on b+tree indices: [09:26] 115M .bzr/repository/indices [09:26] down from [09:26] 444M backup.bzr/repository/indices/ [09:26] poolie: oh yeha, hi :) === wgrant_ is now known as wgrant [09:55] night all [10:21] hi [10:22] anybody using bzrweb with bzr 1.5rc1? :D [10:50] lifeless: But are b-trees Faster too? [11:28] awilkins: igc mailed the list with some results [11:28] awilkins: executive summary: much faster at some things; a bit slower at others, ~= on the rest. [12:00] hi all [12:01] wondering if someone might be able to help me out with a bzr related problem [12:01] get the following error: bzr: ERROR: [Error 32] ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, [12:01] ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, is unreadable meaningless heap of letters! [12:01] reported it on https://bugs.launchpad.net/bzr/+bug/237305 [12:01] Launchpad bug 237305 in bzr "bzr: ERROR: [Error 32] " [Undecided,Incomplete] [12:04] gabe: What OS are you using? === Cael is now known as Splodge [12:11] that's on windows vista with bzr 1.5 [12:13] Hmm, I don't really know enough about Windows to be able to help you debug. :( [12:13] i know enough about Windows not to use it! [12:13] gabe: That said, attaching the relevant part of .bzr.log to the bug report would probably be helpful. [12:13] it's actually a russian friend with the problem [12:13] trying to help him solve it.. [12:14] i'll see if i can get hold of bzr log [12:24] Hi, I'm hoping somebody here can help me: is it possible to compare two branches in bzr? [12:24] I have a trunk on the server which I've 'branch'ed to my PC. Then, to test things, I updated some files in the working tree and committed them to the local copy of the branch (what's the proper term for this - local mirror?). The question is, is it possible to compare the local copy containing the commits, to the branch on the server in a nice, simple way? Or am I approaching development... [12:24] ...with bzr incorrectly? [12:25] cd local-branch [12:25] bzr diff http://path/to/remote/branch [12:25] 'bzr missing' will show the different commits on each, or you can use bzr diff to show diffs [12:28] gabe: sounds liek the error isn't encoding correctly on output [12:31] Ah I see. [12:31] 'diff' doesn't show anything for me, but 'missing' does list the extra revisions I have locally. [12:31] And the --verbose item will show extra details on the changes to files etc. [12:31] That's just what I was looking for. Thank you. [12:34] thanks [12:35] I got a section of the bzr log attached to the bug report, it's here... http://launchpadlibrarian.net/16008570/bzr.log === emgent_ is now known as emgent [13:02] gabe: thanks === andrea-bs_ is now known as andrea-bs === cody-somerville_ is now known as cody-somerville [13:17] gabe: ERr 32 is an IO error ; probably a file being held open by another process [13:18] gabe: Which shell are you using? THe error text looks like it's in unicode or something === jaypipes_mysql is now known as jaypipes [13:36] gabe: Looks like an eastern European error message for err 32. Your local encoding is cp866 so I presume you are cyrillic by nature... [13:41] yeah it's actually a russian friend I am asking on behalf of [13:41] what info do you need? [13:43] gabe: Well, it's an IO error during a tree transform ; I would suspect that another process has a lock on one of those files [13:43] hmm, I was going to say bzr --version [13:43] but it doesn't include the encoding [13:43] gabe: does your friend see a readable error? [13:43] what he sees is what I pasted here [13:43] error 32 etc [13:43] and some unreadable junk too [13:44] gabe: if what he sees is correctly encoded cp866 he will be able to read it even though we can't [13:44] he's used bzr for a while [13:44] no problem [13:44] thats the nature of encoding [13:44] yeah but he said it is junk [13:44] unreadable even to him [13:44] gabe: so I'm tryingt o understand if *he* can read it, not if the copy and pasted stuff is unreadable [13:44] ok [13:44] so there are two issues: why the error, and the error being unprintable [13:44] he has a checkout of a branch [13:44] and been doing about 25 --local commits [13:44] as for why the error, does he have an editor open on a file or something? [13:45] then wanted to commit back to the repo [13:45] but it said he needed to bzr up [13:45] so he did bzr up and got this === thekorn_ is now known as thekorn [13:45] hey * [13:45] some conflicts [13:45] and errors [13:45] He has a file open [13:45] gabe: I would guess an editor open on a file [13:45] ok [13:45] It's during a rename [13:45] jelmer: hi [13:45] i'll make sure he quits any editors and tries again [13:45] Windows ia waaay more picky about files being open when it writes over them [13:46] mornin' all [13:46] lifeless: How were things at GUADEC? [13:46] jelmer: intense :) [13:46] many positive discussions, some rather more neagative [13:47] lifeless, any guesses on what the outcome for VCS choice will be? [13:47] lifeless: what in particular were the negative ones about? [13:49] jelmer: some folk felt that canonical was pushing bzr (rather than us being there because gnome devs *wanted* support for bzr) [13:49] jelmer: and there were some rather opinionated folk that didn't want a dialogue, but instead wanted to tell me how stupid it was to even hack on bzr given that git exists [13:50] lifeless: wow, ok [13:50] beuno: no idea yet [13:51] The number of people who think that git is the be-all-and-end-all, perfect, etc. does surprise me [13:51] esp. given how I cannot get on with it no matter how hard I try [13:51] Kinnison: the number of them that have used bzr in anger appears to approach zero [13:51] lifeless: surprise surprise. [13:51] * Kinnison wishes git was easier and nicer [13:52] * Kinnison gave up and did his kernel module dev in bzr and supplied a patch to the kernel guys [13:52] because I just can't get git to be of any use to me [13:52] lifeless: Thanks for the update [13:53] jelmer: should have a interseting ssvn bug for you soon [13:53] I'm looking forward to it ;-) [13:54] lifeless: did you persuade any gnomers (that currently use svn/git) to at least try bzr? [13:54] pbor: yes [13:54] cool [13:54] rob taylor from codethink appears quite excited :) [13:54] lifeless: are you serious ? [13:54] Jc2k: how's your head? recovering from guadec? [13:54] asabil: about what? [13:54] about rob taylor [13:54] getting people to actually try it is the only way to gain user base :-) [13:55] asabil: yes [13:55] wow ! [13:55] lifeless: my brain is at about 25% usefulness [13:55] last time I talked to him (a year ago), he was worshiping git [13:55] asabil: he's had Jc2k hammering on him way before guadec :) I just added the straw I think [13:55] * Jc2k nods [13:55] lol :) [13:55] not just that though [13:55] well done Jc2k ^^ [13:56] he's been poking the Git source code for his project [13:56] we need more of you [13:56] and Git source would finish anyone of [13:56] f [13:56] its horrible in there. [13:56] haha [13:57] I think bzr developers maybe should start blogging code snippets from git's source code [13:57] maybe that would shed some light on the evil dark corners of git :p [13:58] jelmer, btw, which BB are we using for bzr-gtk? it seems we have 2 fighting over it now [13:58] beuno, vernstok.nl is still the primary one [13:58] until the one on Aarons machine has the right details [13:58] jelmer, cool, I'm back home now, so I should be able to go through the remaining reviews, and merge some of them [13:58] cool [13:59] sorry I've been so unresponsive, but I've had a few unusual weeks :) [14:00] Heck, I've had a few unusual _months_... [14:05] vila: Ping? [14:10] guys, I love you all, but this: bzr: ERROR: Repository KnitPackRepository() is not compatible with repository KnitPackRepository() [14:10] is quite possibly the worst error message in the history of mankind [14:10] mtaylor: totally [14:11] mtaylor: Couldn't agree more [14:11] mtaylor: and I'm embarrased [14:11] ok. [14:11] jelmer: so patch it up :) [14:11] as long as you're embarrassed [14:11] jelmer: add the rich root etc stuff to str() [14:11] also, let me verify... [14:12] rich-root-pack is required for former svn repos... but is not recommended at this point for normal use of large projects, say, like the mysql trees? [14:12] lifeless: Maybe once I finish browsing through the bzr-svn bugs from the last 5 days... [14:12] jelmer: :) [14:12] mtaylor: its a one way trap door; shouldn't be performance implications [14:26] holy cow [14:27] this index is a 5-level B+Tree [14:27] 2.9Million keys [14:29] lifeless: Did you think about incredibly-scary-judy-arrays ? [14:33] awilkins: yes [14:34] I never tried them personally, but the papers read really impressively :-) [14:34] 5 IO's per key -> not ideal. But hey, its all of ubuntu. [15:05] jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/248406 [15:05] Launchpad bug 248406 in bzr-svn "Import of SVK modified SVN repositories" [Undecided,New] === mw|out is now known as mw [15:32] ok my russian friend closed his editor [15:32] did bzr up [15:32] this is what he said: [15:32] i've closed editor and run bzr up and it completely removed all my changes [15:32] all 26 local commits are disappeared [15:32] why did it do that!? [15:35] gabe: bzr st will show you a pending merge [15:35] gabe: and he should now 'bzr commit' to record it and put it in the repository [15:35] oh [15:36] lifeless: thanks for your continued assistance [15:36] i'll check on the bzr st [15:36] gabe: if he reverted or something then it will have become a dead head and he can do 'bzr heads --dead' or whatever to find the id etc. [15:36] er [15:36] this is what his bzr st shows [15:36] gabe: check on bzr st :) [15:36] D:\xampp\htdocs\eastwestfilms\hungerseason>bzr st [15:36] unknown: [15:36] .project [15:37] no merges :( [15:37] gabe: bzr heads --dead-only [15:37] gabe: he will need bzrtools installed [15:37] he had a whole bunch of about 25 --local commits [15:37] lifeless: he has been using bzr for a while without problem? Is he really missing bzr tools? [15:37] gabe: the heads command is in bzrtools [15:38] gabe: I don't know if he is missing it or not, but to find the id of the commits that he reverted we need bzrtools [15:38] can anyone tell me how to revert a 'branch'ed that has had some commits made back to the trunk version? a 'revert' only reverts the working tree to the branched copy. do I need to do something with 'pull' or provide some optional parameter. googling has turned up unless i'm just looking in the wrong places... (apologies if it is a stupid question) [15:38] right, i'll make sure he has it installed. [15:38] gabe: its there in his repository, we just need to pull it back into his tree [15:38] gabe: try the command, if it's unknown command install bzrtools/upgrade bzrtools [15:39] Splodge: pull --overwrite [15:39] try this command? zr heads --dead-only? [15:39] gabe: yes [15:39] bzr heads --dead-only [15:40] what will it do? [15:40] lifeless: Thanks! You guys are good ;) [15:40] gabe: report on the name of the stuff he reverted [15:40] ok i asked him to try [15:40] lifeless: you are right, unknown command [15:40] so install bzr tools [15:41] gabe: yes [15:41] abentley: ping [15:41] lifeless: pong [15:42] abentley: nevermind, something stranger than I considered [15:42] abentley: I have an epic fail on my mega repo; with bzrlib.errors.RevisionNotPresent: Revision {('zopezver.init.in-20080520144343-w8u8nix52axlkvgg-19', 'liw@gytha-20080520144343-7pdk3g344utm17vz')} not present in "". [15:42] abentley: but the repo has single commits everywhere so it should be impossible [15:43] lifeless: This is with B+ trees? [15:43] abentley: yes, though I think that that is orthogonal === Splodge is now known as splodge [15:45] I know what is happening [15:45] bug in my bug fix [15:50] abentley: so yes, it was B+trees [15:50] lifeless: Glad you found it. [15:52] how to install bzrtools [15:55] abentley: I was handling far right hand end nodes wrong if the node had only one child [15:56] abentley: BB doesn't seem to be picking up on when patches have been merged into PQM's trunk (http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080710071152.05c913e0@lapbert%3E is the only example ATM). [15:57] Odd_Bloke: Okay, I'll look into it. [15:58] abentley: Thanks. :) [15:58] Odd_Bloke: Could you file a bug report, please? [16:01] abentley: Sure. [16:01] ok my friend has bzr tools installed [16:01] this is the result of bzr heads --dead-only [16:01] HEAD: revision-id: kos@pixeco.com-20080714080119-60tpfuob57h4zma4 (dead) [16:01] committer: Kos [16:01] branch nick: hungerseason [16:01] timestamp: Mon 2008-07-14 14:01:19 +0600 [16:01] message: [16:01] Added sIFR for images caption [16:01] gabe: ok, you can now do 'bzr merge -r revid: kos@pixeco.com-20080714080119-60tpfuob57h4zma4' [16:02] oooh ok [16:02] gabe: and then 'bzr commit' [16:02] that's very precise :) [16:02] erm, thats revid:kos... [16:02] I added a space by mistake [16:02] like so: [16:02] 'bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob57h4zma4 .' [16:02] ok cheers [16:02] that will resurrect his patches [16:03] D:\xampp\htdocs\eastwestfilms\hungerseason>bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob [16:03] 57h4zma4 [16:03] bzr: ERROR: No location specified or remembered [16:04] is that bad news? [16:04] gabe: add the '.' :) [16:04] gabe: there is a hard to see '.' after the revid [16:04] you could alternatively change the order [16:04] bzr merge . -r revid:..... [16:05] lifeless: are you still in Europe? [16:05] lifeless: yep, quite right! [16:05] jam: London indeed [16:05] gabe: happy to help, sorry it took up your friends time [16:05] abentley: https://bugs.launchpad.net/bundlebuggy/+bug/248422 [16:05] lifeless: how long before you head back to AU? (Just curious how much time you'll be awake when I am :) [16:05] Launchpad bug 248422 in bundlebuggy "Merging of patches to PQM trunk not detected" [Undecided,New] [16:06] Odd_Bloke: Was the patch merged after BB started tracking PQM? [16:08] jam: 1 week [16:09] lifeless: we're still working on that last command [16:10] seems he gets [16:10] "'bzr" is not recognized as an internal or external command, [16:10] operable program or batch file. [16:10] gabe: well, how does he run bzr normally ? :) [16:10] is that because windows doesn't recognise the quotes around the command? [16:10] gabe: you shouldn't copy the quotes, they were to show you what to copy :) [16:10] he uses the bzr command but not with quotes around it I guess [16:10] oh woops [16:12] that worked [16:13] lifeless: when I work on a checkout make local commits, when I want to commit to repo sometime I need to bzr up, but then it wipes all my changes too - why does this happen? [16:13] gabe: it does not wipe them away; you have to run 'bzr revert' to wipe them away [16:13] so what does it do with my local commits then? [16:13] and why are they 'taken away'? [16:14] it puts them into a pending merge [16:14] so that after the update, when yo commit they go into the master [16:15] and they are taken away when you run 'bzr revert' because bzr revert removes pending merges [16:15] abentley: I _think_ so, but I'll go and check timestamps. [16:15] but bzr st doesn't show them? [16:16] gabe: bzr st will show them [16:16] i mean i thought merges didn't really happen with checkouts [16:16] gabe: I assure you, he ran - 'bzr up' and then 'bzr revert' [16:16] gabe: checkouts can totally do merges [16:16] ok, so in the future, when my local revisions appear to have been nuked what should be be looking at doing? [16:16] gabe: dont run bzr revert after an update and they will never appear to have been nuked [16:17] mmm ok [16:17] abentley: You sent the message to the ML about PQM now being managed by BB on the 9th, the merge happened on the 10th. [16:17] 'bzr update && bzr revert' is guaranteed to give you a tree the same as the thing you have a checkout of. [16:17] gabe: (&& means followed by) [16:17] ah ok [16:18] and then what did you do to fix that? merge the current tree with a previous version that included local commits? [16:18] bzr update && bzr commit is guaranteed to commit your local edits to the thing you have a checkout of. [16:18] yes, the use of heads --dead-only, and merge, is how we reinstated the local commits. [16:19] Odd_Bloke: I'm not sure when the last tweak of the merge-detection code happened. It may have been afterward. [16:22] jam: I am going to make the last node in a row be variable-sized [16:22] jam: using b+tree indices in bzr search.. hurt [16:23] lifeless: I understand your desire, but isn't that the last node in the *last* row only? [16:23] jam: yes [16:23] i need to find out about bzr heads [16:24] bzr heads [16:24] bzr: ERROR: unknown command "heads" [16:24] even after doing: sudo ./setup.py install [16:24] jam: its actually really the use of many tiny indices *I think* [16:24] in the bzrtools extraction dir [16:24] gabe: what path did it install into [16:25] lifeless: you realize, that is probably sub-optimal from an FS perspective anyway [16:25] Writing /Library/Python/2.5/site-packages/BzrTools-1.5.0-py2.5.egg-info [16:25] considering most FS have a minimum 4k page [16:25] jam: they are in a pack [16:25] lifeless: you are putting the indexes into a pack file... ok, I guess [16:26] jam: better than 100000 files on disk :) [16:26] jam: ask mtaylor how long the earlier editions took to delete an index :) [16:26] jam: oit was not pretty :) [16:27] lifeless: because deleting required re-packing everything? [16:27] sounds like a flag "deleted" case :) [16:27] jam: no, because ext3 doesn't handle hundred's of thousands of files in a single directory gracefully [16:28] jam: bzr-search doesn't delete stuff anyway [16:28] ah, before the packing [16:28] yeah, I seem to remember running into that in the past [16:28] when we were working on medical images and dumped 100k files in a directory [16:28] I had to write a custom script that used the raw C files to move them out [16:29] the raw C *functions* [16:29] because 'ls *' or python listdir() would just take forever to finish [16:30] ls /Library/Python/2.5/site-packages/bzrlib/plugins/bzrtools/ [16:30] __init__.py dotgraph.pyc rspush.py [16:30] etc [16:30] seems to be there [16:30] gabe: I would double check that "bzr --version" lists /Library/Python/2.5/site-packages/bzrlib as its bzrlib location [16:31] ha no [16:31] it doesn't [16:31] best fix that [16:34] Odd_Bloke: still getting your random commits on the commit list [16:34] http://bzr.daniel-watkins.co.uk/pqm/work/foo "renamed 'foo' => 'bar'" [16:35] i initialized a repository from generated code, added everything, committed, then branched to a remote bzr+ssh url. this location on the server only ended up with a .bzr subfolder, and is smaller, significantly, than a branch made from it locally, eg. 'bzr branch main dev' [16:35] clearly there is something basic i don't understand, anyone care to proffer a link or something? [16:35] jam: Ah, thanks. [16:36] meteoroid: I'm guessing on your server you don't have a working tree, which is standard for places that we can't access the wt directly [16:36] you should still have all the revision data [16:36] just no working files [16:36] If I have a lightweight 'work' checkout which is bound to a branch, which location's settings will be used from locations.conf? [16:36] jam: ah ok, that's what i figured, is there some command i run to turn a branch into a wt? [16:36] Odd_Bloke: are you saying light weight => branch => other_branch ? [16:36] meteoroid: 'bzr co' [16:37] but the WT won't be updated by default either [16:37] (there are some workarounds for this) [16:37] hm [16:37] well i shouldn't use the 'master' i set up as a wt anyway [16:37] actually i was kinda curious why the other branches were bigger [16:37] i guess i want to branch remotely [16:38] still have yet to set up http :/ [16:38] I have 'pqm/work' bound to 'pqm/foo'. When I commit in 'pqm/work' (and so in 'pqm/foo') which config in locations.conf will be used, 'pqm/work's or 'pqm/foo's? [16:38] jam: ^ [16:39] Odd_Bloke: that isn't a lightweight checkout... [16:39] but I would guess if you have a bound 'work' => 'foo' then 'work' still gets used for the bound branch [16:39] lifeless: thanks ever so much for your help [16:39] I'm not sure that all functions agree on this, though [16:39] dato: ping [16:39] my friend is so relieved to have all his work back and is very grateful to you :) [16:39] gabe: no probs [16:40] what is a revision that doesn't have descendents and is dead? [16:41] gabe: a dead revision is one that no branch refers to [16:41]