=== echo-are` is now known as echo-area [03:47] afternoon [03:47] I'm seeing a weird error in a bzr tree: [03:47] AssertionError: get_next() called when there are no chars left [03:47] any hints on what it could be? [04:56] bradm: yes, you have a truncated dirstate file. [04:56] bradm: e.g. something powered off or killed a bzr process mid-write. [04:57] bradm: you'll need to replace the dirstate with a fresh one. [04:57] lifeless: that's enitrely possible with this system [05:00] lifeless: I've fixed similar type bugs by branching and then copying the dirstate file back, that seemed to help [05:01] yes [05:01] thats exactly what you need to do. [05:01] And try not to kill bzr so willynilly ;) [05:01] the last error message was a bit more helpful, this one suggested it was an internal error and to file a bug [05:03] ah [05:04] worth reporting a bug [05:04] same root cause but the error could indeed be better [06:01] Y'know there's some command to write out a fresh dirstate. Saves the manual branching and copying around. [06:33] bzr help repair-workingtree [07:26] bzr atomically-write-to-files-to-begin-with [07:27] bob2: bug #98836 ? [07:28] Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836 [07:29] hahaha [07:29] :) [07:29] AFAIR, dirstate is the only file bzr modifies in place [07:33] i used to get a lot of errors relating to locks >.> [07:38] mgrandi: on windows ? [07:39] yeah [07:39] can't really reproduce it consistantly though [07:39] yeah, that's a pita, we know there is something going on but lack reproducible recipes :-/ [07:40] or may be I'm not up to date with the details... [08:13] morning [08:17] vila, why's it done in place? [08:17] bob2: hysterical raisins :-/ [08:18] there is code somewhere to switch to a different implementation but I can't remember where :-/ [08:18] heh [08:19] mgz: ghaa, I looked at the rename_map stuff... looks like I was over-optimistic :-( [08:25] :) [08:48] mgz: on a more positive note, I've got a test for bug #957049 [08:48] Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049 [08:49] ace, so you can stick that on top of larsiq's branch and land [08:50] what ? Without review ? :-D [08:56] submitted against 2.5, will merge up when it lands [09:24] well, you could have put it up for review [09:26] but I trust you to have got the small details right, and trust pqm to tell you if you got anything major wrong :) [09:34] hehe, yeah, sure, but indeed the fix was quite simple (and right to the point), so a test failing without the patch was all that was needed === yofel_ is now known as yofel [13:02] * mgedmin wants $(bzr nick) in his bash prompt [13:03] Easy enough to arrange [13:04] I have all sorts of crazy magic in my bash prompt; multiple VCS integrations, colours, job counts, pushd status,... [13:06] I think I managed: https://github.com/mgedmin/dotfiles/commit/b8a3cbb9074ba6d6309835f2b884168f88975fbe and https://github.com/mgedmin/dotfiles/commit/80d0430c6181ac817ac3f63fa9fe7d5b42bf801f [13:06] (this was going to be url to commit #1 followed by "but it is amaaaaaaaaaaaAAAAAAzingly slow in svn checkouts", but then I discovered bzr help global-options) [13:07] job counts is interesting; could I see your bashrc? [13:07] Mm.. not terribly easily; it's split across about 20 files [13:07] I'll dig out some piece [13:07] also, I'd like to compare the bzr solution -- maybe there's something more efficient/cleverer compared to what I have [13:07] no github url? [13:07] er.. no? [13:08] * mgedmin suddenly realizes github urls might not be the most politic thing to wave around in a #bzr channel [13:09] http://pastie.org/4371428 some bits and pieces [13:11] and the bzr bits? [13:13] http://pastie.org/4371445 [13:18] ooh, clever, only look for dotted dirs when $PWD changes [13:18] (at the cost of not noticing when 'bzr init .' takes place, I suppose) [13:29] Yeah; I considered that reasonable [13:29] bzr is fast enough without that, but p4 is waaaaaaayslow [15:02] hi, can i get some help? i'm having a problem doing a merge, it says 2 revisions are identical, but they do have changes [15:06] Is there a way to stop bzr checking the host authenticity for bzr+ssh connections? Alternatively, can anyone suggest why it might keep asking again and again for the same host? [15:08] Something in your .ssh/config file? [15:08] Have you set the hostkey file to /dev/null? [15:12] * thomi checks [15:13] LeoNerd: nope, the IdentityFile and User is set for that host, but nothing else [15:18] yolanda: need more details to give any kind of answer [15:18] thomi: do you get the same thing if you just ssh to the host? if so, it's not a bzr issue, use `ssh -vv` to debug [15:19] I'd guess something like known_hosts having the wrong perms [15:21] mgz: yes, the same thing happens if I ssh manually. If I manually accept the key, it works for a while, and then starts failing sgain :-/ [15:21] ...almost as if somthing is overwriting the known_hosts file [15:22] anyway, i guess we know it's not a bazaar issue :) [15:25] ah, if it accepts it for a bit sounds more like something along those lines [15:26] I'd try and catch a few that fail with -vv, and double check the fingerprint is actualy static, and keep a few known_hosts copies [17:33] hi, everyone... is cherrypicking that bad? [17:34] because I somehow managed to do it and now in bazaar explorer's log's context menu is showing Reverse cherrypick [17:34] is it something I need to worry about? [17:37] nope, it's a useful thing, but doing it by accident doesn't sound normal [17:38] basically it's a merge of a revision range, which is then just the content of those changes, rather than any of the revision data [17:40] ^^ well, if I remember correctly, I merged into my trunk just one file from other branch === deryck is now known as deryck[lunch] [17:47] mgz: and why no revision data is merged? [18:06] because you're not actually merging that revision === deryck[lunch] is now known as deryck === zyga is now known as zyga-afk === jam1 is now known as jam