[00:00] <markh> there's your problem :)
[00:00] <disturbedsaint> its hg :/
[00:00] <disturbedsaint> ill uninstall
[00:00] <markh> well
[00:00] <markh> just work out how it got on your sys.path
[00:00] <disturbedsaint> was comparing hg with bzr :P
[00:01] <markh> but yeah, this channel will be unlikely to adise you to *not* uninstall hg ;) :)
[00:01] <disturbedsaint> :P
[00:02] <markh> it looks like tortoise's installer or something is broken - tbzr should not interfere with a stand-alone python install :(
[00:02] <markh> s/tortoise/hg/
[00:02] <markh> ack :) s/tbzr/hg/ too -  I think I'll give up :)
[00:07] <disturbedsaint> I guess thg's install is broken then, since it does somehow add itself to sys.path
[00:07] <disturbedsaint> when I just run a python shell though it's not there
[00:09] <markh> strange
[00:09] <markh> maybe the python.dll from that dir is found before any others?
[00:10] <markh> if that dir is before system32 on PATH I could see that happening...
[00:10] <disturbedsaint> will have a look,
[00:10] <disturbedsaint> in the trace it says bin path =  C:\Program Files\TortoiseHg
[00:11] <disturbedsaint> you're right I guess "C:\Program Files\TortoiseHg;C:\Program Files\TortoiseSVN\bin;C:\Python25"
[00:13] <markh> hrm - bin path should include \windows\system32 - all should work if you move that before hg
[00:13] <markh> or uninstall hg :)
[00:13] <disturbedsaint> yeah :P
[00:13] <disturbedsaint> will do!
[00:13] <disturbedsaint> bad behaviour! :P
[00:14] <markh> for my interest, why are you playing with sources instead of just the binaries?  you hoping to hack a little?
[00:14] <Peng_> Maybe you should take this up with the hg guys too to get that side of it solved.
[00:14] <disturbedsaint> yeah I'd like to get the latest version
[00:14] <disturbedsaint> +I don't mind to do a little trial&error/editing here and there to make it work
[00:15] <disturbedsaint> Can't fix a lot (yet, still want to learn more bout python) but can at least file bugs and test
[00:15] <markh> yeah - its possibly just their installer.  I'm not sure I'll get to finding and subscribing to their mailing lists etc
[00:16] <markh> ultimately we will be replacing that code with c++ anyway, so it should be less of a problem.
[00:16] <markh> and hopefully 'ultimately' means 'in the next couple of months'
[00:17] <disturbedsaint> you also know c++ or is someone else going to do the codeing?
[00:17] <markh> i know it too
[00:17] <disturbedsaint> I can file a bug for hg btw
[00:18] <markh> are you sure you didn't manually add that dir to your PATH?
[00:18] <disturbedsaint> the hg dir?
[00:18] <markh> if not, I guess the bug should say "please ensure you add yourself to the end of PATH, not the start"
[00:18] <disturbedsaint> 100% sure I didnt do that myself
[00:18] <markh> yeah
[00:19] <markh> cool
[00:19] <markh> and say "the problem is that python COM objects rely on pythonxx.dll being found on PATH, and if the hg one is found before the one in system32, COM objects will use the incomplete hg python modules and likely fail"
[00:20] <disturbedsaint> k
[00:20] <disturbedsaint> will do, thx!
[00:22] <disturbedsaint> yeay! I've go overlayed icons now!
[00:22]  * disturbedsaint = happy :)
[00:27] <Peng_> Ehh..
[00:29] <markh> woohoo :)
[00:34] <disturbedsaint> markh I've submitted a "bug" btw with the icon for the systray
[00:35] <markh> yeah, I saw that, thanks.
[00:35] <disturbedsaint> it's not included and seems to be hardcoded to "C:\Python25\Lib\site-packages\bzr.ico"
[00:35] <markh> its "hard-coded" to the parent of bzrlib
[00:35] <disturbedsaint> couldn't find where it was set in the sources
[00:35] <markh> if bzrlib is run from a source build it works
[00:36] <disturbedsaint> ah ok, thats why I couldn't find it
[00:36] <markh> somewhere like fixup_icon in tbzrlib\*.py
[00:36] <markh> its possible to use bzr from a source tree - just set PYTHONPATH to point at that too.  Then the icon will work.
[00:37] <markh> Note that all "help" links will also fail in source builds as we can't locate the built bzr docs.
[00:37] <disturbedsaint> I see, will do that
[00:37] <disturbedsaint> k
[00:37] <markh> (but at least it says "sorry - can't locate the docs in a source build" :)
[00:37] <disturbedsaint> also noticed the 3 links from the traymenu don't do anything
[00:37] <disturbedsaint> help/settings/about
[00:38] <markh> they should.  check .bzr.log
[00:39] <markh> you have the qbzr plugin installed?
[00:40] <markh> note that for debugging, it might be useful to exit the taskbar process, then manually execute 'python tbzrcache.py -v' - that will re-run the taskbar program, but show output on the console as well as logging it.
[00:40] <disturbedsaint> thats easier indeed
[00:40] <disturbedsaint> and I dont have qbzr atm because of the clean install :/
[00:40] <beuno> lifeless, it is
[00:41] <beuno> I sent you the traceback a few days ago
[00:41] <markh> you won't get too far without it.
[00:41] <beuno> probably wan't a good idea not to report it
[00:41] <beuno> Peng_, pong!
[00:41] <disturbedsaint> ok :) will fix that tomorrow, time to go to bed, quiet late already
[00:42] <disturbedsaint> Thanks a lot for your help!
[00:42] <markh> cheers!  good night!
[00:42] <disturbedsaint> thx
[00:43] <disturbedsaint> have a nice day!
[00:43] <disturbedsaint> bye!
[00:43] <markh> you too
[00:43] <Peng_> beuno: Hahaha, hi.
[00:47] <Peng_> beuno: Um..a few days after the abstract_paths stuff, Googlebot started causing lots of errors like 'NoSuchId: The file id "<whatever>" is not present in the tree None.'I guess it was finding links to files in revisions where they didn't exist? Do you think that could have happened?
[01:01] <beuno> Peng_, well, my guess would be that it was still lookinf for file IDs
[01:01] <beuno> although, those URLs should probably be valid...
[01:02] <Peng_> Hmm
[01:03] <Peng_> You're right. At least one example was with a file ID.
[01:04] <beuno> Peng_, I will do some tests and see if I broke fileids
[01:04] <beuno> I shouldn't of
[01:05] <Peng_> Euhh.
[01:06] <Peng_> One of the requests that bombed was for /annotate/811/some/path?file_id=totally_different_file_id
[01:07] <fullermd> It's reaching into the future and handling the result from 'bzr cp'.
[01:08] <Peng_> fullermd: It's not handling it very well. :P
[01:08] <Peng_> How do you check the file ID of a path?
[01:08] <fullermd> No, _it's_ handling it fine.  It's not Google's fault your version of bzr is too old   :p
[01:08] <lifeless> beuno: I filed a bug with the fix
[01:08] <lifeless> beuno: you broke it :)
[01:09] <Peng_> lifeless: Who broke what?
[01:09] <Peng_> Are we talking about me?
[01:09] <Peng_> (I mean, my issue)
[01:09] <fullermd> Colonel Mustard, in the library, with the wrench.
[01:10] <lifeless> beuno: loggerhead's search facility
[01:10] <Peng_> Oh.
[01:16] <beuno> lifeless, I did?  aw...
[01:16] <beuno> I'll merge it in tomorrow
[01:16] <beuno> thanks
[01:16] <lifeless> beuno: [(foo)] != [(foo,)]
[01:16] <beuno> now, I need some sleep to manage the halloween alcohol  :)
[01:17]  * beuno waves
[01:17] <lifeless> be
[01:17] <lifeless> bye
[01:21] <Peng_> G'night.
[10:30] <gour> what 1.9 format brings?
[10:40] <gour> will 1.9 remove some of the old formats?
[10:42] <luks> bzr doesn't remove all formats
[10:43] <luks> old
[10:45] <AfC> Well, as long as we can get rid of the gawdawful mess that is present in the help of `init` and `init-repo`, what is silently supported doesn't matter. But right now that is the very first impression one has of bzr, and it howls.
[11:21] <Odd_Bloke> I think the first impression one has of bzr is whatever the tutorial you're following tells you.
[11:24] <gour> still, looking at plethora of formats is not encouraging...
[11:26] <Odd_Bloke> No, that's true.
[11:30] <gour> some months ago, shortly after moving to bzr, i asked the same question and all what changed is some new formats :-)
[13:43] <jelmer> gour, I really think we should move to using a rich root format as default..
[13:44] <jelmer> gour, that eliminates half of the formats for the future
[13:44] <gour> jelmer: i agree. the present situation is messy...too many formats
[13:45] <gour> the 'old' formats should become 'hidden'
[13:48]  * gour is doing sys-upgrade which brings python-2.6
[14:09] <AnMaster> hm?
[14:09] <AnMaster> pack-0.92?
[14:10] <AnMaster> yeah why haven't the default format changed from that yet (in 1.8 which is what I have)
[14:16] <gour> and we got new '1.6' formats
[18:00] <rocky> how is python2.6 support with bzr 1.9 ?
[18:03] <LarstiQ> rocky: afaik all known 2.6 issues were released in 1.8
[18:03] <rocky> oh cool
[18:03] <LarstiQ> ehm, fixes for those issues
[18:03] <LarstiQ> rocky: so I expect 1.9 to be all dandy
[18:03] <rocky> jelmer: which version of bzr-svn for bzr 1.9 ? :)
[18:35] <ronny> hmm, how much better is bzr v1.9?
[18:55] <fullermd> .1 obviously.
[19:31] <lifeless> Peng_: how are you liking btrees?
[20:10] <LarstiQ> ronny: any area in specific?
[20:11] <LarstiQ> ronny: it has things I care about, but you might not.
[20:11] <ronny> LarstiQ: speed, repo size?
[20:11] <ronny> hmm
[20:11] <ronny> sometimes i wish bzr had a monotone-style branching ui with updates to specific revisions
[20:12] <LarstiQ> ronny: btree indices in format 1.9, pack optimizing for size more (possibly 25%), less memory usage for checkout, annotate fast path
[20:13] <LarstiQ> ronny: I'm unfamiliar with monotone I'm afraid, other than using it as part of the OpenMoko build
[20:13] <ronny> LarstiQ: branches can have multiple heads, and one can easyly move the dirstate to previous revisions within that branch
[20:14] <LarstiQ> ronny: just the dirstate, or does that also work well for daggy fixes?
[20:14] <ronny> of course well for dagy fixes
[20:15] <LarstiQ> ok, so what's the ui like?
[20:15] <ronny> mtn up -r the_rev_i_want; edit; commit;merge
[20:15] <ronny> btw, it works the same in hg
[20:16] <LarstiQ> how far would you be along to that if you had up -r?
[20:16] <fullermd> mtn's allowing multiple heads on a branch is what makes daggy fixing work so well there.
[20:16] <fullermd> Without that, it's a whole lot more work.
[20:16] <LarstiQ> (ie, hg, in the case of two heads, automatically merges them with an unqualified merge iirc)
[20:16] <fullermd> (now, you don't _actually_ need to support multi-headed branches to do it per se, but you have to hack up something near indistinguishable)
[20:17] <ronny> LarstiQ: hu? hg doesnt auto-merge multiple heads
[20:17] <LarstiQ> ronny: I mean, you don't have to specify what you want to merge, if you say you want to merge, and have two heads
[20:17] <LarstiQ> ronny: is that wrong?
[20:17] <ronny> LarstiQ: ah, ok thats right
[20:18] <LarstiQ> that latter part might be a bit troublesome
[20:18] <LarstiQ> oh, but no
[20:19] <LarstiQ> it could work nicely if you had a :other-head style thing
[20:19] <fullermd> Well, it works in mtn since that's all that 'merge' does.
[20:20] <LarstiQ> fullermd: right, bzr already has a meaning for just 'bzr merge'
[20:21] <luks> hm, committing to an "outdated" tree and updating only the tree parent id (not the branch) seems like an interesting idea
[20:21] <fullermd> Well, I haven't put much thought into the best way to represent it in bzr.  I mean, we can't even update -r yet...
[20:22] <luks> it would be basically like a local commit in a bound branch
[22:19] <LarstiQ> jam: hmm, your file_log plugin breaks selftest in an interesting way
[22:21] <LarstiQ> jam: not that that is relevant anymore, but it tries to load 'bzrlib.plugins.file_log.', which then gets to 'module = getattr(module, '')', and suprisingly module doesn't have a '' attribute.
[23:44] <rod__> hi, i'm trying to do 'bzr ls --kind=directory --non-recursive mybranch/some/folder' to list the contents of a directory in a branch, but it doesn't return any results.  i know this seems like a very basic question, but i can't find much help by searching for it.  thanks