[00:18] <Peng> "Rendering RevisionUI: 51.553565979003906 secs, 35388458 bytes, 15192308 (42.9%) bytes saved" <-- Oops.
[00:21] <Peng> I accidentally loaded it again, and this time it took 73 seconds. :)
[02:04] <sstangl> Does bzr have a way to auto-generate a patch?
[02:05] <sstangl> I want to generate a patch from local branch "development" against local branch "trunk" to be emailed.
[02:07] <sstangl> ah, send.
[02:20] <mib_zv5ff9> I use bazaar to track version changes with my python application...  you know that __version__ attribute seen in most python programs?  I was wondering if those are typically automatically given a value after doing a version commit (and how to do that), or if the developer puts in a number manually?
[03:00]  * rockstar looks around for james_w
[05:26] <lifeless> rockstar: james_w is on utc time
[05:28] <rockstar> lifeless, yea, I knew that, but thought I'd try anyway.
[05:29] <lifeless> 1am - hoopeful :)
[06:44] <abentley> lifeless: morning.
[06:47] <lifeless> hi abentley
[06:48] <abentley> lifeless: When are you flying?
[06:48] <lifeless> leaving hotel at 1100
[06:49] <abentley> I was thinking 11:45
[06:49] <lifeless> that would be too late for my flight, have to be at airport by 1200
[06:50] <lifeless> so I'm catching a lift with davyd
[06:51] <abentley> Okay.  I'm packing right now, but ping me if you want to pair on something, or just hang out.
[06:52] <lifeless> k
[06:52] <lifeless> I'm eating now
[06:53] <lifeless> the 333MB index has under 1MB left to parse
[06:53] <abentley> Teh Rock!
[06:59] <LaserJock> jelmer: around?
[07:01] <Peng> lifeless: With your mailing list message about adding bzr-svn to the PPA, do you mean 0.4.10? Because it's gotten significantly better since then..
[07:01] <lifeless> Peng: 0.4.aything >> None
[07:02] <Peng> 0.4.11exp0? :D
[07:02] <lifeless> well
[07:02] <LaserJock> I updated my bzr-svn branch (0.4) and now it fails to load
[07:02] <lifeless> concretely I'd like something that matches the bzr in each ppa
[07:02] <lifeless> LaserJock: run make
[07:03] <Peng> lifeless: The 0.4 branch matches bzr.dev. :P
[07:03] <lifeless> Peng: if you use the ppa today you end up not having bzr-svn
[07:03] <lifeless> Peng: this is a bug
[07:04] <LaserJock> hmmpf, it needs apr-config
[07:04] <Peng> Are you implying that the PPA works?
[07:05] <Peng> Wow, it's been almost 2 months since 1.5 was released.
[07:05] <Peng> 1 month since 1.6b2.
[07:15] <LaserJock> ok, phew, got it working again :-)
[07:25] <lifeless> time to finish packing
[07:26] <Peng> You people with your lives and traveling and contributions to society... Pssh.
[07:32] <lifeless> :)
[07:33] <LaserJock> oh darn, I'm in a bit of a pickle :/
[07:34] <LaserJock> are there any bzr-tools packages compatible with the bzr 1.6 betas?
[07:34] <lifeless> yes
[07:34] <lifeless> 1.6 bzrtools should be in the beta ppa
[07:34] <LaserJock> ... it's not
[07:35] <lifeless> oh
[07:35] <LaserJock> https://edge.launchpad.net/~bzr-beta-ppa/+archive only has bzr
[07:35] <lifeless> well its at lp:bzrtools I think
[07:35] <LaserJock> *sigh* OK
[07:37] <LaserJock> this well this spagetti of packages is getting messy
[07:39] <lifeless> yes
[07:39] <LaserJock> I can't remove bzr-tools because of bzr-builddeb
[07:39] <lifeless> I'd love some more csript support for the folk doing ppa maintenance
[07:40] <LaserJock> although I suppose I can keep it but use the bzr branch of bzr-tools
[07:40] <LaserJock> but I only need bzr 1.6 because I updated bzr-svn
[07:46]  * Peng doesn't use the packages at all.
[08:07] <LaserJock> Peng: well, I'm a simple user and I'd rather spend time using the VCS than tracking down all the versions
[08:10] <luks> LaserJock: the thing is that it's easier to do `bzr branch lp:bzrtools ~/.bazaar/plugins` than to find the right package
[08:25] <LaserJock> luks: yeah, but then you update and things are screwed
[08:26] <luks> LaserJock: why do you think so?
[08:26] <LaserJock> because that's what I just did
[08:26] <luks> LaserJock: in me experience, things are screwed more if some debian packages refuse to update
[08:27] <luks> *my
[08:27] <LaserJock> I wondered if new stuff was in bzr-svn, and now I'm running after dependencies
[08:30] <Peng> New stuff is most definitely in bzr-svn.
[08:34] <LaserJock> well, I figured being on the 0.4 branch wouldn't be too bad
[08:35] <Peng> It's not bad.
[08:35] <Peng> But it has new C bits, so you have to run make.
[08:35] <LaserJock> except it require a beta bzr
[08:35] <Peng> Oh.
[08:35] <Peng> I run bzr.dev anyway, so I hadn't noticed.
[08:35] <LaserJock> which gives me problems with bzr-tools
[08:47] <LaserJock> hmm, I can't find what reversion the bzr-dep was bumped :/
[09:04] <LaserJock> ok, so I can't branch bzrtools because my current bzr won't work
[09:06] <LaserJock> hmm, so I think I need to start from scratch
[09:11] <Peng> LaserJock: Why won't it work?
[09:13] <LaserJock> Peng: gives me some traceback
[09:14] <Peng> LaserJock: Details?
[09:14] <LaserJock> Peng: so I went back and removed everything bzr
[09:14] <Peng> LaserJock: If it's from a plugin, you can run bzr without plugins temporarily.
[09:14] <LaserJock> reinstalled 1.5
[09:14] <LaserJock> now I'm trying to see if I can get a bzr-svn that works
[09:15] <LaserJock> bah! it want's python2.4
[09:16] <Peng> Bazaar has required Python 2.4 or greater for ages.
[09:16] <LaserJock> no, I mean I have 2.5
[09:16] <Peng> You mean bzr-svn specifically wants python2.4 rather than 'python -- yeah./
[09:17] <Peng> Um, I use bzr-svn's 0.4 branch, and I don't have python2.4.
[09:17] <LaserJock> yeah, I can't use that branch right now
[09:17] <Peng> Why not?
[09:17] <LaserJock> because it requires a newer bzr!
[09:17] <LaserJock> this is the cycle I've been going through
[09:18] <Peng> Oh.
[09:18] <LaserJock> somewhere the bzr dependency got bumped
[09:18] <Peng> There's no cycle for me, but I use the dev branches of everything.
[09:18] <Peng> And don't build packages or anything.
[09:18] <LaserJock> right, which is not great for me
[09:19] <LaserJock> I'm not trying to be necessarily at the tip of development, I just want a set that works
[09:20] <Peng> The tip of development works. :P
[09:20] <LaserJock> if I can find where in the 0.4 branch the bzr dep was bumped I can go back to that revision, but I can't find it
[09:20] <GaryvdM> Hi - I'm having a problem with ext-merge on windows. The file name has / separators and it should have \ .
[09:21] <LaserJock> Peng: I guess, but I'd end up updating a lot of branches to keep up
[09:21] <LaserJock> if I have to do bzr, bzrtools, bzr-svn, and the other plugins
[09:21] <GaryvdM> Is there a api method to get a windows path from a unix path or should is just replace / with \ if on windows?
[09:21] <LaserJock> and if they don't work with the current bzr.dev branch then they break
[09:22] <LaserJock> anyway, I've got to go to bed, I'll trying to think of something tomorrow
[09:23] <Peng> LaserJock: Yeah. I do keep up with them, and it's not too much effort. I update bzr.dev and bzr-svn whenever I'm bored (which is every 2 hours), and update the others whenever I think of it (every week or two?), and things usually work.
[09:23] <Peng> LaserJock: Anyway, good night. :)
[09:23] <Peng> GaryvdM: os.path?
[09:24]  * Peng stares at Freenode.
[09:24] <GaryvdM> This is where it gets the filenames:
[09:24] <GaryvdM> http://bazaar.launchpad.net/~zindar/bzr-extmerge/trunk/annotate/10?file_id=__init__.py-20060218133530-ac9ae4e505cbcfa9#L70
[09:25] <GaryvdM> I'm browsing bzrlib/osutils.py atm
[09:26] <GaryvdM> I think might be able to find something there.
[10:07] <GaryvdM> Is there a way to specify --fixes= after you have commited?
[10:54] <lifeless> Guest12932: you are thashing your name; please stop, its filling the page up with noice
[10:58] <Peng> lifeless: Do you have the ability to ban him?
[11:00] <lifeless> yes, though I think Lnidas is somewhat regular and that seems harsh
[11:02] <Peng> I agree, but temporarily banning people with misconfigured clients isn't an uncommon practice.
[11:03] <Peng> Heck, it's not like anything is going on here anyway.
[11:03] <lifeless> Leonidas: ping
[11:03] <lifeless> Peng: OTOH I'm about to hop on a plane; I won't be around to unban
[11:03] <Peng> lifeless: Oh.
[11:05] <lifeless> which is more of a problem  I feel
[11:07] <Peng> lifeless: Before you go, what's the status of bzr-search? Is it, like, done? Do you think it should be merged into the core?
[11:08] <lifeless> Peng: well, there are some bugs open indicating future work
[11:08] <lifeless> Peng: I consider it alpha status
[11:08] <Peng> That would've been great if he had auto-rejoin off.
[11:09]  * Peng blinks.
[11:09] <lifeless> ok, so its entertaining but useless
[11:10] <lifeless> bah
[11:10] <lifeless> I don't want to kick the username, because I won't be around
[11:10] <lifeless> sorry, but perhaps /ignore Guest* ?
[11:10] <oleavr> or *@chronon.pointtec.de
[11:10] <Toksyuryel> he's not changing his name to guest, nickserv is
[11:11] <Toksyuryel> because he's not entering the password for the nick
[11:11] <lifeless> oleavr: yeah, I want him/her to be able to join the channel; I will be offline very soon
[11:11] <lifeless> Toksyuryel: oh, interesting
[11:12] <Toksyuryel> given the number of attempts I'd wager that's not the real owner of that nick
[11:12] <lifeless> I'm pretty sure it is
[11:12] <oleavr> lifeless: ah I see
[11:12] <lifeless> oleavr: so if they could msg me and say 'fixed unban me' I would ban them, but as I have to go - bad idea
[11:14] <oleavr> lifeless: yep, understandable :)
[11:14] <lifeless> Toksyuryel: I reckon they are not in front of the pc/not notcing nickserv complaining
[11:14] <Toksyuryel> lifeless: then why does the nick keep changing back?
[11:14] <lifeless> Toksyuryel: client
[11:15] <lifeless> Toksyuryel: or they don't understand why its happening
[11:15] <Toksyuryel> lifeless: what client auto-changes one's nick back?
[11:15] <Toksyuryel> if they don't understand why it's happening it means they don't own the nick
[11:16] <lifeless> 20:15 [freenode] -!-  away     : Auto Away at Thu Jul  3 16:41:12 2008
[11:16] <Toksyuryel> a better script might be an auto-identify script :P
[11:17] <Peng> -Guest2534- VERSION ZNC by prozac - http://znc.sourceforge.net <-- Apparently that client.
[11:18] <Peng> Oh, it's a bouncer.
[11:19] <Toksyuryel> *!*leonidas@chronon.*
[11:20] <lifeless> clearly, after 10 days idle this is unlikely to go away in the next 5 hours :)
[11:20] <Toksyuryel> heh heh
[11:21] <lifeless> Peng: so search
[11:21] <lifeless> Peng: I think its alpha - it works but there are some important things to do to make it as slick and smooth as the rest of bzr
[11:22] <lifeless> Peng: getting indices shared between branches; stemming; date ranges; for starters
[11:24] <lifeless> and there is the boarding call; I must go
[11:24] <lifeless> back in 6 or so
[11:24] <Peng> lifeless: D'oh, I was jsut about to say something. Anyway, have a nice flight. :)
[11:24] <lifeless> Peng: oh, I think search is reliable now, just not complete; if that helps with clarity
[11:24] <lifeless> bye
[11:25] <Peng> lifeless: Thanks, it does.
[11:28] <GaryvdM> ping luks
[11:33] <Peng> GaryvdM: FWIW, my IRC client says his last message was 186 minutes ago.
[11:33] <GaryvdM> ok - thanks
[11:36] <luks> GaryvdM: pong
[11:37] <GaryvdM> I wanted to chat about qdiff
[11:37] <GaryvdM> I was thinking for background loading
[11:38] <GaryvdM> The different views each have a append_diff method
[11:39] <GaryvdM> The background loading calls thoughs methods when it has finished a diff.
[11:40] <luks> have you seen my changes to the code from yesterday?
[11:40] <GaryvdM> That will split populate_diff_documents.
[11:40] <GaryvdM> Yes
[11:40] <GaryvdM> Thats why I wanted to chat
[11:41] <GaryvdM> So far - I actually have not written any code. Just reading and planing.
[11:41] <luks> personally, the only thing I'd do is moving sequence matching from the initialization code to populate_diff_documents
[11:41] <luks> and make populate_diff_documents only work on one file at a time
[11:42] <luks> which would be repeatedly called by an idle timer, until all files are diffed
[11:43] <GaryvdM> ok
[11:46] <luks> GaryvdM: I mean, I don't mind any other solution if you think it's better, but this seemed the easiest to me
[11:46] <luks> you are going to write the code, after all, you decide :)
[11:47] <GaryvdM> DiffSourceView.setChanges and DiffViewHandle.setChanges  need the be changed to extendChanges
[11:47] <luks> yep
[11:47] <GaryvdM> Yes - but you know then code better than I so you might be able to give me advice...
[11:48] <GaryvdM>  Ok - time to dive in....
[12:14] <strk> $ bzr update
[12:14] <strk> You tried to execute: bzr serve --inet --directory=/ --allow-writes
[12:14] <strk> Sorry, you are not allowed to execute that command.
[12:14] <strk> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[12:14] <strk> gnash project, repository on savannah
[12:14] <bob2> lp?
[12:14] <bob2> does 'unset BZR_REMOTE_PATH ; bzr up' work?
[12:15] <strk> no such env
[12:15] <luks> misconfigured server on savannah?
[12:15] <strk> same error with the unset anyway
[13:06] <spiv> strk: sounds like a misconfigured server
[13:12] <strk> they must have changed something within the last 12 hours then
[13:52] <vimes656> hi there
[13:52] <vimes656> I'm using bzr bzr1.5 installed from fink in mac os x
[13:52] <vimes656> I'm always getting a locale error
[13:53] <vimes656> bzr: warning: unknown encoding . Continuing with ascii encoding.
[14:10] <mathrick> hiya
[14:10] <mathrick> I hit a bug in bzr cat
[14:10] <mathrick> http://pastebin.com/f78cd4840
[14:10] <mathrick> I don't know what to make of it
[14:25] <spiv> mathrick: That's https://bugs.launchpad.net/bzr/+bug/175570, I think.
[14:26] <mathrick> spiv: ah, bummer
[15:55] <colbrac> I just posted a patch on the bzr-gtk mailinglist with some dialog cleanup.. any comments?
[15:56] <ToyKeeper> Yeah, but I'm replying on-list.
[16:21] <Leonidas> lifeless: you can unban me already, I've got it working again
[16:21] <Leonidas> my bouncer started to play ping-pong with the services
[16:22] <Leonidas> (sorry for these problems, I'll take a look at the configuration of the bouncer)
[16:24] <Peng> Did the bouncer finally give up or what?
[16:46] <clemente> Hi; I plan to turn my web site into a branch repository to hold different simultaneous developments. But is there an easy way to check out a whole repository with all branches?
[16:56] <liw> clemente, I don't know of such a way; I've occasionally wanted a "bzr branches http://foo/repository" kind of command, which would let one script things
[16:56] <liw> (there might be one, I have not really looked for one throughly)
[16:59] <colbrac> About the olive.glade file: The window_merge is used in MergeDialog in olive. But, unlike the other window_* dialogs, MergeDialog is not in the olive subfolder but in the main folder in merge.py. Is it thus used outside of olive?
[17:01] <clemente> liw: that would be good; otherwise you need to know the exact name of each branch; is it like that?
[17:01] <liw> clemente, as far as I know, you need to know the exact name of each branch to check them all out
[17:17] <mathrick> I'm enhancing Bugs Everywhere to support operations on arbitrary branch URLs, not just working trees in the current directory, and I'm not sure how best to go about re-structuring the bzr backend of it
[17:18] <mathrick> namely, the current implementation happily invokes bzr as a subprocess (ie. plain old popen()), and assumes there is a working tree available. So it can do things like add several files, then commit them all in a batch
[17:18] <Peng> bzrtools adds a "bzr branches" command that recursively finds all branches in the current directory.
[17:18] <mathrick> what is the best way to implement that from python using bzrlib?
[17:18] <mathrick> that is, I want to be able to accept several ops, construct a revision from them, and then push it to a branch
[17:19] <mathrick> having temp files is A-OK, but requiring working trees is not
[17:22] <clemente> Peng: but not on a remote server, I think
[17:23] <clemente> (trying)
[17:25] <clemente> Mmmm :-(
[17:25] <clemente> bzr: ERROR: Could not understand response from smart server: ('UnicodeDecodeError', 'ascii', 's:w7p0aWxlcw==')
[17:59]  * mathrick still looks for someone to help him with navigating bzr's innards
[18:00] <mathrick> to rephrase my question, is it possible to build up a commit without having a (physical) working tree?
[18:25] <clemente> mathrick: I have no idea... Maybe you can construct a pack directly? Or maybe using bzr fast-import... fast-import accepts just a stream of data and does not require files
[18:25] <mathrick> oh, that's certainly a hint, thanks
[18:26] <clemente> It is the same data format that „git fast-export“ creates
[18:28] <lifeless> mathrick: yes
[18:28] <lifeless> mathrick: there are tests that do this using InMemoryWorkingTree
[18:28] <lifeless> or MemoryTree or whatever I called it
[18:28] <mathrick> oh!
[18:29] <mathrick> cool, so reading those tests should tell me everything I need to know?
[18:29] <lifeless> its only as sophisticated as I needed it to be at the time; but further improvements would be welcomed:)
[18:29] <lifeless> mathrick: yah
[18:30] <mathrick> I don't expect my needs to be terribly sophisticated, I follow a rigid protocol and mostly communicate with myself
[18:30] <mathrick> well, somewhat rigid
[18:33] <lifeless> mathrick: well, give it a shot; let me know how it goes
[18:34] <mathrick> yup, doing that now
[18:34] <lifeless> Leonidas: unbanned, thanks
[18:38] <Leonidas> lifeless: thank you. I changed the settings and will change the bouncer to prevent this from happending in the future
[18:38] <lifeless> Leonidas: no probs
[18:50]  * Odd_Bloke returns.
[18:55] <liw> http://www.yosefk.com/blog/dvcs-and-its-most-vexing-merge.html -- that has probably been discussed to death, yes?
[18:56] <mathrick> does put_file_bytes_non_atomic replace the previous contents?
[18:56] <mathrick> liw: the answer is "depends on your merge algorithm"
[18:57] <mathrick> in particular, diff3 fails this test miserably
[19:23] <colbrac> funfact: bzr-gtk trunk is 1000 days old today
[19:23] <colbrac> at least.. according to my olive information dialog :)
[19:28] <lifeless> mathrick: yes it replaces
[19:29] <lifeless> colbrac: cool
[19:33] <clemente> In a repository, I did (knowingly...) „rm -rf branch/“. But since the contents were stored in repo/.bzr and not in the branch, repo/.bzr has still a lot of things I don't want. How can I really remove the remainings of the branch?
[19:34] <lifeless> clemente: you mean a gc?
[19:34] <clemente> yes
[19:34] <lifeless> I should really write that :). Anyhow, the manual way is to make a new repo; branch the branches you want to keep into it and then replace the old repo's .bzr/repository with the new one's.
[19:34] <clemente> but there's no „gc“ command
[19:35] <lifeless> thats what bzr gc will do when I get around to writing it
[19:35] <lifeless> (well, it will optimise away some of the copying, but it will be conceptually the same)
[19:37] <clemente> Thanks, I'll try it. By the way, I had to remove the branch by force because I had interrupted a „branch“ with C-c and then no command I tried could delete it
[19:37] <ToyKeeper> That reminds me... is there a way to see which abandoned branches are in the repo, and maybe get them back?
[19:37] <lifeless> clemente: did you try zr break-lock ?
[19:37] <lifeless> ToyKeeper: bzr hads
[19:37] <lifeless> *heads*
[19:38] <colbrac> bzr heads only shows 2 for me
[19:38] <colbrac> and I have a few more
[19:38] <ToyKeeper> Hmm, must be in some plugin I don't have right now.  I think I've seen it somewhere, though.
[19:39] <colbrac> bzr help heads to the rescue
[19:39] <colbrac> bzr heads --all
[19:39] <colbrac> or even better
[19:39] <colbrac> bzr heads --dead-only
[19:39] <clemente> lifeless: No... In fact I don't know how to remove the branch. Is it remove-tree?
[19:40] <clemente> lifeless: By the way, I thought that command „reconcile“ would be similar to what you said about „gc“. Maybe they share features
[19:51] <lifeless> clemente: to remove a branch its normally just rm -rrf branch
[19:51] <lifeless> erm, -rf I mean :)
[19:51] <lifeless> ToyKeeper: its in bzrtools
[19:51] <lifeless> clemente: remove-tree removes the working tree, so you just have the branch on its own.
[19:54] <clemente> But it's still needed a command to remove a branch which exists in a repository
[19:54] <clemente> Althought rm -rf  + bzr gc   would work, too...
[19:54] <ToyKeeper> Ah, I just hadn't set up a version compatible with bzr.dev yet.
[19:59] <lifeless> clemente: well, yes. generally though a branch is a tiny fraction of a repo
[19:59] <lifeless> clemente: so there has been little user pressure to make this part of the system streamlined (though it will happen) :). In particular, rming the directory leaves the head behind which is beneficial
[19:59] <lifeless> (if you want to recover later :))
[20:03] <Peng> Hmm, I occasionally mess up with bzr-svn and pollute a repo. A gc command would be nice there.
[20:05] <lifeless> Peng: well a first implementation for packs would be refs = last-revision + tags for b in repo.find_branches(); create-pack_from_packs(revs = refs); remove packs matching refs;
[20:06] <Peng> Would it wind up packing everything into one pack?
[20:12] <lifeless> nah, only the ones it has to read to grab shit from
[20:13] <lifeless> theres a little more glue etc in there, that was clearly just a sketch :)
[20:39] <apol> how can I update to a revision from a workingtree?
[20:42] <lifeless> apol: udpate will take you to tip, revert can take you back
[20:42] <apol> mmm
[20:42] <apol> fine
[20:42] <apol> but... update only updates
[20:42] <lifeless> yes, need to add -r to it
[20:42] <apol> lifeless: i need to update it to a certain revision (say as svn up -r213)
[20:43] <lifeless> apol: revert -r 213
[20:43] <lifeless> apol: if you have local edits, shelve them first
[20:44] <apol> lifeless: and with the python interface? is it the old_tree parameter?
[20:45] <lifeless> apol: not sure offhand, builtins.cmd_revert and follow your nose probably
[20:45] <apol> lifeless: cool
[20:47] <apol> thx
[20:47] <lifeless> np
[21:45] <Peng> Huh, Loggerhead's RAM usage has dropped slightly twice today.
[22:52]  * Foskasse http://graphjam.files.wordpress.com/2008/06/gj32.gif LOL!
[22:57] <mathrick> ok, so I can hit https://bugs.launchpad.net/bzr/+bug/175570 with memorytree as well against bzr://
[22:57] <mathrick> it seems that branch.lock_read() does NOT lock the repo
[22:57] <mathrick> even though branch.is_locked() returns true
[22:58] <mathrick> could anyone assist me with debugging that?
[22:59] <mwhudson> mathrick: do you have a testcase ?
[22:59] <mathrick> mwhudson: I will in a second, but I wanted to poke around more in PDB
[23:03] <mwhudson> hm, the traceback in the bug report is out of date
[23:04] <mwhudson> mathrick: it seems to work for me now
[23:05] <mathrick> it doesn't for me
[23:05] <mathrick> I'm running 1.5 btw
[23:05] <mwhudson> mathrick: i'm running 1.6b2 i think
[23:05] <mathrick> mostly because 1.6 breaks loggerhead and it hasn't been updated last I checked
[23:05] <mwhudson> mathrick: this seems like this sort of thing that might have been fixed by accident in the versionedfiles refactoring
[23:05] <mwhudson> mathrick: i'm pretty sure loggerhead works with 1.6...
[23:06] <mathrick> it didn't when I tried
[23:06] <mwhudson> try again :)
[23:06] <mathrick> if it does, then I see no reason to stick with 1.6 :)
[23:06] <mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181 looks relevant
[23:12] <mathrick> yep, thanks
[23:14] <mathrick> isn't there a PPA for bzrtools?
[23:29] <mathrick> mwhudson: still happens for me on 1.6b2
[23:29] <mwhudson> mathrick: hmm
[23:29] <mathrick> oh, maybe it's because the server is still running 1.5
[23:29] <mwhudson> ah
[23:30] <mathrick> nope
[23:30] <mathrick> reran it as 1.6b2, still happens
[23:34] <mathrick> mwhudson: https://bugs.launchpad.net/bzr/+bug/175570
[23:35] <mwhudson> mathrick: can you pastebin the traceback?
[23:35] <mathrick> mwhudson: I did
[23:35] <mwhudson> if i run bzr serve in one window
[23:35] <mathrick> as a python comment
[23:35] <mwhudson> oh ok
[23:35] <mwhudson> i can run "bzr cat bzr://localhost:4155/README" in another
[23:36] <mathrick> mwhudson: hmm, can you try subdir/README?
[23:36] <mathrick> nah, that happens here for files in the main dir as well
[23:37] <mathrick> mwhudson: what is the format of the repo?
[23:37] <mwhudson> very odd
[23:37] <mathrick> mine is pack-0.92
[23:38] <mwhudson> same
[23:38] <mwhudson> hm, if i run your python code it fails in a different way
[23:38] <mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181
[23:38] <mwhudson> no
[23:38] <mwhudson> NotImplementedError: <bound method MemoryTree._populate_from_branch of <bzrlib.memorytree.MemoryTree object at 0x7f284c38f8d0>>
[23:39] <mathrick> oh
[23:40] <mathrick> mwhudson: definitely something is not in sync at your place
[23:40] <mathrick> it's implemented and supposed to work
[23:41] <mwhudson> oh
[23:41] <mwhudson> that's because i have symlinks in the tree i'm testing with, it seems
[23:43] <mwhudson> ok, now it fails the same way as for you
[23:45] <mwhudson> mathrick: http://pastebin.ubuntu.com/27148/ seems to summarize the problem
[23:46]  * mwhudson pulls in latest bzr.dev
[23:54] <cyberix> I'm working on a bzr branch and it uses the bzrlib from my Ubuntu installation instead the one from that branch ( without my permission ;-)
[23:54] <cyberix> How do I force it to use the one that comes with it
[23:54] <cyberix> s/bzr branch/bzr bzr branch/
[23:55] <Verterok> cyberix: /path/to/branch/bzr selftest ;)
[23:55] <Verterok> cyberix: s/selftest/<any_command>/
[23:58] <cyberix> That is what I'm doing
[23:59] <Verterok> hm, cyberix: try with: PYTHONPATH=/path/to/branch:$PYTHONPATH /path/to/branch/bzr