[00:07] <lifeless> beuno: ping - bzr session now
[00:07] <lifeless> beuno: in 'bragi'
[00:15] <rocky> hey, what versions of python does bzr 1.10 "officially" support?
[00:16] <beuno> rocky, 2.4 and 2.5
[00:16] <rocky> is 1.11 aiming for 2.6 support? (officially)
[00:18] <beuno> rocky, I don't think we'll be officially supporting 2.6 very soon. Supporting 3 versions of python sounds a bit hell-ish
[00:19] <rocky> it does, but i would hope for a shift to 2.5/2.6 up from 2.4/2.5
[00:22] <lifeless> 2.6 should be fine with 1.10
[00:22] <lifeless> rocky: 2.4 going is more a factor of distro release schedules and company migration needs than anything else
[00:32] <rocky> lifeless: i asked about "official" because when i tried 1.9 on py2.6 (which "should" work) i found several plugins i used  didn't work with 2.6
[00:33] <rocky> anyways, bzr rocks, keep up the good work ;)
[00:33] <jelmer> well, plugins are different from bzr core of course :-)
[00:35] <jelmer> apparently bzr-svn requires >= python 2.5 these days :-/
[00:36] <rocky> part of why i'm asking is because i'm considering integrating bzr into my cluemapper suite (trac integration) and i require >= py2.5 and would like to update it to 2.6 at some point
[00:36] <jelmer> I don't think anybody is opposed to 2.6 support, but it may be useful to file bugs if you find things don't work with 2.6 yet
[00:44] <lifeless> rocky: plugins - file bugs on them
[00:45] <rocky> right
[00:45] <lifeless> rocky: I mean, I don't *have* python2.6 available on my machine, I can't really fix bugs:)
[00:45] <rocky> everyone can have py2.6 available on their machine :)
[00:45] <rocky> unless you're running msdos or something ;)
[00:46] <lifeless> $ apt-cache search python2.6
[00:47] <rocky> wget Python-2.6.1.tar.bz2 && tar jxf Python-2.6.1.tar.bz2 && cd Python-2.6.1 && ./configure --prefix=$HOME/python2.6 && make && make install
[00:47] <Peng_> Oogh.
[00:47] <rocky> at least that's what i just did on my 3 ubuntu desktops :)
[00:48] <lifeless> rocky: yeah, 'no'.
[00:48] <lifeless> :)
[00:49] <rocky> lifeless: i guess my line was a tad bit longer than yours ;)
[00:56] <lifeless> rocky: :)
[00:59] <Lutin42> Hi! I have a bzr repository. Today, I copied the whole folder onto a USB key and from an other computer, changed some files in it. I did not do any bzr operations. Tonight, I copied the folder back to the first computer in a different folder. Now, bzr status tells me that all the file  have been modified (which is not true).
[00:59] <Lutin42> Any reason this happens?
[00:59] <Lutin42> Any way to fix it?
[01:00] <Rolly> have you tried bzr revert?
[01:00] <beuno> Lutin42, well, the files probably changed properties like owner and such
[01:00] <beuno> bzr revert will throw away all those changes
[01:00] <beuno> so make sure that you don't have anything you don't want to loose
[01:00] <Lutin42> hmmm... I can do this. But I'd like to figure out what happened
[01:01] <Lutin42> I will look at the property
[01:01] <Lutin42> Is time relevant?
[01:03] <jfroy|work> jelmer: are you aware of a problem with bzr 1.10 and bzr-svn 0.4.16 in create_auth_baton?
[01:04] <jelmer> jfroy|work, no
[01:04] <jfroy|work> I'm getting a TypeError exception from that method (auth.py:181)
[01:04] <jfroy|work> "Auth providers should be list"
[01:05] <jfroy|work> Any ideas?
[01:07] <jelmer> jfroy|work, no, sorry. Is providers actually a list?
[01:07] <jfroy|work> totally should be
[01:09] <Lutin42> ok; the permissions have been messed up
[01:10] <lifeless> Lutin42: time isn't relevant
[01:10] <lifeless> Lutin42: I would guess the execute bit was changed or something
[01:10] <lifeless> Lutin42: what does 'bzr diff' show?
[01:10] <lifeless> Lutin42: and can you pastebin the output of status, for justa few files, so we can see it
[01:11] <Lutin42> I fixed the permission of one of the file and it does not show any more in the status
[01:11] <Lutin42> so all is good :)
[01:13] <jfroy|work> jelmer: nm must have been a bad build
[01:13] <jfroy|work> actually that's exactly what happened
[01:13] <jfroy|work> your Makefile is not robust enough
[01:14] <jelmer> patches welcome :-)
[01:14] <jelmer> the Makefile is just a convenience wrapper around setup.py though, not intended as the primary build mechanism
[01:14] <jfroy|work> correct
[01:15] <jfroy|work> the problem is that it uses which to find Python and bzr
[01:15] <jfroy|work> But on the system I was using, the default python is not the same as the python used by bzr.
[01:15] <jfroy|work> All kinds of bad things ensued.
[01:15] <jfroy|work> Ideally it should parse the path returned by bzr --version
[01:16] <jfroy|work> (which is what my patch will do)
[02:37] <Peng_> beuno: fwiw, I'm not sure the Loggerhead changes improve memory usage for me much.
[02:38] <Peng_> beuno: It *might* be a bit better. It's at 120 MB right now, but it usually jumps to 150 instead.
[02:40] <beuno> Peng_, 120 vs 150?
[02:40] <beuno> the major win should be in total usage
[02:40] <beuno> it shouldn't keep on scaling
[02:41] <Peng_> What do you mean?
[02:42] <beuno> it leaks memory for us
[02:42] <beuno> until it crashes
[02:42] <beuno> on large trees
[02:42] <beuno> brb
[02:42] <Peng_> eep
[11:58] <arekm> hello, does bzr have commands that works like git log -p (producing both, changelogs and diffs at the same time - ex http://pld.pastebin.com/f1c76c250) ?
[13:21] <Peng_> beuno: Since the latest Loggerhead trunk stuff, mem usage has actually gotten worse for me. But the workload is a bit different than usual, so it might be expected.
[13:22]  * Peng_ goes back to being away
[13:25] <pygi> mr
[14:03] <Peng_> s/expected/because of that/
[14:03]  * Peng_ goes back to being away again. :P
[14:59] <arekm> hmm, looks like there is no such feature in bzr :-( most commonly used command by me for git repos
[15:02] <arekm> on the other hand http://wiki.frugalware.org/Git_setup says "not possible without plugins"  so maybe there is a plugin for that already
[15:07] <arekm> so is there a plugin that does this? https://lists.ubuntu.com/archives/bazaar/2008q1/038202.html
[15:50] <arekm> matkor: https://bugs.launchpad.net/bzr/+bug/202331 and https://bugs.launchpad.net/bugs/227335
[15:51] <matkor> arekm: he he, you are not the only one [to cite GnR ;) ]
[15:53] <beuno> Peng_, that's not very good news  :(
[15:53] <beuno> what version of bzr are you running?
[16:11] <Peng_> beuno: bzr.dev.
[16:11] <Peng_> Hmm, Loggerhead just recently started loading plugins. I wonder if that could be involved?
[16:12] <Peng_> I have no idea /how/, but..
[16:22] <beuno> Peng_, ah, right. That patch probably shouldn't of gotten in
[16:22] <beuno> it does load plugins
[16:22] <beuno> actually, I'm not sure if that's such a bad thing...
[17:54] <bpierre> hi
[18:36] <Flimm> What's the difference between bzr get and bzr branch?
[18:37] <bpierre> Flimm: get is just an alias for branch
[18:38] <Flimm> OK, thanks
[18:59] <derekS> hello. i messed up my branch and committed a huge file. i want to remove any history of this commit
[18:59] <derekS> because now my .bzr is way too big
[18:59] <derekS> how do i do this?
[19:02] <bpierre> you could uncommit
[19:02] <bpierre> and then clone the branch
[19:02] <bpierre> the new one will not contain the uncommited revision
[19:02] <bpierre> it's more complicated if you're using a shared repo
[19:03] <derekS> good plan
[19:03] <derekS> nope not
[19:04] <Peng_> Even if you are using a shared repo, it's not that complicated.
[19:05] <bpierre> how would you do it? reconfigure --standalone on each branch using it, recreate the shared repo, and reconfigure --shared?
[19:06] <bpierre> or is there a command to completly wipe out the revision?
[19:06] <Peng_> bpierre: Create a new repo and a branch inside it, "bzr heads" in the original repo, pull each one into the new repo, then swap the repos out.
[19:06] <Peng_> ("bzr heads" comes from bzrtools.)
[19:07] <derekS> Peng_: you hang out here too :)
[19:07] <bpierre> ok
[19:07] <Peng_> derekS: Hi. :)
[19:09] <derekS> i am considering putting my bzr repo in something like Dropbox. its only me who uses it, any comments for or against it?
[19:09] <derekS> i am thinking it might be easier then pushing/pulling on 2 computers
[19:09] <pygi> jelmer, lifeless: you rock ;)
[19:10] <Peng_> derekS: Pushing/pulling/merging is not that hard.
[19:10] <bpierre> mmm
[19:10] <bpierre> Peng_: I just tried heads on one of my repo, and I'm not seeing the head of each branch using it
[19:10] <derekS> Peng_: i know ;)
[19:16] <lifeless> pygi: thanks? :)
[19:17] <pygi> lifeless, why the question mark? :p
[19:18] <derekS> hmm, i uncommitted, and did a clone, the new folder is bigger than the old :)
[19:19] <bpierre> :P
[19:19] <bpierre> I tested it and it worked for me
[19:19] <pygi> lifeless, you can probably expect our TOC next week, so you can do a quick check so we could create final revision of it :)
[19:20] <bpierre> derekS: same repository formats?
[19:24] <derekS> bpierre: yeah, just realize i might have had to do 2 uncommits
[19:34] <lifeless> pygi: wasn't sure what you where thanking me for :)
[19:34] <pygi> lifeless, ah, now you know then :p
[20:33] <lifeless> jml: ping me when you are up please
[20:35] <beuno> Peng_, so, memory usage is still up for you?
[20:42] <derekS> so when you push a directory, it just copies the .bzr?
[20:44] <luks> if you push to a remote server, yes
[20:45] <derekS> so what kind of compression is used? my .bzr folder is significantly smaller than the contents of the repo
[20:46] <luks> it stores only the changes (not the full history), and the data are then gzipped
[20:46] <luks> oh wait
[20:46] <luks> by 'repo' you mean actual bzr repository, or your working tree
[20:47] <derekS> bzr repo
[20:47] <derekS> because the working tree has actual data
[20:47] <derekS> the remote push doesn't
[20:47] <luks> well, it might be using a shared repository
[20:48] <luks> what's inside the .bzr folder on the server?
[20:48] <derekS> just the .bzr
[20:48] <luks> I mean inside it
[20:49] <derekS> README  branch  branch-format  branch-lock  repository
[20:49] <luks> ah, then it contains the repository as well
[20:50] <derekS> means all the data gzipped?
[20:50] <luks> delta-compressed and gzipped
[20:50] <derekS> thanks :)
[23:04] <CyberSnooP> Hi. I'm having trouble with the SVN plugin on bzr-1.9 on windows. I've ran the setup, but things like  "bzr version" now say:
[23:04] <CyberSnooP> Unable to load bzr-svn extensions - did you build it?
[23:04] <CyberSnooP> cannot import name client
[23:04] <CyberSnooP> Does anyone know how to fix this?
[23:04] <jelmer> CyberSnooP, how did you run the setup?
[23:05] <CyberSnooP> Downloaded bzr-setup-1.9.exe and kept the defaults
[23:05] <jelmer> that should include bzr-svn I think
[23:05] <CyberSnooP> Well, the plugin is there and bzr tries to load it indeed
[23:06] <CyberSnooP> but somehow it fails to load with the above error
[23:06] <CyberSnooP> The only clue seems to be: "cannot import name client". So probably I'm missing a dependancy, but I couldn't find which one, or how to fix it
[23:11] <jelmer> CyberSnooP, that file is part of bzr-svn
[23:11] <jelmer> CyberSnooP, it is built when you run setup.py
[23:11] <jelmer> CyberSnooP, how did you install bzr-svn?
[23:12] <jelmer> CyberSnooP, also, I think there was an updated version of the bzr 1.9 setup that fixed some issues, it may fix stuff in bzr-svn as well
[23:12] <CyberSnooP> I didn't install bzr-svn manually, but I've only used the bzr-setup-1.9 which should have bzr-svn bundled
[23:13] <jelmer> CyberSnooP, in that case, it sounds to me like a broken setup
[23:47] <Jc2k> jelmer: any chance of that pack code :)? sorry to bug but im blocked on it atm.