[00:35] <izm99> I have a branch stored on my webserver, and I did a checkout on it.  but I can't commit.  I get bzr: ERROR: Cannot commit to branch BzrBranch6('file://local-path'). It is bound to BzrBranch6(sftp.....') which is bound to sftp:same-path.
[00:36] <izm99> so BzrBranch6(sftp-path) is bound to sftp-path sounds circular... but I have no idea....
[00:37] <LarstiQ> izm99: that sounds as if the branch on your server is a checkout.
[00:37] <izm99> LarstiQ: so how can I commit to it?
[00:37] <LarstiQ> izm99: what does `bzr info` return for sftp:remote-path?
[00:38] <izm99> checkout root: .
[00:38] <izm99> oh sorry.. of remote path.. one sec
[00:39] <izm99> branch root: http://stevenbrown.ca/src/AttrDict/
[00:39] <izm99> bound to branch: sftp://blah@blah/src/AttrDict/
[00:40] <izm99> related branches: push branch: sftp://blah@blah/src/AttrDict/
[00:40] <LarstiQ> and the bound branch is the same as that branch itself?
[00:40] <LarstiQ> 'bound to branch'
[00:40] <izm99> i kinda fudged when I put it up there....  ¬_¬
[00:41] <LarstiQ> izm99: if so, that's rather silly. Issue a `bzr unbind` on the remote branch.
[00:41] <LarstiQ> izm99: after that, you should be able to commit in the local one.
[00:41] <izm99> oooh.. ok, i'll try
[00:42] <izm99> wait, do i have to ssh into the remote host to do that?
[00:42] <LarstiQ> izm99: yeah, fraid so.
[00:42] <izm99> dang
[00:42] <izm99> bzr isn't actually installed on that.
[00:43] <LarstiQ> if you're not afraid to touch .bzr we can do it without bzr installed.
[00:43] <izm99> i'm in
[00:44] <izm99> :D
[00:44] <izm99> (i have a local copy anyways, this is a learning exercise)
[00:44] <LarstiQ> ok
[00:45] <LarstiQ> izm99: see .bzr/branch/branch.conf
[00:46] <LarstiQ> izm99: it should have a bound_location and a boolean 'bound' option.
[00:46] <LarstiQ> izm99: toggle the latter to false, and you should be good to go.
[00:49] <izm99> hmm....  it let me commit
[00:50] <LarstiQ> izm99: so your problem is fixed now?
[00:50] <izm99> not really... it didn't actually change the files
[00:52]  * LarstiQ needs a bit more context
[00:52] <LarstiQ> where did you commit, and where didn't files change?
[00:52] <izm99> yeah, sorry, I'm trying to poke around...
[00:52] <izm99> Committing to: sftp://stiibu@stevenbrown.ca/home/stiibu/stevenbrown.ca/src/AttrDict/
[00:52] <izm99> added COPYING
[00:52] <izm99> modified attrdict.py
[00:52] <izm99> modified test_attrdict.py
[00:52] <izm99> Committed revision 2.
[00:52] <izm99> (woops username.. oh well)
[00:53] <LarstiQ> that looks like it worked to me.
[00:53] <izm99> ya..
[00:53] <LarstiQ> izm99: I'm guessing you're expecting the checkout on stevenbrown.ca to also have updated?
[00:53] <izm99>  bzr status http://stevenbrown.ca/src/AttrDict -> bzr: ERROR: Path(s) do not exist: http:/stevenbrown.ca/src/AttrDict
[00:53] <izm99> yes i am
[00:53] <LarstiQ> that doesn't actually happen.
[00:53] <izm99> oh.
[00:53] <izm99> i have to push?
[00:54] <LarstiQ> izm99: no no, the .bzr file got updated fine.
[00:54] <izm99> (unless I'm bound)?
[00:54] <LarstiQ> izm99: so the question is, what are you trying to accomplish?
[00:54] <izm99> i wanted to update the remote branch with my commit
[00:54] <LarstiQ> izm99: if you just want to publish your branch, you don't have to do anything extra, since all bzr cares about is .bzr, and that's updated.
[00:55] <LarstiQ> izm99: is your use case something like website deployment?
[00:55] <LarstiQ> izm99: or do you want to be able browse the content of the branch?
[00:55] <izm99> yeah, i want the source to browsable, as well
[00:55] <LarstiQ> izm99: ok, for the latter I'd probably recommend running loggerhead to do that.
[00:56]  * izm99 googles
[00:56] <LarstiQ> izm99: That's an actual webfrontend akin to things like viewcvs if you are familiar with that.
[00:56] <izm99> yes, I'm familiar
[00:57] <izm99> so the changes have been committed, but the actual files are not updated?  The changes are stored in the .bzr somewhere?
[00:59] <LarstiQ> izm99: The changes have been commited, yes. The files outside of .bzr are not touched, I wouldn't call them 'actual files' though :)
[00:59] <LarstiQ> izm99: so, if you wanted to updated the files there, you could do 'bzr update'
[00:59] <izm99> ooooh....
[01:00] <LarstiQ> izm99: there is a plugin to ssh into the remote machine and run update after a push if you want something like that.
[01:00] <izm99> so I should pretty much at least install bzr on the remote machine...
[01:00] <izm99> I was trying to avoid any server stuff...
[01:01] <LarstiQ> izm99: if you want to do code browsing there, yes.
[01:01] <LarstiQ> izm99: the alternative is having to transfer all the files in the working tree every time, that's rather expensive though.
[01:02] <LarstiQ> izm99: at this point I would step back and consider if browsing on the server is really what I want to do then.
[01:03] <izm99> hah.. ok, I believe you.. i just tried another checkout. :P
[01:03]  * izm99 checks local bzr version
[01:04] <izm99> so, there's likely incompatibilities between bzr versions, right?
[01:04] <izm99> my local is : bzr 1.3.1, python 2.5.2;;  remote is : python 2.3
[01:04] <LarstiQ> izm99: depending on versions, yes. But you're not combining 0.11 with 1.5 are you?
[01:04] <LarstiQ> izm99: ah see, we kinda depend on python2.4 or higher.
[01:05] <izm99> i'm just curious ... ya, that was my next question.
[01:05] <izm99> i figured the python would be too old.
[01:05] <izm99> >.<
[01:06] <izm99> is it a bzr option to transfer the working tree?
[01:06] <poolie> izm99: check out bzr-upload plugin
[01:06] <LarstiQ> izm99: yes
[01:12] <izm99> hmm.. ok, should i take the debian or trunk branch of bzr-upload?
[01:14] <LarstiQ> izm99: the debian branch is specifically for Debian packaging, it doesn't bring you other benefits.
[01:14] <izm99> oh ok.
[01:15] <LarstiQ> izm99: it might mean that you can just apt-get install bzr-upload depending on what suite of Debian you are running. But bzr 1.3.1 looks older than what is in sid.
[01:15] <LarstiQ> and I doubt it's in anything else at this point.
[01:15] <izm99> i'm using hardy
[01:15] <izm99> just searched, not there
[01:16] <izm99> i'll follow the directions to branch into .bazaar/plugins/ directory.
[01:16] <LarstiQ> right
[01:24] <izm99> i'm guessing a lot of plugins have a hypen in the name...  it'd be nice if bzr had some install_plugin command that renamed the plugin branch appropriately when grabbing it.
[01:25] <LarstiQ> yes
[01:25] <izm99> whoo! it worked.  Thanks for all the help!
[01:26] <LarstiQ> izm99: so, _now_ everything you want to do works? :)
[01:27] <izm99> yes!  LarstiQ: Thank you very much.  :D
[01:27] <LarstiQ> good, good.
[01:27]  * LarstiQ continues poking at python-nautilus.
[01:27] <izm99> ^.^
[01:28] <LarstiQ> for some reason the nautilus-bzr stuff doesn't work when I think it should.
[01:29] <LarstiQ> But phatch has a nautilus extension that does work, so it _is_ possible.
[01:29] <pygi> it's so amazingly funny
[01:29] <pygi> you know Novell folks also work/will work on nautilus-bzr, right? xD
[01:29] <pygi> what happened with the collaboration I though exists in FOSS world? :-/
[01:30] <pygi> oh well
[01:30] <LarstiQ> pygi: huh what?
[01:31] <LarstiQ> how should I know this?
[01:31] <pygi> at least I think that's correct, If I understood right
[01:31] <pygi> I'll have to investigate
[01:31] <pygi> LarstiQ, no idea, I'm just talking in general xD
[01:32] <LarstiQ> pygi: the problem was that nautilus doesn't pick the script up from ~/.nautilus/python/, but it does look at /usr/lib/nautilus/extensions-1.0/python/
[01:32]  * LarstiQ insers an extensions-1.0 in his home dir variant
[01:33] <LarstiQ> pygi: I'd like to know more about that. Have you been at GUADEC this year?
[01:33] <pygi> LarstiQ, I haven't, no ...
[01:34] <pygi> LarstiQ, I'll investigate that more for you in the coming days, to see if I got it right
[01:34] <pygi> but I think I have, and there'll also be nautilus-hg, nautilus-git and similar
[01:34] <LarstiQ> strace ftw, .nautilus/python-extensions
[01:35] <LarstiQ> pygi: riight.
[01:35]  * pygi has to make them collaborate with you then =)
[01:35] <LarstiQ> pygi: I admit to not having followed bzr lately.
[01:36] <pygi> but I'm sleeping now, it's 2:35AM, and I gotta get up in 3 hours and 25 minutes :P
[01:36] <LarstiQ> pygi: so Mark Hammond and I discussed TortoiseBazaar today, and our idea was to use the same code at one side of the pipe, and/but write a small nautilus thingy that does the equivalent of windows shell.
[01:36] <pygi> enjoy folks :)
[01:36] <LarstiQ> pygi: have fun
[01:36] <pygi> LarstiQ, we'll talk about that tomorrow, ok?
[01:36] <LarstiQ> pygi: yes/no
[01:36] <LarstiQ> pygi: please do talk to me
[01:37] <LarstiQ> pygi: but I'll be away untill Sunday/Monday
[01:37] <pygi> LarstiQ, ah, ok, then Monday it is :)
[01:37] <LarstiQ> pygi: you can paste links at me and I'll read my backlog when I get back.
[01:37] <pygi> sure, that works too perhaps :)
[01:37]  * pygi is officially in sleep-mode
[01:39] <LarstiQ> sigh, I'm reminded of why I didn't use nautilus in the first place.
[01:39] <izm99> LarstiQ: why not?
[01:40] <LarstiQ> izm99: I recall there being some option to turn it off, but the main thing that is annoying me right now is it's autospawning.
[01:41] <izm99> LarstiQ: oooh... yeah, that bothers me sometimes too, actually.  never bothered looking for how to turn it off.
[01:42] <izm99> LarstiQ: but i'm interested to try the new tab interface...  :)
[01:42] <LarstiQ> also, I don't appreciate it chaning my root window.
[01:44] <LarstiQ> ah, -n is helpful
[02:03] <LarstiQ> emilis_info: Just installed taglist (finally!), quick test looks great!
[02:03] <LarstiQ> emilis_info: so thanks :)
[02:03] <arjenAU> hmm, branch lp:,mysql-server going since yesterday arvo... still going...
[02:22] <igc> poolie: i have some user doc on stacked branches in progress. Will put a patch up later today.
[02:22] <igc> explaining 'policies' is the main thing left to do
[02:25] <poolie> igc, hi
[02:26] <dan1> does bazaar support encrypted repositories? i searched and found only one plugin that released no code and has not been touched in a year. anyone know of anything else?
[02:27] <poolie> i think there's just that
[02:27] <poolie> so no, they're not supported
[02:28] <dan1> ok, thanks. i sent an email to the author asking about it.
[02:45] <arjenAU> I was going to ask, why... you can have it on an encrypted fs anyway
[02:46] <poolie> arjenAU: well it would be kind of nice to host it on an untrusted server
[02:46] <arjenAU> it's distributed, allover the place, bzr needs to know the pwd anyway... and so on. messy. and slow
[02:46] <poolie> it is a bit of an edge case
[02:46] <arjenAU> poolie: well that's true I suppose. but would you really... that's tricky for other reasons
[02:56] <poolie> imo it's more of a cool feature than a useful one
[02:57] <arjenAU> poolie: yup. nice for later. right now, aim for speed. the mysql-server branching is upsetting me a bit, fortunately its a one off but it's heading towards a 24hr thing
[03:02] <poolie> could you be maybe pulling into or from a knit repository?
[03:39] <poolie> jml, i think i have a fix now
[03:39] <poolie> happy to say
[03:39] <jml> poolie: sweet
[03:39] <jml> poolie: I am happy to hear it.
[03:41] <libwilliam> I was wondering what the default merge algorithm was. in the user reference it shows 4 options, diff3, lca, merge3 and weave but doesn't show what the default it.
[03:41] <libwilliam> is*
[03:44] <mwhudson> libwilliam: merge3
[03:44] <libwilliam> mwhudson, thanks
[03:56]  * igc lunch
[04:55] <poolie> arjenAU: so i can branch mysql-6.0 from launchpad in about 20 minutes
[04:56] <poolie> and my adsl link is busy with other stuff
[04:56] <poolie> it should be roughly comparable for you?
[04:56] <arjenAU> poolie: i' grabbing mysql-server (that is all branches)
[04:56] <poolie> but if you put them in a repo most of the data should be shared?
[04:56] <arjenAU> and I have ADSL2+.. it's not eating the bandwidth. it's just slow as. no idea what it's doing
[04:57] <poolie> check using bzr info they have the same format
[04:57] <arjenAU> hmm
[04:58] <arjenAU> remote? on lp?
[05:02] <arjenAU> poolie: perhaps i'm confused somewhere. on my box I just do bzr init-repo mysql, cd mysql, bzr branch lp:mysql-server
[05:02] <arjenAU> flawed logic that that should be ok?
[05:03] <arjenAU> I think the repo-init was done with an old bzr, I've just restarted the whole thing and we'll see....
[05:03] <arjenAU> that might've been the issue.
[05:04] <arjenAU> poolie: would be godo to have bzr complain about version stuff between repo and the branch you're trying to get. also, perhaps have lp refuse ancient bzr clients to protect them against what I had the other day, namely bzr pulling about 20G of data and putting it nowhere. ate my iiNet allowance ;-)
[05:05] <stewart> poolie: it'd be great if you could bug the launchpad ppl to have init-repo there, takes 7+hrs to push a mysql branch :(
[05:08] <mwhudson> stewart: stacked branches coming soon!
[05:08] <stewart> mwhudson: yay :)
[05:09] <mwhudson> in a couple of weeks i guess
[05:10] <Peng> How big is the repo for one branch of mysql-server?
[05:11] <Peng> stewart: FWIW, I push things to shared repos on my own server, and have Launchpad mirror from there. It still uses lots of my server's bandwidth, but pushing is quick.
[05:12] <stewart> Peng: 500mb or so i think....
[05:12] <stewart> $ du -sh ~/mysql/.bzr
[05:12] <stewart> 619M	/home/stewart/mysql/.bzr
[05:12] <stewart> that's shared repo... but i'm pushing 6.0 branches, which is latest, so includes about all history.
[05:13] <Peng> Nice. I tried to branch it once on a VPS with very little memory and it almost died. :D
[05:15] <stewart> Peng: yeah... branching into shared repo is quite quick (2minutes for a new mysql branch being pulled from europe over bzr+ssh over ADSL1). wish it was that quick for pushing to lp
[05:16] <mwhudson> i guess it
[05:17] <mwhudson> 's not worth it with stacked branches looming, but otherwise i'd suggest getting a machine in the uk you could host a shared repo on and have lp mirror those branches, like Peng said
[05:17] <Peng> Yeah, exactly.
[05:17] <stewart> mwhudson, Peng: there's machines and stuff within Sun that i could do that with, although it involves going through people, not as direct as "bzr push lp:...."
[05:18] <mwhudson> stewart: you can probably make it pretty easy actually (have you seen register-branch?) but well yeah
[05:18] <mwhudson> stewart: hence why stacked branches are priority 1
[05:19] <Peng> stewart: If you have to go through people, they probably won't appreciate you using that much disk space and bandwidth.. :P
[05:30] <poolie> arjenAU: yes, those commands are correct; yes, we should make it give a warning when doing a transfer or conversion that will be slow
[05:30] <poolie> or possibly on any access to a really old format
[05:30] <poolie> and as mwhudson says stacking should fix this on lp soon
[05:31] <arjenAU> poolie: I think the latter was the prob. and there's no indication for it so blocking it would be fine
[05:31] <arjenAU> I mean the old format foo
[05:31] <arjenAU> itt's doing better now on the progress bar. sanity is prevaling
[05:33] <poolie> yay
[05:34] <poolie> little things like a warning would make a big difference
[05:34] <poolie> i'll try to add one soon
[05:37] <arjenAU> yep. tnx.
[05:38] <arjenAU> poolie: I'd say just block old stuff. say to upgrade.
[05:38] <poolie> jml, i think i'm on the home stretch now
[05:39] <poolie> or at least another stretch :)
[05:42] <mwhudson> poolie: yay
[05:49] <jml> poolie: yay
[05:50] <poolie> i have an change i should separate out that puts you into the debugger when a test fails
[05:50] <poolie> it's super useful
[05:50] <poolie> can't believe i haven't done it before
[05:50] <Peng> Wait, yay what?
[05:50] <poolie> yay stacking is nearly landed
[05:50] <Peng> Oh, yay. :)
[05:50] <stewart> i have a suggestion, it'd be cool to have "bzr conflicts" print out a list of files directly, so you could: emacs `bzr conflicts`
[05:51] <stewart> oh... --text does that
[05:51] <arjenAU> poolie: mysql-server 50 minutes. all done
[05:51] <poolie> stewart: yes, but it kind of annoys me it's not the default
[05:51] <poolie> also it would be nice if we could run the editor for you
[05:51] <Peng> How exactly does stacking work? Does it cache X revisions locally? Does it cache all revisions starting at X?
[05:51] <poolie> though emacs users might not prefer it
[05:52] <poolie> Peng: basically the second
[05:52] <poolie> it's not really a cache though
[05:53] <Peng> Yeah, I know.
[05:54] <Peng> Can you (automatically) remove older revisions from the local repo?
[05:54] <Peng> Should we always use stacked branches, or only when it's necessary?
[05:54] <mwhudson> stewart: $ grep -c 'vim $(bzr conflicts --text)' /home/mwh/.bash_long_history
[05:54] <mwhudson> 23
[05:54] <mwhudson> :)
[06:03] <poolie> peng, if you're familiar with a union filesystem mount it's kinda like that
[06:47] <poolie> jml, mwhudson, i have only 3 more failures, all repetitions of the same test and i think i know why
[06:48] <jml> \o/
[06:48] <mwhudson> \o/
[06:48] <mwhudson> poolie: what exactly is in this branch btw?
[06:48] <poolie> integration of stacking into trunk
[06:48] <mwhudson> poolie: branch7 etc but not the stacking policy?
[06:49] <poolie> not the policy patch but that's pretyt small
[06:49] <poolie> i know it does need to be merged too
[06:49] <mwhudson> cool
[06:49] <mwhudson> if it lands, i'll run a launchpad make check tonight against bzr.dev
[06:52] <chandlerc> jelmer: known issue about apr-config and rst2html binaries being arbitrarily used by "make" in bzr-svn? (i have apr-1-config and rst2html.py here...)
[06:53] <poolie> chandlerc: what do you mean by 'arbitrarily'?
[06:57] <chandlerc> it doesn't seem to do any detection of the path, or variable substitution
[06:57] <chandlerc> but i haven't looked directly at the makefile -- could be dead wrong
[06:59] <chandlerc> poolie: ahh, it seems RST2HTML is a variable, apr-config comes out of setup.py, but it actually keeps testing till it finds (correctly) apr-1-config, so the "error message" is just not swallowed
[07:00] <chandlerc> poolie: setting RST2HTML=rst2html.py fixed it right up, although it didn't fail fatally before, just didn't bulid the HTML docs, which is fine
[07:20] <Peng> Random: bzrlib/tests/ is 106k lines of code, including whitespace and everything.
[07:21] <Peng> All of bzrlib is 211k.
[07:53] <Odd_Bloke> Moin.
[07:54] <Peng> Hmm, I have an appointment in 6.5 hours. I should sleep or something.
[08:02] <lifeless> Jc2k: pong
[08:02] <lifeless> poolie: hi, can't skype from here, can use phone
[08:02] <poolie> hi lifeless
[08:02] <poolie> that could be good
[08:02] <poolie> i can call you if you want
[08:03] <lifeless> just starting a talk now, is 55 minutes ok for you? I'll ring - cheaper
[08:06] <poolie> ok
[08:08] <Odd_Bloke> Do we have any test coverage figures for bzr?
[08:08] <poolie> no
[08:08] <poolie> there may be some support for making it, i'm not sure
[08:11] <vila> poolie, Odd_Bloke: I'm not aware of any figures, spiv may (he implemented the --coverage global option and used it at least for parts of bzr). I'm interested in such figures too.
[08:12] <vila> and hi all :)
[08:14] <poolie> hello vila
[08:14] <poolie> i should mail you
[08:29] <markh> is there a particular reason the gtk plugin doesn't offer a 'glog' command?  Is it considered that gannotate is all you really need?
[08:30] <markh> (I'm hoping to directly reuse almost all of the 'g' commands for tbzr)
[08:33] <fullermd> I think 'viz' usually fills that role in -gtk...
[08:33] <AfC> markh: `bzr viz` fills that role
[08:33] <markh> ahh, thanks.  I missed that as it doesn't start with 'g' :)
[08:34] <Peng> Maybe someone should add an alias?
[08:34] <AfC> Peng: if you do `bzr help commands` everything says where it comes from. You can always just ` | grep gtk`
[08:35] <AfC> Peng: but perhaps an alias would be good - unless someone is planning on writing a glog that does something else.
[08:35] <markh> but you do get "tricked" into thinking that gtk adds a new version of most common commands, but with a 'g' prefix
[08:35] <fullermd> Which unfortunately fails when descriptions go to more than one line   :|
[08:35]  * fullermd wishes for "bzr plugin-commands $FOO"
[08:35] <markh> but I admit it was there for me to find :)
[08:36] <AfC> fullermd: aren't the descriptions single lines? If not, "oh"
[08:36] <fullermd> Not all.
[08:36] <Peng> fullermd: Maybe "bzr help plugins/foo" should list them.
[08:36] <fullermd> cvsps-upgrade-conversion Convert the old layout of branches to the new one.
[08:36] <fullermd>                          [cvsps]
[08:36] <fullermd> fetch-ghosts             Attempt to retrieve ghosts from another branch.
[08:36] <fullermd>                          [bzrtools]
[08:36] <fullermd> [etc]
[08:37] <AfC> You'd think a project which refuses to feed its output to $PAGER would refuse to wrap its lines.
[08:37] <fullermd> I guess the gtk ones are all shor...   no, there's test-gtk, running onto a second line for the [gtk]
[08:38] <AfC> But as to markh's query, all that we are discussing only applies if you've conceived of the problem as "there GUI commands I am looking for are in a plugin called '[bzr-]gtk' and so I should search down from that"
[08:44] <Peng> bug 220331 (in reference to a mailing list post, not what's going on here)
[08:44] <Peng> Thank you, ubottu.
[08:44] <Peng> bug 109115 (same)
[08:49] <lifeless> poolie: is your phone on ?
[08:52] <poolie> lifeless: yes, i was on teh phone to amanda
[08:52] <poolie> lifeless: try again?
[09:01] <lifeless> Jc2k: http://bzr-playground.gnome.org/gnome/.mirror-log/changes <- the log
[09:05] <Kinnison> lifeless: how goes guadec?
[09:09] <markh> it seems 'bzr viz' always shows a visualization of the entire branch - which is different than 'log'
[09:20] <fullermd> Well, I didn't say it was the same   :)
[09:28]  * Odd_Bloke --> breakfast
[09:36] <steltho>  With bzr, is there any way I can pull a specific commit from another branch, kind of like git cherry-pick?
[09:37] <gour> git has cherry picking?
[09:37] <lifeless> gour: it records a single revid
[09:37] <lifeless> steltho: yes you can, bzr merge -r x..y BRANCH
[09:38] <gour> lifeless: but that's still not like darcs' ?
[09:38] <lifeless> gour: not at all
[09:38] <gour> (due to different design)
[09:40] <markh> fullermd: you think there is scope to add a 'glog' command which is just a graphical version of 'log'?  Or maybe it is considered unnecessary?
[09:40] <markh> (I'm not asking anyone to do it - just if it makes sense!)
[09:41] <lifeless> markh: I think it does
[09:41] <lifeless> markh: though for full log it should look like viz :)
[09:42] <markh> lifeless: by "full log", you mean "log of entire branch"?
[09:42] <markh> I'm not sure what a log of multiple files should do.  Maybe it makes more sense for 'vis' to accept a filename?
[09:42] <markh> s/a filename/list of filenames/
[09:46] <lifeless> markh: sure; st
[09:50] <poolie> hello markh
[10:01] <poolie> jml, stacking passes all tests
[10:02] <jml> poolie: rock the cazbah
[10:09] <poolie> and patch is sent
[10:09] <lifeless> poolie: woo!
[10:09] <poolie> lifeless: if you could read it that would be great
[10:09] <poolie> there is some more that can be done but at least it passes
[10:09] <poolie> it's in the 'stacking status update' thread
[10:09] <poolie> have a good weekend
[10:11] <poolie> now i should really log off
[10:11] <poolie> night
[10:13] <a_c_m> anyone know of any good introduction videos for bzr, im trying to sell the development team/management on the idea, videos seems to get watched from start to finish, were as text gets skimmed or not read at all :)
[10:16] <AfC> If there isn't, perhaps we should get a good one produced. That would be fun to be a part of, actually.
[10:26] <markh> poolie: hi.  I'm at the bzr sprint at europython, which is quite cool!
[10:26] <markh> I wish I could work out how to get a group of talented people to work like dogs for free for a few days ;)
[10:32] <steltho> \leave
[10:35] <james_w> a_c_m: would you be after screencasts, or more presentational videos?
[10:35] <Odd_Bloke> neobug: Hey, just replied to your email.
[10:36] <neobug> ok, thanks
[10:36] <Odd_Bloke> neobug: How did you send your changes to the mailing list previously?
[10:37] <neobug> Odd_Bloke: LarstiQ helped me
[10:37] <neobug> I just sent a mail with Mutt
[10:37] <neobug> and attached a bundle
[10:38] <Odd_Bloke> neobug: OK, you should be able to do exactly the same again, having committed your changes to the same branch.
[10:38] <lifeless> markh: hey there
[10:38] <lifeless> markh: who is sprinting?
[10:40] <markh> Wouter was here yesterday, but there are a few new people who have never used or seen bzr too - which is quite amazing really
[10:40] <markh> A couple of [RFC] mails to the list are from such people
[10:40] <lifeless> most excellent
[10:41] <gour> markh: save'em all ;)
[10:41] <a_c_m> james_w: dont mind... just something text light, ideally with moving bits and sound ;)
[10:42] <a_c_m> james_w: i just sent out one of the pdf presentations as a stop gap... but i doubt they would make it past all 50 odd pages
[10:42] <Odd_Bloke> markh: On a side note, if you could encourage them to use '[MERGE/RFC]' rather than just '[RFC]', that makes not losing them much easier.
[10:42] <james_w> a_c_m: I've been working on some instructional screencasts. We haven't set up hosting for them yet, and there are only a few, but once I've got my current deadline out the way I hope to make some more.
[10:44] <a_c_m> james_w: sounds good to me, ones on the different workflow situations and how to set them up / use them would be what my guys would be most interested in
[10:44] <james_w> a_c_m: I hadn't got that far yet, but that's the sort of thing that I would like to do. Unfortunately they are not quick to produce.
[10:47] <markh> Odd_Bloke: that is a convention that is news to me.  Wouter was actually mentoring those guys yesterday, but I'll try and make that happen for today.
[10:48] <markh> I think that none of the patches was really considered ready for merging though (IIRC, one of the new error messages suggested buying more RAM ;)
[10:49] <uws> markh: which Wouter?
[10:49] <markh> I suggested adding "you idiot" to the end of the message ;)
[10:49] <uws> V?
[10:49] <uws> vH
[10:49] <markh> umm - not sure :)  The dutch one
[10:49] <uws> you're highlighting me :)
[10:49] <uws> markh: i'm "the other dutch wouter"
[10:49] <markh> oh :)
[10:49] <uws> but I'm at guadec, so it's not me ;)
[10:49] <markh> um - the one with the Q at the end of his IRC nick
[10:49] <uws> thogh we do have a bunch of bzr people around here as well
[10:49] <uws> larstiq that is
[10:50] <a_c_m> james_w: cool, are you on identi.ca ?
[10:50] <markh> yeah!
[10:50] <james_w> a_c_m: nope
[10:50] <a_c_m> james_w: shame
[10:50] <james_w> heh :-)
[10:54] <lifeless> uws: larstiq
[11:02] <lifeless> beuno:
[11:02] <lifeless> Traceback (most recent call last):
[11:02] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/controllers/changelog_ui.py", line 45, in get_values
[11:02] <lifeless>     revid, start_revid, filter_file_id, query)
[11:02] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
[11:02] <lifeless>     return unbound(self, *args, **kw)
[11:02] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 458, in get_view
[11:02] <lifeless>     revid_list = self.get_file_view(start_revid, file_id)
[11:02] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
[11:02] <lifeless>     return unbound(self, *args, **kw)
[11:03] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 423, in get_file_view
[11:03] <lifeless>     revlist = list(self.get_short_revision_history_by_fileid(file_id))
[11:03] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
[11:03] <lifeless>     return unbound(self, *args, **kw)
[11:03] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 330, in get_short_revision_history_by_fileid
[11:03] <lifeless>     w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
[11:03] <lifeless> breaks http://bzr-playground.gnome.org/robsta/gtk-css-engine/changes?start_revid=20&filter_file_id=gtk2.0-20080708104047-cvt44z7pck8smu4n-3
[11:05] <beuno> ew
[11:07] <beuno> hm
[11:07] <beuno> lifeless, that's using the latest lh-search?
[11:07] <lifeless> beuno: I hope so :) - but its in history.py in loggerhead :)
[11:08] <lifeless> beuno: its using the latest loggerhead-gnome-theme
[11:08] <lifeless> beuno: http://bazaar.launchpad.net/%7Ebeuno/loggerhead/gnome_theme/
[11:09] <beuno> that file is empty
[11:10] <beuno> I wonder if that's what triggers the traceback
[11:10] <lifeless> beuno: using weave_store triggers it
[11:10] <lifeless> beuno: its running 1.6b3 bzr
[11:11] <beuno> lifeless, where can I get a branch for that repo?
[11:11] <lifeless> http://bzr-playground.gnome.org/robsta/gtk-css-engine
[11:12] <lifeless> bbs
[11:15] <beuno> lifeless, it doesn't blow up in trunk
[11:15] <beuno> looking at what may have caused it
[11:17] <beuno> lifeless, pushed a revision that fixes it
[11:20] <lifeless> beuno:
[11:20] <lifeless> Traceback (most recent call last):
[11:20] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/controllers/changelog_ui.py", line 45, in get_values
[11:20] <lifeless>     revid, start_revid, filter_file_id, query)
[11:20] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 376, in get_view
[11:20] <lifeless>     revid_list = self.get_file_view(start_revid, file_id)
[11:20] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 342, in get_file_view
[11:20] <lifeless>     revlist = list(self.get_short_revision_history_by_fileid(file_id))
[11:20] <lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 252, in get_short_revision_history_by_fileid
[11:20] <lifeless>     w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
[11:20] <lifeless> AttributeError: 'KnitPackRepository' object has no attribute 'weave_store'
[11:22] <beuno> that's odd, I don't get that traceback locally
[11:22] <beuno> running bzr.dev
[11:26] <lifeless> beuno: you're probably not actually using bzr.dev :)
[11:26] <lifeless> beuno: check your python path
[11:28] <beuno> mn
[11:28] <beuno> damn
[11:29] <beuno> how can I force bzr.dev in my python path?
[11:37] <lifeless> PYTHONPATH=path_to_bzr.dev ./serve-branches.py
[11:38] <beuno> and on a more permanent basis?
[11:38] <lifeless> install bzr.dev ? :)
[11:39] <beuno> you and your complicated ways...
[11:40] <beuno> hm, I still don
[11:40] <beuno> 't get the traceback
[11:41]  * beuno installs bzr.dev
[11:41] <lifeless> beuno: its simple really - weave_store does not exist anyomore
[11:42] <beuno> yeah, I'll have to update that
[11:42] <beuno> I'd just like to reproduce it
[11:42] <beuno> there
[11:42] <beuno> ok
[11:43] <beuno> I'll file a bug
[11:43] <beuno> thanks lifeless
[11:44] <lifeless> beuno: so, can I suggest:
[11:44] <lifeless> put a import pdb;pdb.set_trace() statement at that line
[11:44] <lifeless> run serve-branches, hit the page
[11:44] <lifeless> if the line triggers you'll be in pdb
[11:44] <lifeless> beuno: then, import bzrlib; print bzrlib.__file__
[11:45] <lifeless> that will tel you what bzrlib its finding
[11:47] <beuno> oh, that's interesting
[11:50] <beuno> lifeless, I'll try and get that fixed this evening
[11:53] <lifeless> beuno: I'll fix it now I think then
[11:54] <lifeless> beuno: users :)
[11:54] <beuno> lifeless, argh, sorry. It's my last day here, and, again, tight schedule  :/
[12:08] <awilkins> Hi there, I think I may have found a bug in the HTTP response handling ; anyone know about that bit and want to talk about it?
[12:21] <lifeless> awilkins: vila is good to talk to
[12:21] <awilkins> vila: Ping?
[12:21] <awilkins> I'm going to put a bug up for this, I think, anyway.
[12:22] <vila> awilkins: not interruptible right now, file the bug, I'll comment, associated tests are in test_http_response.py, if you encounter it in RL, please add relevant .bzr.log while -Dhttp is active
[12:22] <awilkins> Righto
[12:30] <lifeless> beuno: fixed, branch coming up
[12:37] <lifeless> ok, fixed - http://bzr-playground.gnome.org/robsta/gtk-css-engine/changes?start_revid=20&filter_file_id=gtk2.0-20080708104047-cvt44z7pck8smu4n-3
[12:41] <markh> so, any other competing GUI toolkits apart from gtk and qt? ;)
[12:42] <markh> hrmph - maybe I misunderstood - is there a QT UI toolkit for bzr at the moment?
[12:43] <markh> ah - just needed the correct google-foo - QBzr
[12:46] <lifeless> beuno: http://bazaar.launchpad.net/~lifeless/loggerhead/gnome
[12:50] <beuno> lifeless, very cool, thanks. I'll merge that into trunk in a while
[12:52] <lifeless> beuno: also, .keys()/.versions() are bad apis, don't use them :)
[12:55] <beuno> lifeless, noted. There are still large parts of the code which are, well, inherited  :)
[13:20] <Odd_Bloke> I'm going to be away over the weekend, probably without Internet and certainly without time to spend on PQM/bzr stuff.
[13:20] <Odd_Bloke> So if anyone wants anything, you have about 10 minutes. :p
[13:29] <james_w> anyone know an easy way in python to grab a file from http only if not modified compared to the local one
[13:29] <james_w> i.e. to set If-Modified-Since or similar?
[13:29] <james_w> bonus points if I can do it with the bzrlib transport.
[13:34] <Odd_Bloke> Right, I'm off.
[13:35] <Odd_Bloke> See you all Sunday/Monday. :)
[13:35] <james_w> see you
[13:39] <markh> james_w: um - set the if-modified-since header? ;)
[13:40] <markh> Or If-None-Match is you have remembered the etag
[13:40] <james_w> markh: yeah, I'm looking in to it. I firstly need to translate from the modified time of the local file to the correct format
[13:40] <markh> (actually, you will have had to remember the date too)
[13:41] <markh> Actually, that might not be good enough
[13:41] <markh> a cached response will have a date in the past, for example, and the RFC says you should just treat the date header as a string, not as a date for this purpose
[13:41] <markh> so you probably need to remember a couple of headers at least
[13:42] <markh> (your requirements may be a little simpler, but in the general case, the above is true)
[13:42] <james_w> ok, thanks, I'll look to see if these servers provide etags
[13:42] <markh> well - etgas and date are the same problem for you
[13:43] <markh> you need to remember *either* (or both, but either will do)
[13:43] <markh> so etags really isn't simpler than date, nor vice-versa
[13:44] <markh> I guess if you were suport luck, the etag may be in the HTML as a "http-equiv" tag (or however that is spelt)
[13:44] <markh> s/suport/super/
[13:45] <james_w> this 'aint html, so that won't help unfortunately.
[13:45] <markh> but I doubt it
[13:45] <markh> right
[13:45] <james_w> so you would recommend just saving the date and repeating it back.
[13:45] <markh> in an if-modified-since header, yeah.  Then you expect either a 304 or 200
[13:46] <markh> 304 means not changed and no body will come, 200 means it has changed and the new version will come
[13:47] <james_w> thanks. Now I see why there isn't a simple bit of code I can steal.
[13:49] <markh> :)
[13:51] <markh> james_w: ack - its not the "date" header you remember, its the "last-modified"
[13:51] <markh> but the rest remains the same
[13:52] <james_w> thanks, I'm stubbornly not opening the RFC, so I'm sure to get some things response
[13:53] <lifeless> james_w: you want to read the rfc
[13:53] <lifeless> james_w: otherwise I will laugh at you :)
[13:53] <james_w> heh :-)
[13:53] <markh> yeah, sadly the RFC can't be avoided ;)
[13:53] <markh> its pretty approachable though
[13:53] <lifeless> james_w: its a complex bitch to deal with, but doing it wrong will just fail
[14:12] <lifeless> abentley: http://advogato.org/person/robertc/diary/92.html
[14:13]  * awilkins is also in _persnickity-RFC-implementation-land_
[14:13] <awilkins> vila: Ping?
[14:15] <vila> awilkins: pong
[14:16]  * vila is interrupted but not available for too long :)
[14:16] <awilkins> vila: Hi there ; just where this bug is is a matter of opinion ... but I think I've fixed it
[14:16] <vila> bug number ?
[14:16] <awilkins> https://bugs.launchpad.net/bzr/+bug/247585
[14:17] <awilkins> Angle brackets are not permissible under RFC 2046, but Python also behaves badly by considering angle brackets to be quotes for the purposes of RFC 822 quoting (as far as I can tell)
[14:17] <awilkins> So I've resorted to passing all the boundary lines in reponse.py through rfc822.unquote() before they are checked
[14:18] <awilkins> Which fixes it
[14:19] <awilkins> I think that's fair given the parameters (including boundary) all get the same treatment when the headers are parsed
[14:20] <vila> awilkins: hmm, sounds reasonable, could you add tests to reproduce it (make it fail before your patch, succeed after) and send that to the list ?
[14:20] <awilkins> vila: I knew that bit would be the most work :-P
[14:20] <vila> since this will be very localized (with a comment explaining it :-) I think there is no point in refusing to work for IIS
[14:21] <vila> awilkins: I think it's a matter of subclassing TestRangeFileMultipleRanges and redefining _boundary_line :-)
[14:22] <awilkins> vila: Ah, well at least that'll be nice and quick
[14:22] <awilkins> TestRangeFileMultipleRangesLikeIIS here we come
[14:23] <awilkins> It seems to use the same boundary string (qhich is someone hopscotching on their keyboard) all the time
[14:23] <awilkins> q1w2e3r4t5 etc
[14:23] <vila> who ? IIS ?
[14:23] <awilkins> Yes
[14:23] <vila> pfff, no further comment
[14:23] <awilkins> I have half a mind to try some content with it's boundary string inside it and see if it copes
[14:24] <vila> well, it shouldn't, we don't scan each part searching for the boundary line, we *know* where they should occur
[14:24] <awilkins> Yeah, but the RFC says it shouldn't happen - boundary strings should not occur in content
[14:24] <vila> the boundary line mechanism is more a robustness encoding
[14:25] <awilkins> BUt I have a feeling that this may be a kludge everyone uses
[14:25] <awilkins> Can you imagine guaranteeing the non-occurence of a given string in a 4GB file on a busy webserver?
[14:25] <vila> The best would be if you can find another implementation known to work with apache2 and IIS needing multi-part and check how they did it
[14:26] <vila> awilkins: You don't have to guarantee that, we *don't* search inside the part itself since we know its size
[14:26] <awilkins> vila: True, it's just the RFC-driven pedant inside me :-)
[14:26] <vila> Content-Range is *required*
[14:27] <vila> ok :)
[14:28] <awilkins> quoth "The boundary delimiter MUST NOT appear inside any of the encapsulated parts
[14:28] <awilkins> ANyhow, thanks for the pointer on the test, that would have taken me a qhile to figure out
[14:30] <vila> awilkins: argh, then IIS is utterly broken of they always use the same one :-/
[14:30] <vila> s/of/if/
[14:31] <vila> np, helping people provides tests helps bzr having more tests :-D
[14:31] <awilkins> vila: It may use a different one if it detects it in the content, but since testing that isn't going to change IIS... I'm rather inclined not to bother
[14:33] <vila> I'll check that when I'll review your patch (if I can find the time) but I'm pretty sure *we* dont't search for the boundary inside the part, so whether or not the multipart is RFC-compliant (for that particular point) should not be a problem
[14:33] <awilkins> I don't see that anywhere either
[14:34] <vila> on the other hand unquote may not be the best solution since after all, you *guessed* their RFC interpretation, may be they always put <> and in that case deleting only that may avoid false positives
[14:35] <vila> awilkins: I suppose you can't check the sources for all available versions of IIS ? No ? Too bad :D
[14:35] <cyberix> is get_transport supposed to work when base isn't a directory?
[14:35] <awilkins> vila: Only verified it on 6.0 and .70
[14:35] <vila> awilkins: in the sources ??? :D
[14:36] <vila> cyberix: It' not supposed to be used with anything but directories...
[14:36] <vila> what is your use case ?
[14:36] <awilkins> vila: Nope, but it doesn't vary on different content and it's always the same plinky-plonked string that some bored developer thought was an unlikely char stream....
[14:37] <vila> awilkins: you can verify that by creating a file with many occurrences of it and querying multiple ranges of it
[14:39] <cyberix> vila: I'm tracking back a problem with someone trying to do a push on a bundle
[14:40] <cyberix> vila: That is not (yet) supported
[14:40] <cyberix> so I'd like to add an exception when someone tries to do get_transport on a file
[14:40] <vila> You can't
[14:40] <cyberix> oh bugger
[14:40] <vila> get_transport do not even connect
[14:41] <cyberix> ?
[14:41] <vila> the first operation on the transport that requires access will automatically connect
[14:41] <cyberix> oh
[14:42] <cyberix> Where can I find the code that connects?
[14:42] <vila> you may want to have a look at bzrlib.bundle.read_bundle_from_url and below to see how to deal with such cases
[14:43] <vila> cyberix: gee, in all transport implementations under bzrlib/transport/
[14:43] <cyberix> ofcourse
[14:43] <cyberix> sorry I'm a newbie and a bit slow because I'm tired
[14:43] <vila> but look at bzrlib.bundle.read_bundle_from_url first
[14:44] <cyberix> But currently I'm not even detecting whether or not the file is a bundle
[14:44] <cyberix> You try to push on a file -> I warn you and exit
[14:44] <cyberix> The problem is detecting whether or not the target is a file
[14:44] <vila> try pushing, trap exceptions
[14:45] <vila> put pushing to a bundle sounds really like a strange idea
[14:45] <vila> bundles are not supposed to be updated
[14:45] <cyberix> I can see that
[14:45] <vila> replaced, yes, updated, I fail to see how
[14:46] <cyberix> The next step would be to tell the user he should do merge and send -o instead
[14:46] <awilkins> vila: Confirmed, it does it even when serving a file packed with "--<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>\r\n" and "<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>\r\n" .. (but I bet apache makes a similar compromise)
[14:46] <cyberix> But I want to get the checking to work first
[14:47] <vila> awilkins: ok
[14:47] <cyberix> vila
[14:47] <cyberix> : does that sound more correct to you
[14:48] <vila> cyberix: That's called 'Look Before You Leap) and we try hard to avoid that
[14:49] <cyberix> The problem is that some users might take the advice and go for it without thinking what it actually does?
[14:50] <vila> :-) It applies to code, not to humans
[14:51] <vila> What is your idea big picture ?
[14:53] <cyberix> I don't think it is a lot bigger than what I already told you
[14:54] <cyberix> 1) tried pushing to a bundle
[14:54] <cyberix> 2) bzr complained about directories
[14:54] <cyberix> There are no directories involved, so it is a bug
[14:55] <cyberix> Then I was told that instead of pushing to a bundle you are supposed to do pull/merge and send -o
[14:55] <cyberix> So might as well tell that to the user who is trying to push into a bundle
[14:56] <cyberix> It does not necessarily make sense to do that for him, because he might not expect the bundle getting mered into his tree when does push
[14:56] <cyberix> telling him about the possibility might still help him
[15:00] <markh> cyberix is also at the europython sprint.  For background, we have been telling people that a bundle is basically a self-contained branch - so an enquiring person then tried to *push* to a bundle (its a branch, right? ;)
[15:00] <markh> so we understand and agree that's not supported - but we want to fix the error message in that case
[15:04] <vila> hmmm
[15:04] <vila> it's a self contained *read-only* branch
[15:05] <vila> does that fix it ? :-D
[15:05] <vila> but... bzr should already says 'not a branch' no ?
[15:06] <vila> I don't think you need to go deep to the transport level to trap that
[15:07] <cyberix> I'm currently planning to go for something like...
[15:07] <cyberix> 'Pushing to a file is not supported at the time.'
[15:08] <vila> But I don't think it will ever be supported since you will need to re-recreate the bundle anyway
[15:09] <cyberix> Yep, might take out 'at the time'
[15:09] <cyberix> Then, if I managed to detect that the file is a bundle I might go with something like...
[15:09] <cyberix> 'Bzr doesn't support direct push into a branch contained within a single file. Use merge to import the changes into your local branch, then use send with switch -o to publish a new single file branch.'
[15:09] <vila> haaaa
[15:10] <vila> hmm
[15:11] <vila> then you should do that in push itself and stay far above the transport level
[15:17] <LarstiQ> vila: the current code tries to mkdir('.') on to_transport, which raises a FileExists, and then it assumes it was a directory
[15:17] <LarstiQ> vila: the error message is rather confusing in that case.
[15:17] <markh> LarstiQ: aren't you supposed to be sleeping to prepare for your music festival? ;)
[15:17] <LarstiQ> markh: I've caught up on sleep, showered and am waiting to be picked up :)
[15:19] <vila> LarstiQ: hi :D
[15:19] <vila> are you referring to ensure_base implementation ?
[15:19] <LarstiQ> vila: cmd_push code
[15:20] <LarstiQ> vila: lines 796
[15:20] <vila> wow line 787 here, I lag :-/
[15:21] <vila> Anyway, 1) You're in the right spot, 2) You just found an old XXX => You won !
[15:22] <LarstiQ> :)
[15:23] <LarstiQ> heya emilis_info
[15:23] <emilis_info> heya LarstiQ, how was your flight?
[15:23] <emilis_info> :)
[15:23] <LarstiQ> vila: when I looked at transport, I didn't see a way to distinguish wether we're dealing with a file or a directory, so choosing which message to return is slightly tricky
[15:24] <LarstiQ> but maybe the error carries some information
[15:24] <LarstiQ> emilis_info: scary :)
[15:24] <emilis_info> LarstiQ, airline madness? :)
[15:24] <LarstiQ> emilis_info: that is, the airport had a general (checkin) system failure, so nothing happened for half an hour
[15:25] <LarstiQ> we managed to leave on time, but the Moscow flight in front of me had people get checked in 5 minutes prior to scheduled takeoff
[15:25] <emilis_info> hmmm...
[15:25] <emilis_info> maybe they were upgradins stuff
[15:25] <emilis_info> :)
[15:25] <vila> LarstiQ: This will be inherently tricky, the best I can think of, once the FileExists has been raised, is to issue a stat() call (incurring roundtrip, but since it's error handling it could be acceptable)
[15:26] <vila> then you can use st.st_mode to check if it's file or directory
[15:26] <LarstiQ> emilis_info: seeing how stressed out the staff was, I don't think so ;)
[15:26] <LarstiQ> vila: can we stat?
[15:26] <vila> *but* stat() is implemented on writable transports only
[15:26] <LarstiQ> right
[15:26]  * vila loves when answer cross question on the wire :)
[15:27] <vila> but in your case, push requires a writable transport
[15:29] <LarstiQ> vila: are we guaranteed to have a writable transport at that point?
[15:30]  * LarstiQ hates dying phones 
[15:30] <vila> LarstiQ: no, but a different exception will be thrown in that case when you try to nkdir()
[15:32] <cyberix> LarstiQ: So don't dye them.
[15:32] <vila> And you get the get famous "http doesn't implement mkdir" error which confuse so many people :)
[15:32]  * vila goes back to gdb for good...
[15:33] <LarstiQ> cyberix: correct, good sir :P
[15:33] <LarstiQ> vila: have fun
[15:48] <cyberix> LarstiQ: You too. I'm soon going to call it a day.
[15:48] <cyberix> But I'm not planning to give up the holy task.
[16:50]  * ToyKeeper finally figures out what's making the labels in bzr vis overflow their parent widgets
[17:46] <awilkins> CAn anyone tell me a smart bzr+http:// I can point a session at so I can see what it's supposed to look like in a debug proxy?
[17:46] <Foskasse> sup
[17:46] <awilkins> I'm about halfway to getting IIS to serve bzr over ISAPI
[17:54] <james_w> awilkins: I don't actually know anywhere that serves over bzr+http://, maybe someone has something set up.
[17:55] <ricardokirkner> hi. I have been struggling with that setup.. what is the problem?
[17:55] <awilkins> ricardokirkner: I have it returning "bzr message 3", and then the client just queries the parent folder ; repeat until 404
[17:56] <awilkins> I think something is missing from my query
[17:56] <awilkins> It might be my WSGI shim though
[17:56] <ricardokirkner> mhh.. sorry, that doesn't ring a bell...
[17:57] <ricardokirkner> my problems where related to not finding the repository, and to authentication
[17:58] <awilkins> ricardokirkner: I can tell bzr is running from the response ; I don't think it's finding the repository either
[17:58] <awilkins> But I think it's my WSGI calling script
[18:00] <ricardokirkner> I had it running with wsgi, and the script is extremely simple (it just bypasses everything on an url to bzr)
[18:01] <awilkins> I;m not sure it's passing the RIGHT stuff
[18:01] <ricardokirkner> here you can see my script: http://pastebin.com/d1d612421
[18:02] <ricardokirkner> that, plus a few lines in http.conf, which I will shortly paste
[18:05] <ricardokirkner> http://pastebin.com/m7ec0f366
[18:05] <ricardokirkner> I am using mod_wsgi
[18:05] <awilkins> I'm using IIS 7 and PyISAPIe
[18:06] <awilkins> Not through choice, I hasten to add :-)
[18:06] <ricardokirkner> ok.. then I dont think that will help you out... maybe it's a windows issue... I am sorry, I cant help you out there
[18:06] <awilkins> I think I'm getting closer, it's accessing a bunch of files in the repo folder now
[18:16] <chandlerc[g]> hrm, I'm getting an odd error on "make" in bzr-svn
[18:16] <chandlerc[g]>   File "./setup.py", line 13, in __init__
[18:16] <chandlerc[g]>     super(CommandException, self).__init__(self.message)
[18:16] <chandlerc[g]> TypeError: super() argument 1 must be type, not classobj
[18:16] <chandlerc[g]> is my Python version too old?
[18:18] <awilkins> What is your Python version?
[18:18] <chandlerc[g]> 2.4.3
[18:18] <awilkins> I saw a comment in the commit log about remving a Python 2.5 -ism recently, could be
[18:19] <chandlerc[g]> hmm i'm working off of 0.4, so i would think i would have anything...
[18:19] <chandlerc[g]> and its in setup.py, which seems especially odd
[18:19] <awilkins> jelmer: ^^
[18:20]  * awilkins is successfully serving his repo from IIS using WGSI
[18:20] <chandlerc[g]> wow
[18:27] <schoni> http://www.pennergame.de/change_please/3238442/
[18:55] <awilkins> vila: On top of fixing that response bug, for good measure I got IIS running as an HPSS
[18:56] <james_w> nice work
[18:57] <awilkins> james_w: Well, I have a "poke hole in firewall" request for SSH going with my IT services crew.... I have this onimous feeling they are going to deny it, so this is insurance.
[18:57] <awilkins> This way I can just exploit a port that's already open to run an interactive application :-)
[19:39] <chandlerc[g]> Any idea why a KnitPackRepository would not be compatible with a KnitPackRepository??
[19:40] <awilkins> chandlerc[g]: Are you pushing over http:// ?
[19:41] <chandlerc[g]> branch over sftp://
[19:41] <awilkins> chandlerc[g]: Is one rich-root-pack and the other not?
[19:41] <chandlerc[g]> maybe?
[19:41] <chandlerc[g]> one is bzr-svn created, the other is a fresh "init-repo"
[19:41] <awilkins> bzr-svn is by necessity rich-root-pack
[19:41] <chandlerc[g]> yea, rich-root-pack
[19:41] <awilkins> pass --rich-root-pack to your init-repo command
[19:41] <chandlerc[g]> just got shelled into tho remote machine
[19:42] <chandlerc[g]> ahhh
[19:42] <chandlerc[g]> thx
[19:42] <awilkins> You're welcome
[19:42] <awilkins> I jsut got the exact same error for a totally different reason :-)
[19:43] <chandlerc[g]> hehehe
[19:43] <chandlerc[g]> its a bit... confusing. ;]
[19:43] <awilkins> Rich roots are set to become the default somewhen
[19:43] <awilkins> But I agree that the error is confusing
[20:21] <vila> awilkins: Great !
[21:30] <Mecha25> hey, anybody know what bzr: ERROR: Transport operation not possible: http does not support mkdir() means?
[21:33] <mtaylor> Mecha25: it means that http does not support mkdir()
[21:33]  * mtaylor ducks
[21:34] <jam> Mecha25: it is usually a sign that you tried to either 'bzr commit' or 'bzr push' to an HTTP url
[21:35] <jam> Generally caused by something like "bzr co lp:project" without doing 'bzr launchpad-login' first. So it checks out the files from the anonymous read-only side.
[21:35] <jam> Alternatively, by doing "bzr push http://URL"
[21:35] <Mecha25> sorry, just got it working, I did need to add my login
[21:35] <jam> which is easier to fix, since you can just do "bzr push sftp/bzr+ssh/etc"
[21:35] <Mecha25> however, now I've pushed it, it has a branch format, but the code isn't there
[21:36] <Mecha25> what happened to the codE?
[21:41] <libwilliam> maybe bzr update?
[21:41] <Mecha25> I'll try that
[21:42] <Mecha25> says No Working Tree exists
[21:42] <libwilliam> or if you are pushing to launchpad wait about 5 minutes
[21:42] <Mecha25> oh
[21:42] <Mecha25> ok, it takes a while for it to get the code?
[21:42] <libwilliam> it always takes a while before the results show up
[21:42] <Mecha25> I just did it 3 seconds ago
[21:42] <Mecha25> cool then, I'll wait
[22:06] <mmmultiworks> does bzr have an external api or swg bindings at all?  I have a need for ruby integration
[22:07] <mmmultiworks> swig bindings, sorry
[22:07] <libwilliam> http://bazaar-vcs.org/Integrating_with_Bazaar
[22:07] <james_w> mmmultiworks: no, sorry, though I think there is a ruby version control API that supports bzr somewhere
[22:08] <mmmultiworks> thanks, I'll keep digging some more
[22:14] <mmmultiworks> james_w: there is this one which I can use as a base probably
[22:14] <mmmultiworks> http://www.redmine.org/repositories/entry/redmine/trunk/lib/redmine/scm/adapters/bazaar_adapter.rb
[22:19] <newz2000> hi, wondering if something like this is possible or even a good idea...
[22:19] <james_w> mmmultiworks: http://rvcs.rubyforge.org/svn/trunk/README
[22:20] <newz2000> I have a config file for project that has a path in it. when I create a branch, is it possible for variable substitution to occur and update the path in the config file?
[22:20] <james_w> newz2000: short answer: no.
[22:20] <james_w> newz2000: long answer: no, but...
[22:20] <newz2000> ok. there's probably a better way then... if it were a good idea it would probably be easy and you all would be using it.
[22:21] <james_w> you might be able to do that with Ian's tree filter stuff that will be in 1.6/1.7
[22:50] <colbrac> hmm.. seems my tweaking of locations.conf yesterday worked. I now produce 2 BB responses on the bzr-gtk list with a patch
[23:19] <gdoubleu> I just did a merge, but then backed out with bzr revert.  Is there a command or option to clean up the unversioned files that stuck around?
[23:21] <Peng> bzrtools adds a clean-tree command that can do this (but read the help; by default it deletes a lot more).
[23:29] <awilkins> bzr ignored | xargs rm   ?
[23:29] <awilkins> Maybe not....
[23:30] <awilkins> bzr ignored | grep -e ~\\d~ | xargs rm   ?
[23:31] <awilkins> best stick with bzr clean-tree --detritus I think
[23:34] <gdoubleu> thanks, I'll check that out
[23:47] <[cliff]> hi all
[23:48] <[cliff]> the guy I work with sent me a bundle via email, I'm trying to merge but I get this message: "bzr: ERROR: Not a branch:" followed by my branch path concatenated with the bundle's path.
[23:48] <[cliff]> how can I merge the bundle?
[23:51] <Peng> Oh, bug 247550 is why Loggerhead broke. Sorry for not getting around to reporting it..
[23:51] <Peng> beuno: With the fix for bug 247550, is Loggerhead still compatible with older versions of bzr? Is it slower, or less memory-efficient or anything?
[23:53] <beuno> Peng, all those are really good questions, for which I don't have a educated answer for right now  :)
[23:53] <beuno> I need to get some sleep
[23:53] <beuno> fly for 16 hours tomorrow
[23:53] <Peng> beuno: Heh, okay. I might find out. Or not.
[23:53] <beuno> and I'll probably be myself again next week
[23:53] <Peng> beuno: Yikes. Moving to the Googlunaplex?
[23:53] <beuno> Peng, let me know what your findings are  :)
[23:54] <Peng> beuno: If you see lots of expletives and whining, you'll know. :)
[23:54] <beuno> Peng, it's called "user feedback"  :p
[23:54] <LaserJock> quick, semi-blasphemous question. Is it possible to *not* have "branches-as-directories"?
[23:54] <Peng> LaserJock: Not at the moment.
[23:54] <Peng> LaserJock: Well, you can use "bzr switch" a lot. And looms sort of do it.
[23:58] <[cliff]> how can I trace bzr execution? is there a switch?