[03:47] <bradm> afternoon
[03:47] <bradm> I'm seeing a weird error in a bzr tree:
[03:47] <bradm> AssertionError: get_next() called when there are no chars left
[03:47] <bradm> any hints on what it could be?
[04:56] <lifeless> bradm: yes, you have a truncated dirstate file.
[04:56] <lifeless> bradm: e.g. something powered off or killed a bzr process mid-write.
[04:57] <lifeless> bradm: you'll need to replace the dirstate with a fresh one.
[04:57] <bradm> lifeless: that's enitrely possible with this system
[05:00] <bradm> lifeless: I've fixed similar type bugs by branching and then copying the dirstate file back, that seemed to help
[05:01] <lifeless> yes
[05:01] <lifeless> thats exactly what you need to do.
[05:01] <lifeless> And try not to kill bzr so willynilly ;)
[05:01] <bradm> the last error message was a bit more helpful, this one suggested it was an internal error and to file a bug
[05:03] <lifeless> ah
[05:04] <lifeless> worth reporting a bug
[05:04] <lifeless> same root cause but the error could indeed be better
[06:01] <fullermd> Y'know there's some command to write out a fresh dirstate.  Saves the manual branching and copying around.
[06:33] <vila> bzr help repair-workingtree
[07:26] <bob2> bzr atomically-write-to-files-to-begin-with
[07:27] <vila> bob2: bug #98836 ?
[07:29] <bob2> hahaha
[07:29] <bob2> :)
[07:29] <vila> AFAIR, dirstate is the only file bzr modifies in place
[07:33] <mgrandi> i used to get a lot of errors relating to locks >.>
[07:38] <vila> mgrandi: on windows ?
[07:39] <mgrandi> yeah
[07:39] <mgrandi> can't really reproduce it consistantly though
[07:39] <vila> yeah, that's a pita, we know there is something going on but lack reproducible recipes :-/
[07:40] <vila> or may be I'm not up to date with the details...
[08:13] <mgz> morning
[08:17] <bob2> vila, why's it done in place?
[08:17] <vila> bob2: hysterical raisins :-/
[08:18] <vila> there is code somewhere to switch to a different implementation but I can't remember where :-/
[08:18] <bob2> heh
[08:19] <vila> mgz: ghaa, I looked at the rename_map stuff... looks like I was over-optimistic :-(
[08:25] <mgz> :)
[08:48] <vila> mgz: on a more positive note, I've got a test for bug #957049
[08:49] <mgz> ace, so you can stick that on top of larsiq's branch and land
[08:50] <vila> what ? Without review ? :-D
[08:56] <vila> submitted against 2.5, will merge up when it lands
[09:24] <mgz> well, you could have put it up for review
[09:26] <mgz> 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] <vila> 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
[13:02]  * mgedmin wants $(bzr nick) in his bash prompt
[13:03] <LeoNerd> Easy enough to arrange
[13:04] <LeoNerd> I have all sorts of crazy magic in my bash prompt; multiple VCS integrations, colours, job counts, pushd status,...
[13:06] <mgedmin> I think I managed: https://github.com/mgedmin/dotfiles/commit/b8a3cbb9074ba6d6309835f2b884168f88975fbe and https://github.com/mgedmin/dotfiles/commit/80d0430c6181ac817ac3f63fa9fe7d5b42bf801f
[13:06] <mgedmin> (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] <mgedmin> job counts is interesting; could I see your bashrc?
[13:07] <LeoNerd> Mm.. not terribly easily; it's split across about 20 files
[13:07] <LeoNerd> I'll dig out some piece
[13:07] <mgedmin> also, I'd like to compare the bzr solution -- maybe there's something more efficient/cleverer compared to what I have
[13:07] <mgedmin> no github url?
[13:07] <LeoNerd> 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] <LeoNerd> http://pastie.org/4371428   some bits and pieces
[13:11] <mgedmin> and the bzr bits?
[13:13] <LeoNerd> http://pastie.org/4371445
[13:18] <mgedmin> ooh, clever, only look for dotted dirs when $PWD changes
[13:18] <mgedmin> (at the cost of not noticing when 'bzr init .' takes place, I suppose)
[13:29] <LeoNerd> Yeah; I considered that reasonable
[13:29] <LeoNerd> bzr is fast enough without that, but p4 is waaaaaaayslow
[15:02] <yolanda> 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] <thomi> 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] <LeoNerd> Something in your .ssh/config file?
[15:08] <LeoNerd> Have you set the hostkey file to /dev/null?
[15:12]  * thomi checks
[15:13] <thomi> LeoNerd: nope, the IdentityFile and User is set for that host, but nothing else
[15:18] <mgz> yolanda: need more details to give any kind of answer
[15:18] <mgz> 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] <mgz> I'd guess something like known_hosts having the wrong perms
[15:21] <thomi> 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] <thomi> ...almost as if somthing is overwriting the known_hosts file
[15:22] <thomi> anyway, i guess we know it's not a bazaar issue :)
[15:25] <mgz> ah, if it accepts it for a bit sounds more like something along those lines
[15:26] <mgz> 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] <mnn> hi, everyone... is cherrypicking that bad?
[17:34] <mnn> because I somehow managed to do it and now in bazaar explorer's log's context menu is showing Reverse cherrypick
[17:34] <mnn> is it something I need to worry about?
[17:37] <mgz> nope, it's a useful thing, but doing it by accident doesn't sound normal
[17:38] <mgz> 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] <mnn> ^^ well, if I remember correctly, I merged into my trunk just one file from other branch
[17:47] <mnn> mgz: and why no revision data is merged?
[18:06] <mgz> because you're not actually merging that revision