mathrick | mwhudson: yeah | 00:00 |
---|---|---|
cyberix | still imports the one from site-packages | 00:01 |
mwhudson | cyberix: what exactly are you doing? | 00:02 |
mwhudson | can you pastebin a session? | 00:02 |
cyberix | Just trying to run selftest on a vanilla "checkout" from lp:bzr | 00:03 |
mathrick | mwhudson: it seems to be true for bzr+ssh:// as well | 00:04 |
Verterok | cyberix: that's weird. try removing/not using your current PYTHONPATH, i.e: PYTHONPATH=/path/to/branch | 00:04 |
mwhudson | mathrick: i'm not surprised there | 00:04 |
mathrick | why not? | 00:05 |
cyberix | http://pastebin.com/d73a21e3 | 00:05 |
mwhudson | mathrick: because the code for bzr:// and bzr+ssh:// is basically the same at this level | 00:09 |
cyberix | Verterok: That doesn't change anything | 00:09 |
mwhudson | cyberix: hm, seems to be loading the system plugins | 00:09 |
mwhudson | which is wrong, but less wrong than what you first said | 00:10 |
cyberix | oh | 00:12 |
cyberix | Any further suggestions? | 00:14 |
Verterok | cyberix: you can use the --no-plugins option | 00:15 |
mwhudson | ./bzr --no-plugins selftest | 00:15 |
Verterok | cyberix: also there is the BZR_PLUGIN_PATH env var, in the case that you want to include some plugins in the selftest | 00:16 |
mathrick | mwhudson: ok, do you see a fix? | 00:24 |
mathrick | 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 |
mwhudson | mathrick: not really looked yet | 00:25 |
mathrick | aha | 00:25 |
mwhudson | mathrick: i wonder if i can trick spiv into fixing it | 00:25 |
mathrick | hehe | 00:25 |
mwhudson | spiv: https://bugs.edge.launchpad.net/bzr/+bug/175570 | 00:25 |
ubottu | Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed] | 00:25 |
mathrick | I think he should feel morally obliged to fix it, he knew the bug number instantly when I mentioned it :) | 00:26 |
mwhudson | smart server/remote branches is something he knows more than most about | 00:26 |
* mathrick wonders if that is a good thing | 00:27 | |
cyberix | thanks that helped | 00:28 |
spiv | mathrick: "instantly" is a bit of an exaggeration :) | 00:29 |
cyberix | going to sleep now | 00:29 |
cyberix | good night | 00:29 |
spiv | I had to search Launchpad, but happily searching bugs.launchpad.net/bzr for "cat ObjectNotLocked" found exactly 1 bug. | 00:30 |
mathrick | excuses | 00:34 |
mwhudson | spiv: do you know about the locking thing off hand? | 00:51 |
spiv | locking thing? | 00:59 |
mathrick | spiv: the bug I ran into | 01:00 |
mwhudson | spiv: http://pastebin.ubuntu.com/27148/ | 01:00 |
spiv | mwhudson: that has the same root cause as 175570, I believe | 01:03 |
spiv | There's another related bug report or two, as well. | 01:04 |
mwhudson | spiv: well, i was more thinking that it could be the root cause for that bug | 01:04 |
spiv | mwhudson: well, that's a symptom, not a cause ;) | 01:05 |
mwhudson | spiv: ok | 01:05 |
spiv | The cause is roughly that RemoteBranch.lock_read doesn't call lock_read on its repo. | 01:05 |
spiv | But just simply doing that breaks other things. | 01:05 |
spiv | There's a discussion of this on the list and/or this mysterious other bug report I'm alluding to. | 01:06 |
mwhudson | hm | 01:06 |
spiv | mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/237067 | 01:06 |
ubottu | Launchpad bug 237067 in bzr "RemoteBranch.lock_read() doesn't lock the underlying repository" [High,Confirmed] | 01:06 |
mwhudson | spiv: yay google | 01:07 |
mwhudson | (i just found that too) | 01:07 |
CrashTest_ | 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 ~ | 03:49 |
=== spiv_ is now known as spiv | ||
lifeless | woo, 1.6Million key btrees , no memory _explosion_ | 05:28 |
lifeless | (and thats not the limit, that was just disk spilling when it blew up cause it exceeded the header size) | 05:29 |
=== elmo_ is now known as elmo | ||
lifeless | megarepo test on b+tree indices: | 09:25 |
lifeless | 115M .bzr/repository/indices | 09:26 |
lifeless | down from | 09:26 |
lifeless | 444M backup.bzr/repository/indices/ | 09:26 |
lifeless | poolie: oh yeha, hi :) | 09:26 |
=== wgrant_ is now known as wgrant | ||
poolie | night all | 09:55 |
pagenoare | hi | 10:21 |
pagenoare | anybody using bzrweb with bzr 1.5rc1? :D | 10:22 |
awilkins | lifeless: But are b-trees Faster too? | 10:50 |
lifeless | awilkins: igc mailed the list with some results | 11:28 |
lifeless | awilkins: executive summary: much faster at some things; a bit slower at others, ~= on the rest. | 11:28 |
gabe | hi all | 12:00 |
gabe | wondering if someone might be able to help me out with a bzr related problem | 12:01 |
gabe | get the following error: bzr: ERROR: [Error 32] ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, | 12:01 |
gabe | ╧ЁюЎхёё эх ьюцхЄ яюыєўшЄ№ фюёЄєя ъ Їрщыє, is unreadable meaningless heap of letters! | 12:01 |
gabe | reported it on https://bugs.launchpad.net/bzr/+bug/237305 | 12:01 |
ubottu | Launchpad bug 237305 in bzr "bzr: ERROR: [Error 32] " [Undecided,Incomplete] | 12:01 |
Odd_Bloke | gabe: What OS are you using? | 12:04 |
=== Cael is now known as Splodge | ||
gabe | that's on windows vista with bzr 1.5 | 12:11 |
Odd_Bloke | Hmm, I don't really know enough about Windows to be able to help you debug. :( | 12:13 |
gabe | i know enough about Windows not to use it! | 12:13 |
Odd_Bloke | gabe: That said, attaching the relevant part of .bzr.log to the bug report would probably be helpful. | 12:13 |
gabe | it's actually a russian friend with the problem | 12:13 |
gabe | trying to help him solve it.. | 12:13 |
gabe | i'll see if i can get hold of bzr log | 12:14 |
Splodge | Hi, I'm hoping somebody here can help me: is it possible to compare two branches in bzr? | 12:24 |
Splodge | 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 |
Splodge | ...with bzr incorrectly? | 12:24 |
Kinnison | cd local-branch | 12:25 |
Kinnison | bzr diff http://path/to/remote/branch | 12:25 |
bob2 | 'bzr missing' will show the different commits on each, or you can use bzr diff to show diffs | 12:25 |
lifeless | gabe: sounds liek the error isn't encoding correctly on output | 12:28 |
Splodge | Ah I see. | 12:31 |
Splodge | 'diff' doesn't show anything for me, but 'missing' does list the extra revisions I have locally. | 12:31 |
Splodge | And the --verbose item will show extra details on the changes to files etc. | 12:31 |
Splodge | That's just what I was looking for. Thank you. | 12:31 |
gabe | thanks | 12:34 |
gabe | I got a section of the bzr log attached to the bug report, it's here... http://launchpadlibrarian.net/16008570/bzr.log | 12:35 |
=== emgent_ is now known as emgent | ||
lifeless | gabe: thanks | 13:02 |
=== andrea-bs_ is now known as andrea-bs | ||
=== cody-somerville_ is now known as cody-somerville | ||
awilkins | gabe: ERr 32 is an IO error ; probably a file being held open by another process | 13:17 |
awilkins | gabe: Which shell are you using? THe error text looks like it's in unicode or something | 13:18 |
=== jaypipes_mysql is now known as jaypipes | ||
awilkins | 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:36 |
gabe | yeah it's actually a russian friend I am asking on behalf of | 13:41 |
gabe | what info do you need? | 13:41 |
awilkins | 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 |
lifeless | hmm, I was going to say bzr --version | 13:43 |
lifeless | but it doesn't include the encoding | 13:43 |
lifeless | gabe: does your friend see a readable error? | 13:43 |
gabe | what he sees is what I pasted here | 13:43 |
gabe | error 32 etc | 13:43 |
gabe | and some unreadable junk too | 13:43 |
lifeless | gabe: if what he sees is correctly encoded cp866 he will be able to read it even though we can't | 13:44 |
gabe | he's used bzr for a while | 13:44 |
gabe | no problem | 13:44 |
lifeless | thats the nature of encoding | 13:44 |
gabe | yeah but he said it is junk | 13:44 |
gabe | unreadable even to him | 13:44 |
lifeless | gabe: so I'm tryingt o understand if *he* can read it, not if the copy and pasted stuff is unreadable | 13:44 |
lifeless | ok | 13:44 |
lifeless | so there are two issues: why the error, and the error being unprintable | 13:44 |
gabe | he has a checkout of a branch | 13:44 |
gabe | and been doing about 25 --local commits | 13:44 |
lifeless | as for why the error, does he have an editor open on a file or something? | 13:44 |
gabe | then wanted to commit back to the repo | 13:45 |
gabe | but it said he needed to bzr up | 13:45 |
gabe | so he did bzr up and got this | 13:45 |
=== thekorn_ is now known as thekorn | ||
jelmer | hey * | 13:45 |
gabe | some conflicts | 13:45 |
gabe | and errors | 13:45 |
awilkins | He has a file open | 13:45 |
lifeless | gabe: I would guess an editor open on a file | 13:45 |
gabe | ok | 13:45 |
awilkins | It's during a rename | 13:45 |
lifeless | jelmer: hi | 13:45 |
gabe | i'll make sure he quits any editors and tries again | 13:45 |
awilkins | Windows ia waaay more picky about files being open when it writes over them | 13:45 |
beuno | mornin' all | 13:46 |
jelmer | lifeless: How were things at GUADEC? | 13:46 |
lifeless | jelmer: intense :) | 13:46 |
lifeless | many positive discussions, some rather more neagative | 13:46 |
beuno | lifeless, any guesses on what the outcome for VCS choice will be? | 13:47 |
jelmer | lifeless: what in particular were the negative ones about? | 13:47 |
lifeless | jelmer: some folk felt that canonical was pushing bzr (rather than us being there because gnome devs *wanted* support for bzr) | 13:49 |
lifeless | 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:49 |
jelmer | lifeless: wow, ok | 13:50 |
lifeless | beuno: no idea yet | 13:50 |
Kinnison | The number of people who think that git is the be-all-and-end-all, perfect, etc. does surprise me | 13:51 |
Kinnison | esp. given how I cannot get on with it no matter how hard I try | 13:51 |
lifeless | Kinnison: the number of them that have used bzr in anger appears to approach zero | 13:51 |
Kinnison | lifeless: surprise surprise. | 13:51 |
* Kinnison wishes git was easier and nicer | 13:51 | |
* Kinnison gave up and did his kernel module dev in bzr and supplied a patch to the kernel guys | 13:52 | |
Kinnison | because I just can't get git to be of any use to me | 13:52 |
jelmer | lifeless: Thanks for the update | 13:52 |
lifeless | jelmer: should have a interseting ssvn bug for you soon | 13:53 |
jelmer | I'm looking forward to it ;-) | 13:53 |
pbor | lifeless: did you persuade any gnomers (that currently use svn/git) to at least try bzr? | 13:54 |
lifeless | pbor: yes | 13:54 |
pbor | cool | 13:54 |
lifeless | rob taylor from codethink appears quite excited :) | 13:54 |
asabil | lifeless: are you serious ? | 13:54 |
lifeless | Jc2k: how's your head? recovering from guadec? | 13:54 |
lifeless | asabil: about what? | 13:54 |
asabil | about rob taylor | 13:54 |
pbor | getting people to actually try it is the only way to gain user base :-) | 13:54 |
lifeless | asabil: yes | 13:55 |
asabil | wow ! | 13:55 |
Jc2k | lifeless: my brain is at about 25% usefulness | 13:55 |
asabil | last time I talked to him (a year ago), he was worshiping git | 13:55 |
lifeless | asabil: he's had Jc2k hammering on him way before guadec :) I just added the straw I think | 13:55 |
* Jc2k nods | 13:55 | |
asabil | lol :) | 13:55 |
Jc2k | not just that though | 13:55 |
asabil | well done Jc2k ^^ | 13:55 |
Jc2k | he's been poking the Git source code for his project | 13:56 |
asabil | we need more of you | 13:56 |
Jc2k | and Git source would finish anyone of | 13:56 |
Jc2k | f | 13:56 |
Jc2k | its horrible in there. | 13:56 |
pbor | haha | 13:56 |
asabil | I think bzr developers maybe should start blogging code snippets from git's source code | 13:57 |
asabil | maybe that would shed some light on the evil dark corners of git :p | 13:57 |
beuno | jelmer, btw, which BB are we using for bzr-gtk? it seems we have 2 fighting over it now | 13:58 |
jelmer | beuno, vernstok.nl is still the primary one | 13:58 |
jelmer | until the one on Aarons machine has the right details | 13:58 |
beuno | 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 |
jelmer | cool | 13:58 |
beuno | sorry I've been so unresponsive, but I've had a few unusual weeks :) | 13:59 |
fullermd | Heck, I've had a few unusual _months_... | 14:00 |
awilkins | vila: Ping? | 14:05 |
mtaylor | guys, I love you all, but this: bzr: ERROR: Repository KnitPackRepository() is not compatible with repository KnitPackRepository() | 14:10 |
mtaylor | is quite possibly the worst error message in the history of mankind | 14:10 |
lifeless | mtaylor: totally | 14:10 |
jelmer | mtaylor: Couldn't agree more | 14:11 |
lifeless | mtaylor: and I'm embarrased | 14:11 |
mtaylor | ok. | 14:11 |
lifeless | jelmer: so patch it up :) | 14:11 |
mtaylor | as long as you're embarrassed | 14:11 |
lifeless | jelmer: add the rich root etc stuff to str() | 14:11 |
mtaylor | also, let me verify... | 14:11 |
mtaylor | 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 |
jelmer | lifeless: Maybe once I finish browsing through the bzr-svn bugs from the last 5 days... | 14:12 |
lifeless | jelmer: :) | 14:12 |
lifeless | mtaylor: its a one way trap door; shouldn't be performance implications | 14:12 |
lifeless | holy cow | 14:26 |
lifeless | this index is a 5-level B+Tree | 14:27 |
lifeless | 2.9Million keys | 14:27 |
awilkins | lifeless: Did you think about incredibly-scary-judy-arrays ? | 14:29 |
lifeless | awilkins: yes | 14:33 |
awilkins | I never tried them personally, but the papers read really impressively :-) | 14:34 |
lifeless | 5 IO's per key -> not ideal. But hey, its all of ubuntu. | 14:34 |
lifeless | jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/248406 | 15:05 |
ubottu | Launchpad bug 248406 in bzr-svn "Import of SVK modified SVN repositories" [Undecided,New] | 15:05 |
=== mw|out is now known as mw | ||
gabe | ok my russian friend closed his editor | 15:32 |
gabe | did bzr up | 15:32 |
gabe | this is what he said: | 15:32 |
gabe | i've closed editor and run bzr up and it completely removed all my changes | 15:32 |
gabe | all 26 local commits are disappeared | 15:32 |
gabe | why did it do that!? | 15:32 |
lifeless | gabe: bzr st will show you a pending merge | 15:35 |
lifeless | gabe: and he should now 'bzr commit' to record it and put it in the repository | 15:35 |
gabe | oh | 15:35 |
gabe | lifeless: thanks for your continued assistance | 15:36 |
gabe | i'll check on the bzr st | 15:36 |
lifeless | 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 |
gabe | er | 15:36 |
gabe | this is what his bzr st shows | 15:36 |
lifeless | gabe: check on bzr st :) | 15:36 |
gabe | D:\xampp\htdocs\eastwestfilms\hungerseason>bzr st | 15:36 |
gabe | unknown: | 15:36 |
gabe | .project | 15:36 |
gabe | no merges :( | 15:37 |
lifeless | gabe: bzr heads --dead-only | 15:37 |
lifeless | gabe: he will need bzrtools installed | 15:37 |
gabe | he had a whole bunch of about 25 --local commits | 15:37 |
gabe | lifeless: he has been using bzr for a while without problem? Is he really missing bzr tools? | 15:37 |
lifeless | gabe: the heads command is in bzrtools | 15:37 |
lifeless | 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 |
Splodge | 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 |
gabe | right, i'll make sure he has it installed. | 15:38 |
lifeless | gabe: its there in his repository, we just need to pull it back into his tree | 15:38 |
lifeless | gabe: try the command, if it's unknown command install bzrtools/upgrade bzrtools | 15:38 |
lifeless | Splodge: pull --overwrite | 15:39 |
gabe | try this command? zr heads --dead-only? | 15:39 |
lifeless | gabe: yes | 15:39 |
gabe | bzr heads --dead-only | 15:39 |
gabe | what will it do? | 15:40 |
Splodge | lifeless: Thanks! You guys are good ;) | 15:40 |
lifeless | gabe: report on the name of the stuff he reverted | 15:40 |
gabe | ok i asked him to try | 15:40 |
gabe | lifeless: you are right, unknown command | 15:40 |
gabe | so install bzr tools | 15:40 |
lifeless | gabe: yes | 15:41 |
lifeless | abentley: ping | 15:41 |
abentley | lifeless: pong | 15:41 |
lifeless | abentley: nevermind, something stranger than I considered | 15:42 |
lifeless | 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 "<bzrlib.knit.KnitVersionedFiles object at 0x2ac7674f8810>". | 15:42 |
lifeless | abentley: but the repo has single commits everywhere so it should be impossible | 15:42 |
abentley | lifeless: This is with B+ trees? | 15:43 |
lifeless | abentley: yes, though I think that that is orthogonal | 15:43 |
=== Splodge is now known as splodge | ||
lifeless | I know what is happening | 15:45 |
lifeless | bug in my bug fix | 15:45 |
lifeless | abentley: so yes, it was B+trees | 15:50 |
abentley | lifeless: Glad you found it. | 15:50 |
gabe | how to install bzrtools | 15:52 |
lifeless | abentley: I was handling far right hand end nodes wrong if the node had only one child | 15:55 |
Odd_Bloke | 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:56 |
abentley | Odd_Bloke: Okay, I'll look into it. | 15:57 |
Odd_Bloke | abentley: Thanks. :) | 15:58 |
abentley | Odd_Bloke: Could you file a bug report, please? | 15:58 |
Odd_Bloke | abentley: Sure. | 16:01 |
gabe | ok my friend has bzr tools installed | 16:01 |
gabe | this is the result of bzr heads --dead-only | 16:01 |
gabe | HEAD: revision-id: kos@pixeco.com-20080714080119-60tpfuob57h4zma4 (dead) | 16:01 |
gabe | committer: Kos | 16:01 |
gabe | branch nick: hungerseason | 16:01 |
gabe | timestamp: Mon 2008-07-14 14:01:19 +0600 | 16:01 |
gabe | message: | 16:01 |
gabe | Added sIFR for images caption | 16:01 |
lifeless | gabe: ok, you can now do 'bzr merge -r revid: kos@pixeco.com-20080714080119-60tpfuob57h4zma4' | 16:01 |
gabe | oooh ok | 16:02 |
lifeless | gabe: and then 'bzr commit' | 16:02 |
gabe | that's very precise :) | 16:02 |
lifeless | erm, thats revid:kos... | 16:02 |
lifeless | I added a space by mistake | 16:02 |
lifeless | like so: | 16:02 |
lifeless | 'bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob57h4zma4 .' | 16:02 |
gabe | ok cheers | 16:02 |
lifeless | that will resurrect his patches | 16:02 |
gabe | D:\xampp\htdocs\eastwestfilms\hungerseason>bzr merge -r revid:kos@pixeco.com-20080714080119-60tpfuob | 16:03 |
gabe | 57h4zma4 | 16:03 |
gabe | bzr: ERROR: No location specified or remembered | 16:03 |
gabe | is that bad news? | 16:04 |
lifeless | gabe: add the '.' :) | 16:04 |
jam | gabe: there is a hard to see '.' after the revid | 16:04 |
jam | you could alternatively change the order | 16:04 |
jam | bzr merge . -r revid:..... | 16:04 |
jam | lifeless: are you still in Europe? | 16:05 |
gabe | lifeless: yep, quite right! | 16:05 |
lifeless | jam: London indeed | 16:05 |
lifeless | gabe: happy to help, sorry it took up your friends time | 16:05 |
Odd_Bloke | abentley: https://bugs.launchpad.net/bundlebuggy/+bug/248422 | 16:05 |
jam | lifeless: how long before you head back to AU? (Just curious how much time you'll be awake when I am :) | 16:05 |
ubottu | Launchpad bug 248422 in bundlebuggy "Merging of patches to PQM trunk not detected" [Undecided,New] | 16:05 |
abentley | Odd_Bloke: Was the patch merged after BB started tracking PQM? | 16:06 |
lifeless | jam: 1 week | 16:08 |
gabe | lifeless: we're still working on that last command | 16:09 |
gabe | seems he gets | 16:10 |
gabe | "'bzr" is not recognized as an internal or external command, | 16:10 |
gabe | operable program or batch file. | 16:10 |
lifeless | gabe: well, how does he run bzr normally ? :) | 16:10 |
gabe | is that because windows doesn't recognise the quotes around the command? | 16:10 |
lifeless | gabe: you shouldn't copy the quotes, they were to show you what to copy :) | 16:10 |
gabe | he uses the bzr command but not with quotes around it I guess | 16:10 |
gabe | oh woops | 16:10 |
gabe | that worked | 16:12 |
gabe | 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 |
lifeless | gabe: it does not wipe them away; you have to run 'bzr revert' to wipe them away | 16:13 |
gabe | so what does it do with my local commits then? | 16:13 |
gabe | and why are they 'taken away'? | 16:13 |
lifeless | it puts them into a pending merge | 16:14 |
lifeless | so that after the update, when yo commit they go into the master | 16:14 |
lifeless | and they are taken away when you run 'bzr revert' because bzr revert removes pending merges | 16:15 |
Odd_Bloke | abentley: I _think_ so, but I'll go and check timestamps. | 16:15 |
gabe | but bzr st doesn't show them? | 16:15 |
lifeless | gabe: bzr st will show them | 16:16 |
gabe | i mean i thought merges didn't really happen with checkouts | 16:16 |
lifeless | gabe: I assure you, he ran - 'bzr up' and then 'bzr revert' | 16:16 |
lifeless | gabe: checkouts can totally do merges | 16:16 |
gabe | ok, so in the future, when my local revisions appear to have been nuked what should be be looking at doing? | 16:16 |
lifeless | gabe: dont run bzr revert after an update and they will never appear to have been nuked | 16:16 |
gabe | mmm ok | 16:17 |
Odd_Bloke | 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 |
lifeless | 'bzr update && bzr revert' is guaranteed to give you a tree the same as the thing you have a checkout of. | 16:17 |
lifeless | gabe: (&& means followed by) | 16:17 |
gabe | ah ok | 16:17 |
gabe | and then what did you do to fix that? merge the current tree with a previous version that included local commits? | 16:18 |
lifeless | bzr update && bzr commit is guaranteed to commit your local edits to the thing you have a checkout of. | 16:18 |
lifeless | yes, the use of heads --dead-only, and merge, is how we reinstated the local commits. | 16:18 |
abentley | Odd_Bloke: I'm not sure when the last tweak of the merge-detection code happened. It may have been afterward. | 16:19 |
lifeless | jam: I am going to make the last node in a row be variable-sized | 16:22 |
lifeless | jam: using b+tree indices in bzr search.. hurt | 16:22 |
jam | lifeless: I understand your desire, but isn't that the last node in the *last* row only? | 16:23 |
lifeless | jam: yes | 16:23 |
gabe | i need to find out about bzr heads | 16:23 |
gabe | bzr heads | 16:24 |
gabe | bzr: ERROR: unknown command "heads" | 16:24 |
gabe | even after doing: sudo ./setup.py install | 16:24 |
lifeless | jam: its actually really the use of many tiny indices *I think* | 16:24 |
gabe | in the bzrtools extraction dir | 16:24 |
lifeless | gabe: what path did it install into | 16:24 |
jam | lifeless: you realize, that is probably sub-optimal from an FS perspective anyway | 16:25 |
gabe | Writing /Library/Python/2.5/site-packages/BzrTools-1.5.0-py2.5.egg-info | 16:25 |
jam | considering most FS have a minimum 4k page | 16:25 |
lifeless | jam: they are in a pack | 16:25 |
jam | lifeless: you are putting the indexes into a pack file... ok, I guess | 16:25 |
lifeless | jam: better than 100000 files on disk :) | 16:26 |
lifeless | jam: ask mtaylor how long the earlier editions took to delete an index :) | 16:26 |
mtaylor | jam: oit was not pretty :) | 16:26 |
jam | lifeless: because deleting required re-packing everything? | 16:27 |
jam | sounds like a flag "deleted" case :) | 16:27 |
lifeless | jam: no, because ext3 doesn't handle hundred's of thousands of files in a single directory gracefully | 16:27 |
lifeless | jam: bzr-search doesn't delete stuff anyway | 16:28 |
jam | ah, before the packing | 16:28 |
jam | yeah, I seem to remember running into that in the past | 16:28 |
jam | when we were working on medical images and dumped 100k files in a directory | 16:28 |
jam | I had to write a custom script that used the raw C files to move them out | 16:28 |
jam | the raw C *functions* | 16:29 |
jam | because 'ls *' or python listdir() would just take forever to finish | 16:29 |
gabe | ls /Library/Python/2.5/site-packages/bzrlib/plugins/bzrtools/ | 16:30 |
gabe | __init__.py dotgraph.pyc rspush.py | 16:30 |
gabe | etc | 16:30 |
gabe | seems to be there | 16:30 |
jam | gabe: I would double check that "bzr --version" lists /Library/Python/2.5/site-packages/bzrlib as its bzrlib location | 16:30 |
gabe | ha no | 16:31 |
gabe | it doesn't | 16:31 |
gabe | best fix that | 16:31 |
jam | Odd_Bloke: still getting your random commits on the commit list | 16:34 |
jam | http://bzr.daniel-watkins.co.uk/pqm/work/foo "renamed 'foo' => 'bar'" | 16:34 |
meteoroid | 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 |
meteoroid | clearly there is something basic i don't understand, anyone care to proffer a link or something? | 16:35 |
Odd_Bloke | jam: Ah, thanks. | 16:35 |
jam | 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 |
jam | you should still have all the revision data | 16:36 |
jam | just no working files | 16:36 |
Odd_Bloke | 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 |
meteoroid | jam: ah ok, that's what i figured, is there some command i run to turn a branch into a wt? | 16:36 |
jam | Odd_Bloke: are you saying light weight => branch => other_branch ? | 16:36 |
jam | meteoroid: 'bzr co' | 16:36 |
jam | but the WT won't be updated by default either | 16:37 |
jam | (there are some workarounds for this) | 16:37 |
meteoroid | hm | 16:37 |
meteoroid | well i shouldn't use the 'master' i set up as a wt anyway | 16:37 |
meteoroid | actually i was kinda curious why the other branches were bigger | 16:37 |
meteoroid | i guess i want to branch remotely | 16:37 |
meteoroid | still have yet to set up http :/ | 16:38 |
Odd_Bloke | 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 |
Odd_Bloke | jam: ^ | 16:38 |
jam | Odd_Bloke: that isn't a lightweight checkout... | 16:39 |
jam | but I would guess if you have a bound 'work' => 'foo' then 'work' still gets used for the bound branch | 16:39 |
gabe | lifeless: thanks ever so much for your help | 16:39 |
jam | I'm not sure that all functions agree on this, though | 16:39 |
lifeless | dato: ping | 16:39 |
gabe | my friend is so relieved to have all his work back and is very grateful to you :) | 16:39 |
lifeless | gabe: no probs | 16:39 |
gabe | what is a revision that doesn't have descendents and is dead? | 16:40 |
lifeless | gabe: a dead revision is one that no branch refers to | 16:41 |
lifeless | gabe: a revision with no commits that build upon it is a head | 16:41 |
Odd_Bloke | jam: It _is_ a lightweight checkout, I presumably didn't mean 'bound to'. :) | 16:41 |
jam | Odd_Bloke: lightweight will use the target | 16:41 |
gabe | and that is what you get if you do bzr up && bzr revert ? | 16:41 |
jam | that I'm sure of | 16:41 |
jam | when we open a light checkout, it instantly redirects to open the target branch | 16:42 |
jam | so we don't really ever *see* the lightweights fake branch | 16:42 |
jam | and almost all config is done at the Branch level, not the WT level | 16:42 |
lifeless | gabe: yes | 16:42 |
jam | lifeless: for the 'failure during deep copy' do you have any hints as to what happened? | 16:48 |
jam | Did it just fail *to* deepcopy? | 16:48 |
jam | (I'm testing with python 2.4.5 and things seem to work) | 16:48 |
lifeless | it just failed to copy | 16:48 |
lifeless | it was 2.4.4 | 16:48 |
lifeless | (manganese) | 16:48 |
jelmer | lifeless, Odd_Bloke: Are you going to be around for some sprinting before saturday? | 16:50 |
lifeless | jelmer: I'm in London, get to wolverhampton 9pm friday | 16:50 |
jelmer | I'm in Dublin atm and trying to decide whether to go home for a day or two or to go there directly | 16:50 |
jelmer | lifeless, ah, ok | 16:50 |
lifeless | jelmer: if you wanted to come to London for a bit I'm sure that would be ok | 16:51 |
jam | lifeless: well, the trivial "a = array.array(...); b = copy.deepcopy(a)" works on manganese :( | 16:53 |
lifeless | jam: I was running 'bzr upgrade --btree-plain' with blooms enabled | 16:53 |
lifeless | jam: and this made it fall down go boom | 16:54 |
jelmer | lifeless, That may be a nice idea | 16:54 |
lifeless | jelmer: let me confirm then | 16:54 |
jam | I wonder if it might have been an OOM error | 16:54 |
Odd_Bloke | jelmer: I'm in Coventry (at home) ATM. | 16:55 |
lifeless | jelmer: yes, wouldn't be a problem for you to drop into the office; ned to know the days in advance though :) | 16:58 |
lifeless | jam: don't think so | 16:58 |
lifeless | jam: it had _much_ more meory problemms earlier when it was digging GB's into swap | 16:58 |
jelmer | lifeless: cool, thanks. I'll see if I can figure out the travel | 17:00 |
Odd_Bloke | jelmer: I don't have any solid committments this week, though, so I'm available for sprinting. | 17:00 |
jam | lifeless: that is where you are testing the 1M keys ? | 17:00 |
lifeless | jam: yeah, I have it in btree-plain now | 17:01 |
jam | and if there is memory fragmentation, it is *possible* for it still to die if array's require contiguous memory | 17:01 |
lifeless | jam: it was something about number pof parameters to a method I think | 17:01 |
lifeless | jam: its 2.9M keys btw | 17:02 |
lifeless | jam: look in ~robertc/megarepo/.bzr/repository/indices :) | 17:02 |
jam | lifeless: we seem to have a 16GB pack file in there. I'm kind of happy to see that we support >4GB files :) | 17:04 |
jam | though I wonder if we *really* want to :) | 17:04 |
lifeless | jam: yes, otherwise latency++++ | 17:05 |
jelmer | Odd_Bloke: Ah, cool - how far are you from Wolverhampton? | 17:06 |
jam | lifeless: so that is just an aggregate repo of a bunch of different projects, right? | 17:06 |
lifeless | jam: oh, it was 2.5 that blew up | 17:06 |
lifeless | selected = min(candidates, key=getter) | 17:07 |
lifeless | TypeError: min() takes no keyword arguments | 17:07 |
lifeless | thats on 2.4 | 17:07 |
Odd_Bloke | jelmer: About an hour by train. | 17:07 |
lifeless | jam: getting content out: | 17:08 |
lifeless | time python2.5 bzr/bzr branch megarepo/pool/main/libj/libjpeg6b/ | 17:08 |
lifeless | real 0m5.365s | 17:08 |
lifeless | then | 17:08 |
lifeless | real 0m1.380s | 17:08 |
lifeless | real 0m2.433s | 17:08 |
lifeless | (the machine is being hammered right now :)) | 17:08 |
jam | lifeless: well, the 1.8G resident is a bit of an issue | 17:09 |
lifeless | jam: thats the bzr search task | 17:09 |
lifeless | jam: which is using GraphIndex still (see the 4K page thing I mentioned :)) | 17:09 |
jam | james_w: by the way, thanks a *ton* for doing all the work you've been doing on managing the bug tracker, it is really nice to have someone on top of it | 17:13 |
james_w | no problem, I think there's quite a bit more to do to get importance/status assigned. | 17:14 |
lifeless | mtaylor: ping | 17:15 |
mtaylor | lifeless: pong | 17:15 |
lifeless | mtaylor: you were working on server-side email right? | 17:15 |
mtaylor | lifeless: was looking at it | 17:15 |
lifeless | mtaylor: the savannah folk are looking for that : if you could put your branch up that would rock :) | 17:15 |
mtaylor | lifeless: I settled on a modification of bzr-email though | 17:15 |
mtaylor | lifeless: so I have nothing for them :( | 17:16 |
lifeless | oh | 17:16 |
lifeless | nuts :) | 17:16 |
mtaylor | yeah | 17:16 |
mtaylor | sorry | 17:16 |
lifeless | is your modifcation general purpose? you could put it up anyhow :) | 17:16 |
Odd_Bloke | jelmer, lifeless: I'm going out for the evening, let me know if anything transpires sprint-wise and I'll respond when I get back. :) | 17:56 |
lifeless | Odd_Bloke: its up to jelmer really :) | 17:57 |
Odd_Bloke | jelmer: Let me know. :) | 18:42 |
agoebel | is there a way to have the webdav plugin handle authentication? | 19:32 |
abentley | lifeless: ping | 19:53 |
vila | agoebel: the webdav plugin handles authentication by relying on bzr http client implementation handling authentication :) | 19:56 |
* vila ducks | 19:57 | |
agoebel | in which case why am I getting a "can't handle 401 auth required" response? | 19:57 |
vila | either because you didn't specify user in url (http://user@host) or your password is wrong | 19:59 |
agoebel | ah, missed the user | 20:00 |
agoebel | figured it would give my a prompt | 20:00 |
agoebel | thanks | 20:00 |
vila | alternatively you can also use authentication.conf to provide user and/or password | 20:00 |
LarstiQ | having it prompt would be real nice | 20:00 |
vila | bug already filed (can't remember it right now, and I'm gone anyway :) | 20:01 |
jelmer | Odd_Bloke, will do | 20:17 |
dato | lifeless: pong | 20:22 |
jelmer | lifeless, ping | 20:34 |
colbrac | jelmer: Currently from olive pressing the push button in the push dialog succesfully pushes, but also gives a bzr-gtk error 'int argument required' | 20:43 |
colbrac | jelmer: Any clue? | 20:43 |
jelmer | colbrac: bzr-gtk probably expects the push function to return an integer | 20:43 |
jelmer | whereas it returns an object these days | 20:44 |
jelmer | PushResult I think | 20:44 |
jelmer | See bzrlib.branch.Branch.push | 20:44 |
colbrac | I see a 'rev = 0' a few lines higher yes | 20:45 |
colbrac | where later try: rev = dopush() | 20:45 |
jelmer | right, rev would actually be a PushResult object rather than the number of revisions pushed | 20:45 |
colbrac | so, in the final lines of that method an info dialog is made with revs as the number of revs pushed | 20:48 |
colbrac | how can I get that number from PushResult? | 20:49 |
colbrac | (if you happen to know by heart) :) | 20:49 |
colbrac | jelmer: The push you are pointing at says 'raise NotImplementedError(self.push)' | 20:50 |
colbrac | :P | 20:50 |
jelmer | colbrac: Well, that should have the API description | 20:50 |
jelmer | See bzrlib.branch.PushResult for the object that's returned by push() | 20:51 |
colbrac | hmm.. has deprecated all over it.. but should return the revno on initiation.. :/ Maybe not initiated anymore in bzr trunk? | 20:53 |
jelmer | I don't see any deprecated stuff there | 20:56 |
jelmer | what in particular are you referring to? | 20:56 |
colbrac | I'm looking in bzr/trunk/bzrlib/branch.py line 2230: class PushResult | 20:57 |
colbrac | But on a closer look of bzr-gtk/trunk/push.py, I don't see any bzrlib.branch imports | 20:58 |
colbrac | bzr trunk as of yesterday | 20:58 |
colbrac | bzr-gtk rev 531 | 20:58 |
jelmer | colbrac: that's because it already has a branch instance | 20:59 |
jelmer | that gets passed to it | 20:59 |
jelmer | there's no need for imports | 20:59 |
colbrac | so.. if I read that do_push function correctly, the count var that is returned is not set when a correct branch_to location is given from the start? | 21:03 |
colbrac | which explains the lack of an int | 21:04 |
colbrac | jelmer: The count var is not set in do_push when the first try is succesfull | 21:07 |
colbrac | jelmer: push to '../folder-that-didnt-exist' doesn't give the error, and a PushResult is returned | 21:14 |
jelmer | colbrac: it is, see the "else:" clause | 21:28 |
=== davi__ is now known as davi | ||
jelmer | the problem is the fact that br_to.pull() no longer returns an integer | 21:29 |
colbrac | but check.. it does br_to.pull | 21:29 |
colbrac | I saw | 21:29 |
jelmer | Odd_Bloke,lifeless: I'll arrive on wednesday in London | 21:30 |
jelmer | colbrac: Yeah, that's correct | 21:31 |
lifeless | dato: I wanted to chat with you about the use of the index in git and what we might do similarly | 23:29 |
lifeless | dato: but its way late for me now; perhaps tmorrow? | 23:30 |
lifeless | night all | 23:30 |
beuno | g'night lifeless | 23:30 |
dato | lifeless: it's late here too :) | 23:30 |
dato | but I'm only available evening UTC | 23:30 |
* ToyKeeper would love to hear about that too | 23:32 | |
agoebel | does anyone have the trunk of bzr-gedit working with gedit 2.22.3? | 23:38 |
=== mw is now known as mw|out | ||
=== mwhudson_ is now known as mwhudson |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!