[00:00] <mkanat> mwhudson: Looks indeed like I was getting the assertion because of actually closing a connection before data came out of it.
[00:02] <mwhudson> mkanat: oh right
[00:42] <phoenixz> bzr missing returns a shell exit code 1 if there is branche divergence?
[00:43] <spiv> phoenixz: that sounds right
[00:44] <phoenixz> spiv: ah, since it was not documented in bzr help missing.. I was already wondering about this behaviour
[00:44] <lifeless> we should doc it
[00:44] <spiv> Similar to how diff will return non-zero if there are differences.
[00:44] <spiv> The docs should say so, though.
[00:45] <phoenixz> spiv: what manual?
[00:45] <phoenixz> spiv: bzr help missing doesnt have it documented..
[00:46] <phoenixz> spiv: http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm also doesn't show
[00:46] <spiv> phoenixz: bzr help missing probably should, and maybe other places too.
[00:46] <spiv> Wow, 0.10 is seriously old.
[00:47] <spiv> Is that really the version you are using?
[00:47] <spiv> phoenixz: by "should" I mean, "probably doesn't yet, but that is something for us to fix"
[00:47] <phoenixz> spiv: eh, no, its just a manual I quickly looked up :)
[00:50] <poolie> lifeless: nice page about pmtu
[00:51] <poolie> the historic problem is what i thought it was, but the auto adaption is new to me, and clever
[00:51] <poolie> also " Just remember: The glass is neither half full nor half empty, it is merely the wrong size. " sounds like you :)
[00:54] <poolie> but him spelling 'microseconds' as 'uS' is like nails on a blackboard
[00:56] <lifeless> ;)
[00:56] <poolie> http://en.wikipedia.org/wiki/Siemens_(unit)
[00:58] <poolie> lifeless: more to the point: if you suspect bad window behaviour with streaming, it would be interesting to capture the packets and graph/print/analyse the window flags
[01:02] <lifeless> poolie: yes, spm has tools to do this
[01:02] <poolie> it seems like we should be able to do it at our end?
[01:03] <spm> tcmpdump + tcpflow + xplot ftw
[01:03] <spm> garh. s/tcpflow/tcptrace/
[01:03] <poolie> rly tcmpdump?
[01:03] <spm> man. I so can't type today... tcpdump :-)
[01:04] <spm> wireshark does the window graphing; but I find the above more versatile and ... obvious
[01:05] <spm> poolie: eg: http://tcptrace.org/manual/node12_mn.html
[01:08] <igc> hi poolie
[01:08] <igc> hi spiv
[01:56] <mwhudson> mkanat: are you on ubuntu one?
[01:56] <mkanat> mwhudson: Nope.
[01:56] <mwhudson> oh, this log chunk is only 28k
[01:57] <mwhudson> mkanat: what's your email address?
[01:57] <mkanat> mwhudson: mkanat at everythingsolved
[01:57] <mkanat> dooot coooooom
[01:57] <mkanat> ♫
[02:00] <mwhudson> mkanat: you should have mail
[02:00] <mkanat> Sweet.
[02:00] <mkanat> Indeeed.
[02:19] <rubbs> Hello,
[02:19] <rubbs> I'm interested in squashing some documentation bugs
[02:20] <rubbs> I need some advice though
[02:21] <rubbs> First, where should I pull a branch down from? bzr or bzr-alldocs?
[02:21] <spiv> igc: ^
[02:21] <rubbs> and should I just pull one down and hack away? or should I talk some things over with a maintainer first?
[02:22] <igc> rubbs: hi
[02:22] <igc> rubbs: which docs did you want to fix first?
[02:22] <rubbs> igc: hello are you Mr. Clatworthy?
[02:22] <igc> rubbs: I am
[02:23] <rubbs> igc: cool I'm Pat Regan, I was the newbie on the mailing list who expressed intrest...
[02:23] <rubbs> the first one I was thinking was bug 59608
[02:23] <rubbs> but I'm thinking it might have already been taken care of.
[02:24] <igc> rubbs: most of the doc is maintained inside the main bzr code base
[02:24] <spm> mkanat: fwiw; that's an extract from a fail that starts from 20091118-05:21:13.665; next restarted @ 20091118-05:42:53.336. We have others :-) lots of others! but that's the smallest to start with.
[02:24] <spm> mkanat: and hi, btw :-)
[02:24] <mkanat> spm: Thanks!
[02:25] <mkanat> spm: Hello. :-)
[02:25] <igc> rubbs: so you want to grab lp:bzr
[02:25] <rubbs> Ok, got one grabbed
[02:25] <igc> rubbs: are you using explorer or the command line tool?
[02:25] <spm> mkanat: fwiw, if you need any further assist; ping me or a general 'losa ping' to summon myself or one of my fellows
[02:25] <rubbs> igc: mostly commandline, but I've got qbzr tools installed too
[02:25] <mkanat> spm: Awesome.
[02:25] <igc> rubbs: cool
[02:26] <igc> rubbs: the doc for each command is inside bzrlib/builtins.py
[02:26] <igc> well, most commands at least
[02:26] <rubbs> igc: ok
[02:26] <igc> look for cmd_ignore (say)
[02:26] <mkanat> spm: I'm hoping that I can reproduce the problem locally, but if I can't, then those logs are going to be critical, for sure.
[02:27] <spm> sure. at this stage all that's beeen done is a purely random IP s/r.
[02:27] <mkanat> s/r = search and replace?
[02:27] <igc> rubbs: the tutorials are under the doc/en directory
[02:27] <rubbs> igc: k, found it
[02:27] <spm> sorry - yes.
[02:28] <mkanat> spm: No problem. :-)
[02:28] <rubbs> igc: ok, found those too.
[02:28] <igc> rubbs: have you submitted a merge proposal using Launchpad before?
[02:29] <rubbs> igc: no I haven't. This would be my first ever contribution to anything really.
[02:29] <igc> rubbs: no problem. We're here to help
[02:29] <rubbs> great!
[02:29] <igc> rubbs: the basic summary is ...
[02:29] <igc> (1) make you changes
[02:29] <spm> mkanat: fwiw, had another restart just a few ago. this one actually gave us a debug return: http://pastebin.ubuntu.com/322088/ so you can see some of the requests... hang. fwiw.
[02:29] <igc> (2) commit
[02:30] <igc> (3) push the branch to Launchpad
[02:30] <igc> (4) submit a merge proposal
[02:30] <mkanat> spm: So these are happening pretty frequently then.
[02:30] <rubbs> igc: ok, that makes sense. Not much different than a centralized with local commits workflow then
[02:31] <spm> mkanat: :-) you *could* say that. that codebrowse is referred to by us sysadmins as codebounce, is another clue ;-)
[02:31] <mkanat> LOL
[02:31] <mkanat> Interesting that there are so many /atom requests for exactly two projects right before the hang.
[02:31] <spm> right
[02:32] <spm> where it gets fun is when our nagios check url gets hungup as well.
[02:32] <mkanat> Hahahaha, omg.
[02:32] <igc> rubbs: I need to grab some lunch right now. If you have questions, spiv and many others can help so just ask
[02:33] <igc> bbiab
[02:33] <rubbs> igc: great thanks for all your help
[02:33] <mwhudson> mkanat: sometimes some requests that usually take a few seconds hang around for minutes
[02:33] <mwhudson> mkanat: i have basically no idea why
[02:33] <mwhudson> mkanat: note that our loggerhead access branches over http
[02:33] <mkanat> mwhudson: In terms of the port being open, or what?
[02:33] <mwhudson> not the local filesystem
[02:33] <mkanat> Ohh, interesting.
[02:34] <mkanat> So there's going to be a lot more latency than on my systems.
[02:34] <mkanat> I didn't even know loggerhead could do that.
[02:34] <mwhudson> but i've never pinned this down to a real problem
[02:34] <mwhudson> mkanat: well, not much more latency, it accesses the branches over gigE (i think) to apache serving static files
[02:34]  * mkanat nods.
[02:34] <mkanat> There's still pretty good latency in general over the http protocol.
[02:35] <mwhudson> mkanat: as to it being possible, bzr is awesome sometimes :)
[02:35] <mwhudson> open branch, give it to loggerhead
[02:35] <mwhudson> loggerhead doesn't care about where the branch is from
[02:35] <mkanat> That's pretty awesome.
[02:35] <mkanat> Yeah, bzr's architecture seems pretty sweet, generally, from the outside.
[02:35] <lifeless> thanks
[02:35] <mkanat> :-)
[02:36] <spm> heh
[02:37] <mkanat> Hmm, on the memory leak one, I'm actually not currently getting it to go over a certain fixed size.
[02:37] <mkanat> I'll have to try other things.
[02:38]  * mkanat is also doing a Bugzilla release simultaneously, right now.
[02:40] <mkanat> mwhudson: I was noticing that a few things seem slower than necessary.
[02:40] <mkanat> mwhudson: Though I can't quite pin that down either.
[02:40]  * mkanat just got a pause on mine, too, even on localhost.
[02:40] <mkanat> Was pretty brief, though.
[02:51] <mkanat> mwhudson: Okay, I can at least see which threads are hanging, from the logs.
[02:51] <mwhudson> mkanat: cool
[02:51] <mkanat> mwhudson: I can see the "Getting information for" but no "Rendering" for certain requests right before the hang.
[02:51] <mwhudson> mkanat: are they building revision caches?
[02:51] <mkanat> mwhudson: Yeah, two of them are.
[02:51] <mkanat> I'll check the second hang.
[02:51] <mwhudson> cool
[02:53] <mkanat> The second one's more confusing. :-)
[02:53] <mkanat> There's a lot happening right before that hang.
[02:56] <mkanat> mwhudson: And yeah, I see what you mean about the long requests. Getting information for RevisionUI: 201.69120788574219 secs
[02:56] <mkanat> mwhudson: Here's an interesting thing. All requests are fast shortly before the hang.
[02:56] <mkanat> I mean, *until* shortly before the hang.
[02:57] <mwhudson> so "something" happens, and then suddenly requests are slow, and then we're in a death spiral?
[02:57] <mwhudson> sounds about right
[02:57] <mkanat> mwhudson: Yeah, that seems like what's going on.
[02:58] <mkanat> mwhudson: And it's never rendering that takes a long time, it's always getting information, from what I can see.
[02:58] <mwhudson> mkanat: now, please tell me what it is that happens
[02:58] <mwhudson> :-)
[02:58] <mkanat> LOL
[02:58] <mwhudson> mkanat: my /theory/ is that it's basically thrashing
[02:59] <mwhudson> too much going on at once, too many threads competing for cpu, performance falls into the toilet
[02:59] <mwhudson> it would be good to confirm/deny
[02:59] <mwhudson> mkanat: if you want to enhance logging, we can get new code into production pretty fast for this
[03:00] <mwhudson> (<24 hrs)
[03:00] <mkanat> mwhudson: Okay, awesome.
[03:00] <mkanat> mwhudson: I might want to do that for the memory leak if I don't get anything.
[03:00] <mkanat> mwhudson: Just like a "process increased by X size after this request" sort of thing.
[03:00] <mwhudson> mkanat: go wild :)
[03:01] <mwhudson> we could even try getting meliae dumps i guess
[03:01] <mwhudson> but they will be, uh, moderately large
[03:01] <mkanat> Hahahaha.
[03:01] <mkanat> Yeah, I would imagine.
[03:02] <mkanat> I think it might be better to just narrow down where it's happening first than try to look through a memory analyzer or profiler for the whole process over like, days and days.
[03:03] <mwhudson> from my side, i view the hangs as a much more serious and mysterious problem than the leak
[03:05] <mkanat> Okay.
[03:05] <mkanat> I'll focus on that.
[03:05]  * mkanat had just started to anyway.
[03:05] <mkanat> And the htdig that I'm running against my local repo to try to reproduce the memory leak could go on for hours or days before I get anything, anyhow.
[03:06] <mkanat> mwhudson: BTW, as far as a cache that everything could access, memcached seems like a reasonable possibility too.
[03:06]  * mkanat hasn't played much with CouchDB though.
[03:06] <mwhudson> mkanat: yeah, possibly
[03:07] <mwhudson> mkanat: a disk backend would be plenty fast enough though
[03:07] <mkanat> Anyhow, back to analysis.
[03:07] <mkanat> mwhudson: Okay. :-)
[03:07] <mwhudson> mkanat: a more serious problem is the serialization of the graph
[03:07] <mwhudson> mkanat: we basically deserialize the graph in one lump
[03:07] <mwhudson> and that's crack, it would be really good to stop doing that
[03:08] <mwhudson> mkanat: i guess the memory leak problem will in all likelyhood come back into prominence for us if we fix the hanging problem :-p
[03:10] <mkanat> mwhudson: Wow, yeah, I imagine that kills performance for huge projects.
[03:10]  * mkanat nods.
[03:10] <mwhudson> mkanat: i marshal the data and gzip it
[03:10] <mwhudson> mkanat: loading it for launchpad takes ~0.2s
[03:10] <mwhudson> so it's not terrible
[03:11] <mkanat> Okay.
[03:11] <mwhudson> but still crack :)
[03:13] <Peng> I can make it slower if you want. >.>
[03:13] <mkanat> mwhudson: If I see one thread do "Getting information" on an identical request three times in a row with no Rendering, does that mean the connection broke before it rendered?
[03:13] <mwhudson> mkanat: not necessarily
[03:14] <mwhudson> it means the requests are piling up :(
[03:14] <mkanat> mwhudson: Hmmm. Maybe I'm missing a bit on the architecture here. How does a thread get multiple "Getting information" requests without rendering the previous requests?
[03:15] <mwhudson> mkanat: er
[03:15] <mwhudson> mkanat: can you point me to a line number in the logfile?
[03:15] <mkanat> mwhudson: INF [20091118-05:42:04.440] [1084594512] loggerhead.~munin-custom-plugins/munin/munin-plugins-tomcat: Getting information for ChangeLogUI: 3.7736661434173584 secs
[03:15] <mkanat> mwhudson: That's the line. I have the log file a bit hacked up at the moment.
[03:15] <mkanat> mwhudson: At least, that's where it starts.
[03:17] <mwhudson> mkanat: the requests are being handled by different threads i think
[03:17] <mkanat> mwhudson: Oh, are the numbers in brackets not thread ids?
[03:18] <mwhudson> INF [20091118-05:42:07.532] [1093282128] loggerhead.~munin-custom-p...
[03:18] <mwhudson>                              ^^^^^^^^^^ thread id doing the logging
[03:18] <mkanat> mwhudson: Yeah, that's what I thought.
[03:18]  * mwhudson looks a bit closer
[03:18] <mkanat> mwhudson: I know that all those in a row aren't the same thread, but if you highlight the thread id, you'll see that it makes several information requests and doesn't render them all, and it doesn't really do it in order either.
[03:19] <mkanat> mwhudson: I can investigate this on my own too, if I'm taking up too much of your time.
[03:19] <mkanat> mwhudson: I'm perfectly capable of figuring out everything by digging through the code. :-)
[03:19] <mwhudson> mkanat: that's pretty whack
[03:19] <mkanat> Yeah!
[03:19] <mkanat> That's what I'm saying! :-D
[03:22] <mkanat> mwhudson: Another hung thread does the same thing.
[03:22] <mkanat> 1088797008
[03:23] <mwhudson> mkanat: i would _guess_ that this perhaps means that the client is no longer listening
[03:23] <mkanat> mwhudson: Yeah, some of those "Getting information" requests take so long, there could be a timeout.
[03:23] <mwhudson> (we run loggerhead behind apache, which might make a difference here)
[03:23] <mkanat> mwhudson: I was just about to ask.
[03:23] <mwhudson> mkanat: oh right, yes, so you should know this: our ProxyTimeout is 20s i think
[03:23] <mwhudson> (maybe 30)
[03:24] <mkanat> mwhudson: Ah, okay. :-)
[03:24] <mkanat> mwhudson: So all these bad threads are getting SIGPIPEd or something. But apparently they keep on living.
[03:24] <mwhudson> well python ignores sigpipe
[03:24] <mwhudson> but you should get an error writing to the socket sure
[03:24]  * mkanat nods.
[03:25] <mwhudson> (and i think you do, sometimes)
[03:25] <mkanat> I've seen it in my own logs, yeah.
[03:25] <mwhudson> maybe one or more of: paste, apache, python, linux, the universe is screwing us here
[03:25] <mkanat> LOL
[03:25] <mkanat> Yeah, it's possible.
[03:26] <mkanat> mwhudson: So python ignores the broken socket, and the thread then...? I guess I should go look at the code at this point.
 mkanat: if you want to enhance logging, we can get new code into production pretty fast for this <== actually TBH, us losas will fall all over each other to speedily get ANY changes in
[03:26] <mkanat> spm: Hahahaha, okay. :-)
[03:26] <mwhudson> mkanat: what i would have written by now if i had an infinite amount of time would be a stateful log parser
[03:27] <mkanat> mwhudson: I could probably write that pretty quickly. That's a Perly sort of job.
[03:27] <mkanat> And I've written so many state-machine parsers now...
[03:27] <mwhudson> mkanat: most request go through a predictable pattern (starting to process, using branch url, ..., rendering) and it would be cool to be able to say how many threads at a particular time were in a particular state
[03:27] <mkanat> mwhudson: Oh, that would be interesting for sure.
[03:27] <mwhudson> and also find threads that don't go through that pattern
[03:27] <mkanat> mwhudson: I'll see if I can put together a little script here.
[03:28] <mwhudson> mkanat: that'd be awesome
[03:28] <mwhudson> then maybe we can fling existing logs at it rather than having to ship them to you and see if any interesting patterns show up
[03:28] <spm> wfm
[03:29] <mkanat> mwhudson: Well, I don't know how consumable by the external world said parser will be, but if it's going to be so consumed, I will consider that. :-)
[03:29] <mwhudson> mkanat: we don't have to tell anyone else about it :-)
[03:29] <mkanat> lol, okay.
[03:30] <mkanat> It'll be easier than parsing text stack traces. :-)
[03:30] <mkanat> (That's the last stateful parser I wrote.)
[03:31] <mwhudson> should be
[03:32] <mkanat> mwhudson: BTW, what log is this that I'm getting? Because it looks different than my normal loggerhead logs.
[03:33] <mwhudson> mkanat: the entry point we use and all the log setup is in the launchpad-loggerhead branch
[03:33] <mkanat> mwhudson: Ahh, okay.
[03:33] <mkanat> So this will be a launchpad-loggerhead log parser, then.
[03:34] <mkanat> Not for the standard loggerhead logs.
[03:34] <mwhudson> yes
[03:34] <mkanat> Works for me.
[03:34] <mwhudson> some of the goodnees in launchpad-loggerhead should probably be moved to loggerhead
[03:34] <mwhudson> not sure that the log setup counts as goodness mind...
[03:34] <mkanat> I dunnow, these logs are more readable, at least.
[03:42] <rubbs> OK, dumb question. I've just made some changes for some documentation, how do I push it to LP so I can ask for a merge review?
[03:43] <lifeless> bzr push lp:~username/project/branchname
[03:43]  * rubbs slaps forehead. should have remembered that. thanks
[03:47] <rubbs> Ok, so I've uploaded the branch. And I see where to click for a merge proposal. Is their any sort of standard way of going about this? Should I talk it over with people or just post and let people see it?
[03:48] <rubbs> Sorry for all the newbie questions, I've just never done this before.
[03:48] <spiv> rubbs: feel free to just propose it
[03:48] <spiv> rubbs: no, please ask any questions, that's totally fine
[03:48] <rubbs> spiv: great thanks!
[03:48] <spiv> rubbs: if you're unsure you can ask here or on the mailing list before proposing
[03:49] <rubbs> spiv: great! thanks for being patient. I've always good help from this channel.
[03:49] <spiv> rubbs: but generally a merge proposal is a great venue for a conversation about a branch :)
[03:49] <rubbs> spiv: great to know
[03:51] <distatica> Hey folks, I have a working redmine setup on my web server. I am using it to display my repository status. If I have nothing on the server then it's fine to do a push, and everything works... however I can't then redo a push because I get told transport does not support update; and that branches have diverged. How do I handle this? I just want to put up a copy of my repo, at whatever state it's in, with it's revision history. Do I have to delete t
[03:53] <spiv> distatica: you got cut off
[03:53] <distatica> what point?
[03:53] <spiv> "to delete t"
[03:54] <spiv> But you probably don't want a working tree on the server.
[03:54] <distatica> Do I have to delete the directory completely on the server and push again every time?Do I have to delete the directory completely on the server and push again every time?
[03:54] <spiv> The revision history is all present in the .bzr directory.
[03:54] <distatica> then I'm not sure what I want to do, just upload the whole directory via scp?
[03:54] <spiv> If you want to upload a copy of the current state of the tree to a server, the bzr-upload plugin is a good way to do that.
[03:54] <spiv> distatica: just "bzr push"
[03:55] <rubbs> spiv: thanks for all your help. I've done a merge proposal.
[03:55] <rubbs> igc: thanks for all your help too.
[03:55] <spiv> distatica: and probably "bzr remove-tree" once on the server to get stop the warnings
[03:55] <mkanat> spm: Are those log times in UTC?
[03:55] <distatica> that's what I'm using, for the first time, but then I have to login and delete or else my client complains
[03:55] <distatica> hmm
[03:56] <spm> mkanat: good Q; that server is on BST; but that may == UTC atm. looking....
[03:56] <spiv> I'm curious about how you created the copy of the branch on the server in the first place though, "bzr push" to a remote host won't create working trees.
[03:56] <spm> mkanat: yes. atm, that's UTC
[03:56] <mkanat> spm: Okay.
[03:57] <distatica> spiv: I use --create-prefix with push, that does it doesn't it?
[03:57] <spiv> No, that's something else.
[03:57] <spiv> That's about whether you can push to a/b/c if the directory a/b doesn't exist yet.
[03:58] <distatica> bzr push --create-prefix sftp://name@host.net/~/public_html/code/myproj
[03:58] <distatica> that's what I use, myproj doesn't exist.
[03:58] <distatica> then in redmine, I point it to there for the repo.
[03:58] <spiv> That seems fine (although if code/ exists then --create-prefix is redundant but harmless)
[03:58] <distatica> code can't exist
[03:58] <distatica> because if it does, I get the errors
[04:00] <distatica> oh interesting
[04:00] <distatica> if I use that full line, it works
[04:00] <distatica> if I just do 'bzr push' it doesn't.
[04:00] <distatica> I thought push just used my last information..
[04:01] <spiv> It uses the "remembered" location.
[04:01] <distatica> I'm confused
[04:01] <spiv> The first time you push a branch, it'll remember that location.  But an already remembered location won't be overwritten unless you specify --remember
[04:02] <distatica> oh, how can I see what I'm attemptign to push to?
[04:02] <spiv> bzr will tell you when it is using a remembered location, it'll say something like  "Using saved push location: ..."
[04:02] <spiv> You can also run "bzr info"
[04:03] <distatica> aha
[04:03] <distatica> that's it, pushing to another directory, heh
[04:04] <distatica> oh beautiful, now everything is working. Thank you very much.
[04:06] <spiv> Not a problem.
[04:16] <spiv> rubbs: oh, I almost forgot: please fill out the contributor agreement: <http://www.canonical.com/contributors>.  I don't remember if it's a requirement for docs rather than code, but if you don't object then it's probably simplest.
[04:33] <lifeless> spiv: to check if ~FOO has signed, are you started at ~FOO and their groups, or at the group we care about?
[04:38] <spiv> lifeless: I look at ~FOO and check their groups, but I also check the wiki page
[04:44] <mkanat> mwhudson: I have the parser, now it's just a matter of output and what we do with the parsed input.
[04:45] <mwhudson> mkanat: cool
[04:46] <mwhudson> mkanat: well, how about "what state are all the threads in when codebrowse was restarted" ?
[04:46] <mkanat> mwhudson: Yeah, that can be done.
[05:14] <mkanat> mwhudson: Here's the fully-parsed log that you sent me: http://pastebin.ubuntu.com/322153/
[05:14] <mkanat> mwhudson: It doesn't include lines that don't involve some sort of action.
[05:15] <mkanat> mwhudson: It lists threads in reverse time order, but then the actions within the threads in forward time order.
[05:16] <mkanat> mwhudson: I did it all by creating objects, so changing the output format should be pretty easy.
[05:17] <mwhudson> mkanat: cool
[05:17] <mwhudson> mkanat: my brain has stopped working for the day, btw :)
[05:17] <mkanat> mwhudson: Hahahaha, no problem.
[05:18] <mkanat> mwhudson: It seems to at least possibly hold up your theory. You can see that a lot of threads built a revision graph cache as one of their last actions.
[05:19] <mkanat> mwhudson: Though I suppose those completed, so that doesn't help. :-)
[05:19] <mwhudson> mkanat: yeah
[05:23] <mkanat> mwhudson: Code's here: bzr://bzr.everythingsolved.com/loggerparse/trunk FWIW.
[05:24] <mwhudson> cool
[05:24] <mwhudson> i'll look tomorrow :)
[05:24]  * mwhudson runs away from the computer
[05:24] <mkanat> Okay.
[05:24] <mkanat> LOL
[05:24] <spm> night mwhudson!
[05:24] <mkanat> Night mwhudson. :-)
[05:41] <distatica> Hey folks, I've been working on a little problem for a bit now, could use some advice. When I redirect from one of my controllers I get the error that headers are sent. I've checked now for whitespace and debug statements and have solved those. I am using Searchable Behavior, and I have various models to be searched (LocalListing, Classified, etc)
[05:41] <distatica> I have one search controller with one action (currently) to handle the request. If the $type and $query vars (and corresponding post vars) are empty I redirect to /search/ this is where my error occurs. I have narrowed this as close as var $uses = array('LocalListing') located in my search controller. I understand that I should include my controllers model name in that array, however I don't have one.  Commenting out this statement fixes things (e
[05:42] <jelmer> distatica: Are you sure this is the right channel?
[05:42] <distatica> It should be noted, when debug=0 the problems disappear.
[05:43] <distatica> oh goodness
[05:43] <distatica> sorry
[05:43] <jelmer> no worries :-)
[05:47] <JohnAlbin> Besides lp, are there any publicly-available bzr hosting solutions?
[05:48] <jelmer> JohnAlbin, sourceforge does, and I believe savannah as well
[05:48] <distatica> bzr hosting? like launchpad?
[05:49] <jelmer> JohnAlbin, and anything that support sftp/ftp can be used (although a bit slower than the smart server)
[05:49] <Kamping_Kaiser> depends what 'like launchpad'
[05:49] <Kamping_Kaiser> means
[05:50] <distatica> I wasn't really sure, I thought John was looking for a place to host bzr projects. I use sftp+redmine as well, and that works on many web hosts.
[05:50] <distatica> oh geez
[05:51] <distatica> I completely missed the lp, I'm on a role. :/
[05:51] <distatica> thought it was a nick
[05:52]  * JohnAlbin is googling savannah and redmine, atm.
[05:52] <JohnAlbin> thanks!
[05:53] <distatica> redmine you have to run though, it's not hosted. You need a web host that will let you do a little compiling and supports ruby
[05:54] <JohnAlbin> ah, ok.
[06:29] <mkanat> spm: Can I get more logs from around restarts?
[06:30] <mkanat> spm: It's hard to say that something is a pattern with just two logs. :-)
[06:30] <mkanat> But I see a few patterns.
[06:30] <spm> mkanat: heh. no worries. will do; what are you after; cause the others are possibly quite large?
[06:30] <mkanat> spm: Well, mostly I'd just like to see the last five minutes before the hang.
[06:31] <mkanat> s/crash/hang/
[06:31] <spm> oki; that's easy. will round up to nearest 10 I 'spect; easier on my aching regexified eyes
[06:31] <mkanat> That's fine.
[06:33] <spm> oki, gimme a few and I'll grep that for you
[06:34] <mkanat> Okay. :-)
[06:36] <mkanat> Also, wow, loggerhead is not coping with all the requests it's getting.
[06:36] <mkanat> DEB [20091118-05:42:40.758] [47447192702192] paste.httpserver.ThreadPool: Added task (14 tasks queued)
[06:37] <spm> harumph. file size == 0. messed something up....
[06:47] <mkanat> spm: If you'd rather have it crash than hang, there's a max_zombie_threads_before_die option for Paste that might help.
[06:48] <mwhudson> oh man, if you can belt paste into being a bit more sane that would also be good
[06:48] <mwhudson> (or suggest a better container)
[06:48] <mkanat> Yeah, there's also hung_thread_limit.
[06:49] <mwhudson> paste is really not expecting threads to be cpu bound though
[06:49] <mwhudson> and the default zombie_thread_timeout is like 1800 seconds
[06:49] <spm> crash/hang - all equally bad from our perspective. no real preference
[06:49] <mkanat> hung_thread_limit might help--it's supposed to be used to kill threads when they do a job for longer than X seconds.
[06:49] <mkanat> Though that would screw with building the revision graph.
[06:50] <mwhudson> mkanat: indeed
[06:50] <mwhudson> mkanat: we kill threads after 300 s
[06:50] <mwhudson> ~ish
[06:50] <mwhudson> 300s of inactivity
[06:51] <mkanat> A workaround for the hang might be to set hung_thread_limit to 300s.
[06:51] <mkanat> Although you might still get 300s hangs.
[06:51] <mwhudson> i think we do?
[06:52] <mkanat> [mkanat@es-compy loggerhead]$ grep -R hung_thread_limit *
[06:52] <mkanat> [mkanat@es-compy loggerhead]$
[06:52] <mwhudson> mkanat: not loggerhead
[06:52] <mwhudson> launchpad-loggerhead
[06:52] <mkanat> mwhudson: Ohh.
[06:52] <mwhudson> mkanat: and in fact we sometimes do recover from the hangs
[06:53] <mwhudson> mkanat: but far too slowly
[06:53] <spm> way too slowly
[06:53] <mkanat> Ahh, okay.
[06:53] <spm> and usually die "harder" within the next 30 mins or so fwiw. unscientific observation
[06:53] <mwhudson> mkanat: i had this vague idea that you could push off the revcache generation, not just caching to another process
[06:54] <mwhudson> then you could just kill threads after 30s and be fine with that
[06:54] <mkanat> mwhudson: That would be a good workaround, yeah.
[06:55] <mkanat> mwhudson: What's weird is that everything gets slow as soon as the revcache generation starts, and then it's all slow after that, even though they've been built.
[06:55] <mkanat> I'm mostly just musing aloud, I'm still investigating.
[06:55] <mwhudson> mkanat: hm
[06:56] <JohnAlbin> Hmm… looks like SourceForge is on 1.10. Guess I'll use lp. :-)
[06:57] <mkanat> mwhudson: It's only RevisionUI that builds the graph, right?
[06:57] <mwhudson> mkanat: no
[06:57] <mwhudson> basically any branch access will
[06:57] <mwhudson> mkanat: look at history,py
[07:00] <mkanat> mwhudson: Thanks.
[07:12]  * spiv is done for the day
[07:13] <spm> g'night spiv!
[07:22] <mkanat> What I really wish I could get is a traceback of every thread when it's hung.
[07:23] <spm> that... that's achievable. gdb attach dump goodness I assume?
[07:23] <mkanat> spm: Well, it's in Python, so it won't be quite the same.
[07:24] <mkanat> spm: Unless gdb can give me a python traceback. :-)
[07:24] <spm> mkanat: it can! mwhudson ^^  we use your magic .gdbinit on that one?
[07:25] <mkanat> spm: Really? Because that would save me all the trouble of log analysis.
[07:25] <spm> really? in that case, no we cna't. :-P
[07:25] <mwhudson> mkanat: http://pastebin.ubuntu.com/322211/
[07:25] <mkanat> spm: lol
[07:25] <mwhudson> stick this in .gdbinit
[07:26] <mwhudson> oh
[07:26] <mwhudson> or do you want this on prod?
[07:26] <mkanat> mwhudson: Yeah, on prod, when it's hung, before it's restarted.
[07:26] <mwhudson> spm: in your court i guess
[07:26] <mwhudson> all the bits are there i think
[07:27] <mkanat> The log analyzer unfortunately can't tell me which threads are actually still attempting to fulfill their requests and are just in a wait state during the hang.
[07:27] <mkanat> Because I can't tell the difference between "client gave up and went away" and "thread is waiting for data".
[07:28] <spm> mwhudson: wfm; lets try that then.
[07:28] <spm> mkanat: next batch of logs enoute anyway. fwiw.
[07:28] <mkanat> spm: Okay, cool.
[07:28] <mkanat> I'll see if I can make it hang locally.
[07:33] <spm> bbs
[07:37] <mkanat> spm: How do you know when there's been a hang? It seems like the restarts happen sometimes just seconds after the last request to the system.
[07:38] <spm> mkanat: 1stly we'll get a nagios check fail
[07:38] <spm> times out - from memory
[07:39] <spm> will try the thread-debug trick - see if that dumps anything useful
[07:39] <spm> often that also hangs tho
[07:39] <spm> try a local manual nagios check - 10secs limit - that time out == considered dead. restart.
[07:40] <mkanat> Hmm.
[07:40] <mkanat> Okay.
[07:40] <spm> is one of those... greatest good for greatest numbers cases.
[07:40]  * mkanat nods.
[07:40] <spm> it sucks for those whose sessions we just KO'd; but....
[07:42] <mkanat> So the hang itself likely happens long before you actually kill the process.
[07:43] <mkanat> It may in fact not even be hanging, just becoming really slow.
[07:43] <mkanat> I have a theory, even. If building the revision graph is really taking 4-5 minutes for each thread....
[07:43] <mkanat> And we get 5 busy threads building revision graphs, then paste won't spawn any more threads.
[07:43] <spm> sure. from our perspective the difference is ... not that significant tho
[07:44] <spm> hang vs slow as in
[07:53] <spm> mkanat: we got one! attaching now.
[07:53] <mkanat> spm: Awesome!!
[07:53] <spm> well.. no, but yes :-)
[07:55] <mkanat> Hahaha. :-)
[07:57] <spm> argh. what's the easy way to attach to a process; do the bt/pydump goodness without having to page all the time?
[07:57] <mkanat> Oh...
[07:57]  * mkanat tries to remember the command.
[07:57] <mkanat> spm: Maybe if your output isn't a terminal it just won't ask you to page at all?
[07:57] <spm> hrm. tricky....
[07:58] <spm> gargh; we're about to lose codehosting anyway - doing a h/w upgrade on it. 2 mins....
[08:00] <spm> mkanat: oki; my bad; I'll do some docco reading and be ready for the next one.
[08:00] <mkanat> spm: Agh, okay. :-)
[08:03] <spm> mkanat: max, may I make you known and introduce you to mthaddon, tom, he's another LOSA and normally starts around this time of the day/night/wherever
[08:03] <mkanat> Great. :-)
[08:03] <mkanat> Hey mthaddon.
[08:03] <mthaddon> o/
[08:06] <mwhudson> mkanat: btw re bug 156453 i think the problem is likely to be connected to the insane number of branches our loggerhead sees
[08:07] <mkanat> mwhudson: Could be, though I ran on a limited number of branches (five) and still saw a leak.
[08:07] <mkanat> mwhudson: If you see the leak faster than me, it could be that there is more than one leak.
[08:17] <BasicOSX> everything ok with LP?
[08:17] <BasicOSX> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch/branch.conf: Unable to handle http code 503: Service Temporarily Unavailable
[08:23] <spm> BasicOSX: ahh. I didn't update the topic here. my bad. Codehost is offline for a h/w update. ~ 4 hours unf.
[08:53] <RenatoSilva> where can I find info about bzr branch formats? google search just returns crap :P
[08:56] <bialix> RenatoSilva: what kind of info you need?
[08:59] <RenatoSilva> bialix: I-have-no-idea kind :)
[09:02] <bialix> cool
[09:20] <rogererens> I find the drawings in the Workflows chapter of the User Guide (command line) not as clear as they might be. Where can I give some feedback on the documentation?
[09:36] <dalin> oh that's why nothing works
[09:36] <LarstiQ> rogererens: launchpad is down for a hw upgrade atm, but the mailing list at https://launchpad.net/~bzr-doc would be a good bet
[09:38] <JohnAlbin> o_O
[09:38]  * JohnAlbin looks at the channel topic.
[09:38] <JohnAlbin> wait. is LP codehosting down right now?
[09:38] <LarstiQ> yes, the topic says so :p
[09:39] <JohnAlbin> I assume that's why I'm getting this error: "ssh: connect to host bazaar.launchpad.net port 22: Connection refused". bah.
[09:40] <LarstiQ> yes
[09:41]  * JohnAlbin starts watching http://twitter.com/launchpadstatus for updates
[09:43] <rogererens> LarstiQ: thanks!
[09:48] <RenatoSilva> why does everyone uses twitter
[09:48] <RenatoSilva> *use
[09:49] <mkanat> mwhudson: Okay, pretty much figured it out. No idea what to do about it yet, that's Phase 2. :-) Phase 1 was figuring out what the heck was going on, for sure.
[09:54] <mwhudson> mkanat: cool
[09:54] <mwhudson> mkanat: what is going on?
[09:54] <mkanat> mwhudson: You were pretty much right, except that it doesn't actually hang.
[09:54] <mwhudson> ok it's just severely degraded?
[09:54] <mkanat> mwhudson: Generating the revision graph for a very large branch simultaneously several times in various threads slows loggerhead to a crawl.
[09:54] <mkanat> Yeah.
[09:54] <mwhudson> mkanat: btw
[09:55] <mwhudson> mkanat: where are you?
[09:55] <mkanat> mwhudson: Mountain View.
[09:55] <mwhudson> i'm sure you should sleep at some point
[09:55]  * mkanat shrugs. :-)
[09:55] <mwhudson> oh not too insanely late i guess
[09:55] <mkanat> My girlfriend's still at work, I'd probably be waiting up for her anyway. :-)
[09:55] <mwhudson> time for me to zzz anyway
[09:56] <mkanat> mwhudson: Anyhow I suspect that just opening a few revisions on a launchpad branch that hasn't been graphed yet will cause it.
[09:56] <mkanat> launchpad itself, bzr itself, mysql -- those seem to be the only ones large enough to cause it.
[09:56] <mkanat> I'll send off an email about it to you and Francis.
[09:56] <mwhudson> thanks, sounds like a good result for day 1
[10:09] <RenatoSilva> bialix: can't find anything about branch formats in bzr docs
[10:13] <bialix> RenatoSilva: bzr help formats ?
[10:14]  * bialix still does not understand what RenatoSilva looking for
[10:14] <bialix> RenatoSilva: what you looking for?
[10:15] <bialix> definition of formats?
[10:15] <bialix> or understanding what's under the hood?
[10:16] <mkanat> mwhudson: Welcome. :-)
[10:19] <RenatoSilva> bialix: I am just one that has no idea about it and is curious about all those weird format specs
[10:20] <RenatoSilva> bialix: bzr help formats tells about rich-root but does not explain or points the user to somewhere else
[10:20] <bialix> bzr help current-formats
[10:20] <RenatoSilva> bialix: in general, it just says 2a ig good and you should be using it, it's not new to me
[10:20] <bialix> bzr help other-fromats
[10:20] <RenatoSilva> bialix: I have run bzr help current-formats already
[10:21] <bialix> RenatoSilva: bzr core devs think that understanding of deeper internals is not for mere mortals
[10:21] <RenatoSilva> bialix: I'm still reading it but it doesn't seem to include any explanation of what is rich-root
[10:21] <bialix> so there is no detailed spec on repo format
[10:21] <bialix> compare to git where you need to understand all internals first you even start using it
[10:21] <RenatoSilva> bialix: the format names are out of order, if there should be any
[10:22] <bialix> rich-root is repository format variant which store unique id for root of your tree
[10:22] <bialix> RenatoSilva: open .bzr/checkout/dirstate file and look at it
[10:22] <RenatoSilva> bialix: e.g are B+trees in 1.9 an improvement (included by all further formats), or an specific feature of that format?
[10:23] <bialix> RenatoSilva: in bzr you need to remember that there is 3 different beasts: branch, repository and working tree
[10:23] <bialix> that's complicate understanding a lot
[10:23] <bialix> rich-root is the "feature" of repository
[10:24] <bialix> RenatoSilva: if you really want to understand all gory details you need to deep into .bzr/ directory, inspect files there and then try to read the code which handles it
[10:25] <bialix> B+trees index introduced in 1.9, yes
[10:25] <bialix> it may be using in all later formats, e.g. 2a
[10:25] <RenatoSilva> bialix: ok I just suggest to order help current-formats
[10:26] <bialix> they are sorted for me
[10:26] <RenatoSilva> bialix: ok, so each entry in the help explains improvements for later use, not specific features (it's not a format shop, it's a log)
[10:26] <bialix> it's format zoo, not format shop
[10:27] <bialix> you may call it a log
[10:27] <bialix> does not really matter
[10:27] <RenatoSilva> I mean, I thought it was a menu showing each format, so that you choose which one fits your needs with their special features, but it's clear now
[10:28] <RenatoSilva> bialix: sorry it's ordered, except 2a is displayed 1st
[10:29] <bialix> RenatoSilva: http://pastebin.com/d78d7b288
[10:29] <lifeless> RenatoSilva: 2a is the one you should use
[10:29] <RenatoSilva> bialix: in the first place that's what I wanted, and overview of the current formats etc
[10:29] <bialix> RenatoSilva: there was decision helper from lifeless: use either default format or what your upstream use. if you're using bzr-svn -- use rich-root
[10:30] <bialix> lifeless: I have big doubts
[10:30] <RenatoSilva> bialix: I just thought I would find it in the docs, not bzr help
[10:30] <RenatoSilva> bialix: so, thanks :)
[10:30] <bialix> most docs generated from help
[10:30] <lifeless> bialix: about 2a? I saw your comment about merge, but thats a working tree thing, not repository layer
[10:30] <bialix> it seems these topics are not found their way to docs yet
[10:30] <bialix> lifeless: wt thing?
[10:31] <lifeless> the same id for '' issue
[10:31] <lifeless> sorry, different id for ''
[10:31] <bialix> Bug 484706?
[10:32] <RenatoSilva> bialix: about your paste, I see 2a in the top, and yours is missing it
[10:32] <lifeless> yeah
[10:32] <bialix> RenatoSilva: this is from bzr 2.1.0b3
[10:32] <RenatoSilva> bialix: which removed 2a from the help?
[10:32] <bialix> RenatoSilva: lol
[10:32] <bialix> I dunno
[10:33] <bialix> 2a listed as default
[10:33] <bialix> but yes it hould be there
[10:33] <bialix> but yes it should be there
[10:33] <bialix> time for filing a bug?
[10:34] <bialix> ghaa! 2a now listed in other-formats
[10:34] <RenatoSilva> bialix: 2.0.2: http://pastie.org/705698.txt
[10:34] <bialix> I think it's a bug
[10:34] <bialix> lifeless: does 2a will not default format in 2.1?
[10:34] <RenatoSilva> even if not default (o.O), I think it should be there
[10:34] <lifeless> bialix: I don't think we'll change the default for a while now
[10:35] <lifeless> bialix: so 2a should still be the default
[10:35] <lifeless> bialix: do you have a plugin that changes the default perhaps/
[10:35] <lifeless> ?
[10:35] <bialix> RenatoSilva: please, file a bug about this topics?
[10:35] <bialix> oh
[10:35] <bialix> yes
[10:35] <bialix> I am
[10:35] <bialix> sorry guys
[10:35] <bialix> my bad
[10:36] <RenatoSilva> that plugin also removes the 2a text?
[10:36] <lifeless> its a side effect
[10:36] <lifeless> current-formats is dynamic
[10:36] <bialix> cool
[10:36] <RenatoSilva> why would it remove it, for what reason
[10:37] <RenatoSilva> just because it is not default? but none of them are default except one of course
[10:37] <bialix> RenatoSilva: I have plugin format1 which forces usgae of pack-0.92 as default format
[10:37] <RenatoSilva> and they're all listed there
[10:37] <bialix> RenatoSilva: I have plugin format1 which forces usage of pack-0.92 as default format
[10:37] <RenatoSilva> bialix: 0.92 is a very old format I suppose
[10:37] <bialix> yes, but I need it
[10:37] <bialix> for my work
[10:38] <bialix> some our machines have installed bzr 1.2
[10:38] <RenatoSilva> bialix: but the plugin should not remove the 2a text, should it?
[10:38] <RenatoSilva> bialix: 1.2 oohh
[10:38] <bialix> RenatoSilva: no, plugin does not working with help text, but the text itslef generated dynamically
[10:38] <RenatoSilva> bialix: is it you that sends some msgs twice, or is your irc client? :)
[10:38] <bialix> so there is some side effects
[10:39] <bialix> it's me
[10:39] <RenatoSilva> bialix: so it it a bug or not?
[10:39] <bialix> no
[10:39] <bialix> it's not bug in bzr
[10:39] <RenatoSilva> *is it, ok so cancel my report
[10:39] <bialix> at least it's not worth to file it.
[10:39] <RenatoSilva> imho it is a bug, but ok
[10:39] <bialix> resolution on this bug would be: bialix is dumb
[10:40] <bialix> it's bug from plugin, so maybe I should fix it in my plugin
[10:40] <RenatoSilva> ah ok
[10:41]  * RenatoSilva is curious about checking what formats his local branches are using
[10:41] <RenatoSilva> bzr format is not a command :(
[10:41] <RenatoSilva> bzr info maybe, lmt
[10:42] <RenatoSilva> oh, why is it 0.92 here too?
[10:42] <bialix> branches not auto-magically upgraded
[10:42] <RenatoSilva> I have other one here 'unnamed' o.O
[10:42] <bialix> you have to upgrade each branch manually
[10:42] <bialix> bzr info -v
[10:43] <bialix> unnnamed -- means a mix of different fomats of branch/repo and wt
[10:43] <RenatoSilva> bialix: but 0.92 sounds like I created the branch in the time of bzr 0.92 (?)
[10:43] <bialix> 0.92 was default format until bzr 2.0
[10:43] <RenatoSilva> why?
[10:43] <bialix> so any branch created by default in this format
[10:44] <bialix> why? what whay?
[10:44] <bialix> why it was default?
[10:44] <bialix> maybe for backward-compatibility reasons
[10:45] <RenatoSilva> oh I see, and it's fine to break it in big releases (2.x), nice :)
[10:45] <bialix> yep
[10:46] <bialix> furthermore it's backward-incompatible break
[10:46] <RenatoSilva> bzr info -v: Format:  control: Meta directory format 1, working tree: Working tree format 6, branch: Branch format 7, repository: Packs 6 (uses btree indexes, requires bzr 1.9)
[10:46] <bialix> once you upgrade to rich-root (2a) you can't go back to poor-roots
[10:46] <RenatoSilva> is there any rich-root explanations for dummies? :)
[10:47] <bialix> lol
[10:47] <RenatoSilva> bialix: about bz info, can't get format 1,2, 3,4...
[10:47] <bialix> RenatoSilva: most likely you have 2a branch ion shared repo which is 1.9
[10:48] <bialix> or something like that
[10:48] <RenatoSilva> I'd expect to see the format names displayed in help rather than ordinal specs
[10:49] <bialix> what is ordinal specs?
[10:50] <RenatoSilva> the names, format 1, 2, 3, 4
[10:50] <RenatoSilva> bialix: Format:  control: Meta directory format 1, working tree: Working tree format 6, branch: Branch format 7, repository: Packs 6 (uses btree indexes, requires bzr 1.9)
[10:51] <bialix> it's internal
[10:51] <bialix> they are internal names
[10:51] <bialix> formats like pack-0.92 or 2a is combine names
[10:51] <bialix> s/is/are/
[10:52] <bialix> because you have sum of 3 formats (Mets directory format 1 is not changed for years)
[10:54] <RenatoSilva> bialix: in LP there's a section in the branch "Repository format:  Packs 6 (uses btree indexes, requires bzr 1.9)"
[10:54] <bialix> it's eq to 1.9 format
[10:55] <RenatoSilva> wouldn't one be interested in the "storage formats" like displayed in bzr help current-formats?
[10:55] <RenatoSilva> rather that this specific internal info?
[10:56] <bialix> heh
[10:57] <bialix> this is question not to me
[10:57] <bialix> the strings you see are hardcoded now forever
[10:57] <bialix> you can see them in .bzr/branch/format
[10:57] <bialix> .bzr/repository/format
[10:57] <bialix> .bzr/checkout/format
[10:58] <bialix> rhey are identify of specific format
[10:58] <RenatoSilva> I mean in LP
[10:58] <bialix> well, I dunno
[10:59]  * bialix -> lunch
[11:00] <RenatoSilva> thanks for help bialix
[11:09] <RenatoSilva> lp-users-editable bzr wiki is recent?
[11:17] <gioele> hello
[11:19] <gioele> I proposed to merge a branch of mine into bzr. I got some comments, changed the code and pushed the updated branch. What should I do now to make to tell the reviewers (and launchpad) that I updated the branch?
[11:20] <RenatoSilva> I'd resubmit the merge proposal and/or subscribe the reviewers to the branch (try also #launchpad)
[11:23] <Glenjamin> hi guys, i'm getting a bunch of NoSuchRevision exceptions when trying to diff local trees which are checkouts from an SVN repository
[11:24] <Glenjamin> is there any way to resolve these, or failing that just remove all the Bzr metadata from the SVN repo and start afresh
[11:28] <salgado> lifeless, still around?
[11:36] <boogiepets> hi all
[11:36] <boogiepets> i have a question on bazaar explorer
[11:37] <boogiepets> when i hit the "Commit" button on the toolbar
[11:38] <boogiepets> the "Commit" window pops up
[11:38] <boogiepets> which is "always on top"
[11:38] <boogiepets> why is that?
[11:38] <boogiepets> i am used to inspecting the diff while i am preparing to commit
[11:39] <boogiepets> in order to write details about the commit in the "Message" area
[11:39] <boogiepets> with the "Commit" window always on top i have to scroll it in order to see the diff window which is rather annoying
[11:40] <boogiepets> anyone willing to help?
[11:40] <boogiepets> is there any way to change this behaviour?
[11:40] <bialix> boogiepets: there is diff button in commit window
[11:41] <bialix> boogiepets: are you using explorer + bzr-gtk
[11:41] <bialix> ?
[11:41] <boogiepets> yes, exactly
[11:41] <bialix> sorry, I dunno then
[11:41] <bialix> are you mysqler?
[11:42] <boogiepets> nope
[11:42] <boogiepets> the "Diff" button is indeed there
[11:42] <bialix> then install qbzr and use it as your gui widgets for explorer
[11:42] <boogiepets> but when i press it, the diff window pops behind the commit window
[11:43] <bialix> hmm
[11:43] <bialix> we have one bug report in qbzr about such weird behavior
[11:43] <boogiepets> hmmmm, okay i'll try qbzr although i was getting quite fond with bazaar explorer
[11:43] <bialix> there is still no understanding what's going on
[11:43] <boogiepets> exactly the same thing?
[11:44] <boogiepets> commit window "alwasy on top"?
[11:44] <bialix> boogiepets: explorer will use qbzr widgets
[11:44] <bialix> lemme find bug report
[11:44] <boogiepets> soorrrrry
[11:44] <boogiepets> just a mo
[11:44] <boogiepets> i am using nautilus and bzr-gtk
[11:44] <boogiepets> i am in Ubuntu 9.04 environment
[11:45] <bialix> boogiepets: in Explorer: Tools -> Options and then select Suite -> qbzr
[11:46] <bialix> bug 421039
[11:46] <bialix> boogiepets: ^
[11:47] <bialix> check if you encounter the same bug, please
[11:47] <bialix> add the comments there about your system and library versions'
[11:47] <boogiepets> OK, for me that was "Edit -> Preferences"
[11:47] <boogiepets> and qbzr was already selected
[11:47] <bialix> will be nice if Gary can figure out what's the problem
[11:48] <boogiepets> i see that gtk provides a different window on commit
[11:48] <bialix> boogiepets: ok, so you're using qbzr in fact
[11:48] <boogiepets> but i like the qbzr one more
[11:48] <boogiepets> yes correct
[11:48] <bialix> yes, bzr-gtk and qbzr are 2 different plugins
[11:48] <boogiepets> allright, installing the various things got me confused
[11:49] <boogiepets> so i am using qbzr at the "Suite" option
[11:49] <boogiepets> i'll check the bug report now
[11:49] <bialix> ok, bbl
[12:04] <boogiepets> ok, posted comment on launchpad
[12:04] <boogiepets> would really like to see this fixed
[12:04] <boogiepets> thanks bialix
[12:04] <boogiepets> see ya
[12:54] <NET||abuse> hey guys.
[12:54] <NET||abuse> i'm trying to use bzr as a way of keeping graphics work, collections of photos that people drop onto a public samba share, in sync with my local copy on my windows graphics station.
[12:55] <NET||abuse> i've just added 34 meg of stuff to the repo, and syncing up to the public shrae, which i'll trigger an update on when it's finished so the files on the public share are synced.
[12:55] <NET||abuse> the problem is that it takes FOREVER!
[12:55] <NET||abuse> 34 megs will transfer on our network in under a minute.
[12:56] <LarstiQ> NET||abuse: how long is forever?
[12:56] <NET||abuse> I've been waiting a good 10 minutes at this point.
[12:56] <LarstiQ> NET||abuse: and what version of bzr, and what transports?
[12:56] <NET||abuse> and i'ts only 36% in Build phase: Adding file contents
[12:57] <NET||abuse> on windows bzr 1.18.1
[12:57] <NET||abuse> transports? network shares, smb
[12:57] <NET||abuse> is that what you mean?
[12:57] <LarstiQ> NET||abuse: hmm, I guess that gives me enough info
[12:57]  * LarstiQ was after sftp://, bzr+ssh:// etc
[12:58] <LarstiQ> in `bzr push bzr+ssh://host/path/`
[12:58] <NET||abuse> it's a dapper drake ahh :)
[12:58] <LarstiQ> but it seems you're treating it as a local filesystem
[12:58] <LarstiQ> which will mean it creates a workingtree
[12:58] <NET||abuse> in windows it's bzr push P:\graphicdesign\sitedesign\
[12:58] <NET||abuse> though i'm using hte tortoisebzr interface right now :)
[12:59] <LarstiQ> ok
[12:59] <LarstiQ> NET||abuse: what format is it in? `bzr info` will tell you
[13:00] <NET||abuse> standalone tree (format: pack-0.92)
[13:00] <LarstiQ> NET||abuse: ok, you might want to try 2a
[13:00] <LarstiQ> NET||abuse: and if you don't need the working tree, getting rid of that will help a lot
[13:01] <NET||abuse> well, the idea is that other people on the network can drop files into the network share, which is a working copy, then on the share working copy, i just do a nightly bzr add, bzr commit and then on my local copy, i do a bzr pull
[13:02] <NET||abuse> or bzr add; bzr commit; bzr merge; bzr commit; bzr push
[13:02] <LarstiQ> NET||abuse: ok, so you absolutely need the working tree then
[13:02] <NET||abuse> and one final bzr up on the share again .
[13:02] <LarstiQ> NET||abuse: are you the only one who interacts with it via bzr?
[13:02] <NET||abuse> yeh. it's to keep stuff on my graphic design station in sync with what's on that share, so other pople have access to what i've produced
[13:02] <NET||abuse> at the moment yeh.
[13:02] <LarstiQ> ok
[13:02] <NET||abuse> i'm the only bzr user.
[13:03] <NET||abuse> i just check for new stuff being dropped in periodically.
[13:03] <LarstiQ> NET||abuse: then please try `bzr upgrade --2a` and see what the effect is of that
[13:03] <LarstiQ> if it's still slow, why needs figuring out
[13:04] <NET||abuse> hehe, i seem to have accidentally duplicated my directories.. haha,, i had p:\garphicdesign\sitename.com  then i did bzr push with the tortoisebzr gui, and it pushed to p:\graphicdesign\graphicwork\   which created a new branch, that's weird...
[13:05] <NET||abuse> LarstiQ, that would be more of a reason it took so long, it actually branched the whole repo of 1.43GB, not just the 34MB of new images i added.
[13:05] <NET||abuse> i just didn't realise it was doing that.
[13:05] <NET||abuse> still,, what's the advantage of the 2a version?
[13:05] <NET||abuse> is it just hte archiving schema? what does it do better?
[13:09] <LarstiQ> NET||abuse: the important part here being a more efficient storage, let me look up the link
[13:09] <NET||abuse> hmm, cool. ok.
[13:10] <NET||abuse> why does it not create that format by default? is my bzr version on windows just too old?
[13:10] <LarstiQ> it creates it by default from bzr version 2.0.0
[13:12] <NET||abuse> ah,, but my windows bzr install is only bzr 1.18.1
[13:12] <LarstiQ> http://bazaar-vcs.org/Benchmarks?highlight=%28benchmark%29 is what I was thinking of iirc
[13:12] <LarstiQ> NET||abuse: right, but 1.18 can read and write 2a
[13:13] <LarstiQ> but it hadn't been made the default yet
[13:13] <LarstiQ> so when the switch was made, there were a couple of older clients that could handle the format too
[13:13] <NET||abuse> ahh, ok
[13:14] <NET||abuse> might see if i can get a 2.x client version for my windows box then.
[13:14] <NET||abuse> my linux laptop is ubuntu karmic, which is packaged with 2.0.1 , is that the most recent stable?
[13:14] <LarstiQ> NET||abuse: it is right now, 2.0.2 is on it's way to release
[13:15] <NET||abuse> cool.
[13:15] <NET||abuse> have to say, it's getting better than when i first used it.
[13:15] <NET||abuse> or at least i'm getting more comfortable with it..
[13:15] <LarstiQ> that's the idea with software development ;)
[13:15] <NET||abuse> switching from svn is tricky :)
[13:16] <NET||abuse> in terms of changing your mindset on how things should work.
[13:16]  * LarstiQ nods
[13:16] <NET||abuse> i use bzr mostly for my personal projects now, in work we are still svn centric, the main projects are svn + trac versioned.
[13:16] <NET||abuse> have to say, svn is good in that your certain it's going to work.
[13:17] <NET||abuse> i've had a few bugs during bzr usage, but mostly they're solved with things like updated repo formats, or i just ask someone in here :)
[13:18] <LarstiQ> svns maturity (and thus 3rd party support) is certainly a feature
[13:19] <NET||abuse> aha,,, i imagine bzr or git will probably make it's way to primary use in our office soon.
[13:20] <NET||abuse> right, i need lunch :)
[13:21] <NET||abuse> oh, one more thing, i need a good workflow for managing web dev projects, i design sites and code php or python,
[13:21] <NET||abuse> at the moment i develop locally, tracking in bzr, then push the branch up to a working copy on my server, then update the working copy on the server and just cp -rf ./dir1 /var/vhosts/sitexyz/
[13:22] <NET||abuse> for each directory of stuff that needs copying..
[13:22] <RenatoSilva> how to extend bug tracker support for commit --fixes?
[13:22] <NET||abuse> i'm wondering about a better deployment management strategy.
[13:22] <LarstiQ> NET||abuse: I'd use bzr-upload
[13:23] <LarstiQ> NET||abuse: http://bazaar-vcs.org/BazaarForWebDevs http://bazaar-vcs.org/BazaarUploadForWebDev
[13:23] <RenatoSilva> how to extend bug tracker support for commit --fixes? can I define new prefixes? like bzr bugs fb=http://foo.bar
[13:24] <LarstiQ> RenatoSilva: yes, see `bzr help bugs`
[13:31] <RenatoSilva> thanks!
[13:36] <RenatoSilva> but why bugzilla_squid_url = http://www.squid-cache.org/bugs
[13:36] <RenatoSilva> why not be free to create a template like
[13:37] <RenatoSilva> bugs_prefix = http://www.anyone.org/this_work/this_way?bug_id=%s
[13:38] <RenatoSilva> so that you bzr commit --fixes=prefix:123
[13:38] <LarstiQ> RenatoSilva: as `bzr help bugs` says, you can do that with bugtracker_prefix_url = http://www.anyone.org/this_work/this_way?bug_id={id}
[13:40] <RenatoSilva> LarstiQ: oh! didn't read it all after this part: "If your bug tracker can't be described by one of the schemes described below then you can write a plugin to support it."
[13:41] <LarstiQ> RenatoSilva: the sentence before that: along with a template mechanism for other bugtrackers with simple URL schemes.
[13:42] <LarstiQ> RenatoSilva: maybe that should be "this will cover most bugtrackers"?
[13:42] <RenatoSilva> why would not that template mechanish doesn't work with some bug tracker?
[13:43] <RenatoSilva> s/mechanish doesn't work /mechanism work
[13:43] <LarstiQ> RenatoSilva: because some are convoluted and you can't just plug in a bug number
[13:44] <RenatoSilva> ah. Do you know one?
[13:45] <LarstiQ> RenatoSilva: not off the top of my head, I may have repressed knowledge of such a beast
[13:51] <maxb> Hrm, didn't qbzr display branch nicks before the most recent version?
[13:55] <maxb> the truncation of branch names in the tree is also less than welcome
[14:07] <maxb> Hm, the branch nicks were lost in a refactor merged yesterday
[14:11] <MvG> Hi! I've got a thing here that feels like a bug, but I'd like your opinion on it. It's about file system encoding.
[14:13] <MvG> I'm running trac-bzr as a fcgi process, and it seems that locale information (LC_CTYPE in particular) don't get passed along. So python has no reliable clue about the current filesystem encoding, i.e. sys.getfilesystemencoding() doesn't give the 'UTF-8' it should. Not bzr's fault so far.
[14:14] <MvG> Now when bzr does list directories, e.g. in transport.local.list_dir, the os.listdir tries to convert byte strings to unicode, but fails on non-ascii chars. For these names, it returns raw 8-bit strings. list_dir applies url escaping to these, and the end result is a bunch of url-escaped utf-8 names. Fine so far.
[14:16] <MvG> Trouble starts when I use one of these names to e.g. clone a transport for a subdir and listing that subdir. In that case, the url gets decoded to a unicode name using utf-8, resulöting in the correct unicode name. Feeding that name to os.listdir causes a UnicodeEncodeError, as the name isn't ascii, and python doesn't know how to convert it to ascii.
[14:17] <MvG> So I wonder, shouldn't the url given for a local repository on a byte-oriented filesystem (i.e. *nix) be byte-oriented as well, instead of unicode-oriented?
[14:18] <MvG> There is a simple correspondence between 8-bit decoded urls and 8-bit filesystem names. And any name returned by the python os module can be easily reverted to its 8-bit form using sys.getfilesystemencoding().
[14:18] <MvG> What do you think? Bug? Feature request? Or simple misconfiguration, as python should know the file system encoding?
[14:54] <MvG> Out of curiosity: is there some document anywhere about how to set up bzr access over ssh in a safe and secure way? Like http://svnbook.red-bean.com/en/1.4/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth for ssh? What's e.g. launchpad doing to keep people from writing all over their system? Custom in-house plugins, or something available to the public?
[14:57] <MvG> Is "bzr serve --directory=/some/dir" guaranteed to restrict access to said directory?
[15:03] <bialix> maxb: hello
[15:03] <maxb> hello
[15:04] <bialix> can you elaborate on "the truncation of branch names in the tree is also less than welcome"?
[15:04] <bialix> maxb: can you test my fix for Bug 485133
[15:04] <bialix> ?
[15:05] <maxb> 1: I'd rather see my long branch names in full, even if they are long
[15:05] <maxb> 2: I will try later, but I don't really know what I did to provoke it in the first place, so it may be difficult
[15:06] <bialix> maxb: I've added truncation long ago on 20 symbols
[15:06] <bialix> we can move this into config
[15:06] <maxb> Indeed, I have no idea why I only just noticed it
[15:06] <bialix> but I can suggest you where in the code you can change the limit
[15:06] <maxb> Also, it only seems to apply to branch names, not tag names, which is a bit inconsistent
[15:07] <bialix> about nick and tags and bugs: this is indeed regression from garyvdm
[15:07] <bialix> Gary!
[15:07] <bialix> yes, only branch names truncated, because I had evidence of 120 chars long nick
[15:08] <bialix> btw, this is branch nicks, not branch names
[15:08] <bialix> so you can do: bzr nick "my very very very very very very very long nick" and guess what happnes
[15:09] <bialix> maxb: you can change branch nick with `bzr nick` command
[15:09] <maxb> yes. But equally you can do: bzr tag my-very-very-very-very-very-very-very-very-very-very-long-tag
[15:10] <bialix> tags is psecial
[15:10] <bialix> sorry
[15:10] <LeoNerd> Surely a certain amount of "you're doing it wrong" applies if you need names -that- long..?
[15:10] <bialix> tags is special
[15:11] <bialix> maxb: truncation done in loggraphprovider.py around line 367
[15:11] <bialix>                 tag = bi.branch.nick
[15:11] <bialix>                 if len(tag) > 20:
[15:11] <bialix>                     tag = tag[:20]+'...'
[15:12] <maxb> LeoNerd: Arguably there's a certain amount of "you're doing it wrong" if you're using CVS, but we are :-)
[15:12] <bialix> but yes, we're not very consistent here
[15:12] <LeoNerd> maxb: Oh.. is this for cvs->bzr branch conversion?
[15:12] <maxb> yup
[15:12] <LeoNerd> Heh.. :) Might have guessed...
[15:14] <bialix> maxb: really?
[15:14] <bialix> scary
[15:14] <maxb> Yes it is, that is why I am attempting to drag my team kicking and screaming out of the dark ages and to bzr
[15:18] <bialix> maxb: about truncation: I won't mind if you file this wish as bug report
[15:32] <jam> MvG: "bzr serve --directory=/foo/bar" does guarantee to not serve outside of /some/dir
[15:32] <bialix> hi jam
[15:32] <jam> jelmer: if you are around... "bzr branch lp:bzr-svn" still seems to be broken for me...
[15:32] <jam> hi bialix
[15:33] <jam> I don't know if you and mwh, et al sorted out a plan for fixing it?
[15:33] <MvG> jam: thx!
[15:34] <jelmer> jam: I'll have a look
[15:34] <jam> MvG: as for trac-bzr, it definitely needs to know the fs is utf-8
[15:34] <jam> I don't know how to tell it that, though.
[15:35] <MvG> jam: Found out, at least for my case: reconfigured my mod_fastcgi to set the LANG environment variable.
[15:35] <MvG> I guess it's not worth the effort to work around a possible misconfiguration on the bzr side.
[15:36] <jam> MvG: it is hard to do, because we are relying on the underlying python implementation for a lot of things
[15:36] <MvG> It would be possible, but probably would require case distinctions for different os.
[15:37] <MvG> Never mind, and thanks for your opinion.
[15:37] <jam> MvG: arguably it would be nice if python defaulted to UTF-8 as the fs rather than ASCII on platforms that didn't give other indications.
[15:38] <MvG> In some cases yes, in others no...
[15:38] <jam> jelmer: I'm not sure if you followed mwh's discussion of how it happened
[15:38] <jam> but basically, your dev focus used to be a mirrored branch
[15:38] <jam> so all your lp branches are stacked on it
[15:38] <MvG> Oh, and by the way, jam, thanks for approving my trac-bzr team membership!
[15:38] <jam> when you changed it to hosted, then the newly created branch got stacked elsewhere, and things got circular
[15:39] <jam> MvG: np, you've been doing a lot of work there anyway
[15:39] <MvG> jam: Do you know how the trac-bzr development usually works? Can I simply start triaging bugs or committing changes, or should there be some kind of review or similar?
[15:41] <jam> MvG: I think trac-bzr is pretty 'loose' in changes
[15:41] <jam> I don't know that anyone is actually maintaining trunk
[15:41] <jam> well, actively maintaining
[15:42] <MvG> In that case I'll start merging my minor fixes soon, and try to get some kind of review on my quoting branch once I've got my latest ideas coded...
[15:42] <MvG> There seems to be a team mailing list, but I couldn't find any messages in the archive. Is that because there were none, or is lp broken?
[15:43] <MvG> https://lists.launchpad.net/trac-bzr-team/
[15:44] <mzz> I really should remove myself from that team, it's not like I actually know the code anymore
[15:44] <jam> MvG: I believe it is because there were none
[15:46] <jam> mzz: I'm sure you know it better than *I* do :)
[15:46] <mzz> jam: you might be surprised!
[15:46] <jam> mzz: since I've never read it at all...
[15:47] <jam> at best we would be equal :)
[15:48] <mzz> I don't even remember if any code I wrote is in this incarnation of the plugin
[15:48] <bialix> oh! trac-bzr hackers here!
[15:49] <MvG> quote so.
[15:49] <mzz> MvG: good luck with your changes though. At the time I actually hacked on this getting trac to play ball was not fun.
[15:49] <mzz> (I'm hoping it has improved)
[15:50] <MvG> I'm only touching the most prominent issues so far.
[15:50] <MvG> Nothing seems impossible yet... ;-)
[15:51] <bialix> I'm still using old version of trac-bzr with trac 0.10.5
[15:51] <bialix> with bzrlib from bzr 1.5
[15:51] <bialix> then something becomes broken
[15:51] <bialix> I really hope that I can upgrade my trac setup soon
[15:52] <bialix> MvG: does new improvements to trac-bzr will require upgrade to trac 0.11?
[15:52] <MvG> mzz: but now that you mention it, get_previous is causing me trouble lately (https://bugs.launchpad.net/trac-bzr/+bug/484983) and as that code seems to be from you in large parts, do you think you can remember your intention there and explain it to me, so I can fix it properly?
[15:52] <mzz> well, I can try
[15:52] <MvG> bialix: good question. Don't have a trac 0.10 around, so I wonÄ't be able to test with 0.10, so I can make no guarantees...
[15:53] <MvG> do you consider 0.10 support important?
[15:53] <MvG> If so, it might be worth a branch...
[15:53] <gioele> MvG: Trac 0.10 is very widely deployed
[15:54] <MvG> Because I assume not all my changes will play nicely with 0.10. If I start fixing the Wiki macro (https://bugs.launchpad.net/trac-bzr/+bug/484640) using genshi, that's for sure.
[15:54] <mzz> MvG: I'm guessing that's incredibly evil code I wrote to hack around a performance problem, but let me read my changelog entries and see if I remember anything
[15:54] <bialix> I won't object to upgrade to 0.11 and support only it if it helps to make trac-bzr better
[15:54] <ubott2> Launchpad bug 484983 in trac-bzr "BzrDirNode.get_previous broken" [Undecided,New]
[15:55] <bialix> just in 2007 when I've installed it on my work it was difficult to use 0.11 on Windows
[15:55] <gioele> MvG: anyway, if the trac-bzr is not going to be released soon, maybe it makes more sense to concentrate on 0.11 only
[15:55] <ubott2> Launchpad bug 484640 in trac-bzr "Branches wiki macro is defunct" [Undecided,New]
[15:55] <MvG> gioele: Don't see a "release" soon. There are quite a number of open bugs, and judging from the fact that the ones I encountered weren't already reported for the most part, I assume there's a lot of work ahead.
[15:57] <gioele> MvG: go ahead and forget my remarks about 0.10.x ;)
[15:57] <MvG> But as there is such an active trac-bzr discussion here at the moment: how would you like this syntax for changesets: [branches,name,42] to refer to revno 42 or the branches/name branch? The key ingredient is the substitution of / by , as trac doesn't like slashes in revnos.
[16:00] <mzz> MvG: did you spot http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L50 ?
[16:01] <MvG> mzz: not yet.
[16:01] <mzz> MvG: it is likely trac changed substantially since I wrote that function and just removing it is now sane
[16:04] <mzz> MvG: I think I wrote that for two reasons (and it's actually doing two different things depending on how it gets called): to quickly get a reasonable "previous" link when browsing changesets, and to generally be faster than going through get_history by only loading a single changeset instead of the complete branch history
[16:05] <Adys> how do I show a diff from one specific rev to another?
[16:05] <mzz> but I'm still re-reading
[16:05] <mzz> Adys: bzr di -rfirstrev..secondrev
[16:05] <Adys> thanks
[16:08] <bialix> hello amanica_
[16:09] <mzz> MvG: after skimming get_history I suspect you're right and get_previous can just be killed, but do poke around a bit to make sure performance isn't stupid anywhere
[16:10] <MvG> mzz: It's the part about "avoiding get_history" for which I don't understand how it works, and which would affect performance.
[16:10] <MvG> Right now it does use get_history, I guess.
[16:11] <mzz> MvG: iirc if you just remove the function the default implementation calls get_history
[16:11] <amanica_> hi bialix
[16:11] <bialix> how are you?
[16:11] <amanica_> not bad thanks, almost recovered from flu
[16:11] <amanica_> you?
[16:12] <mzz> MvG: I think I wrote a specialized implementation mainly (perhaps exclusively) for performance reasons: bzr ended up doing something involving loading lots of trees that was slow, and I thought I could get away with loading a single known revision by id instead, which was much faster
[16:12] <bialix> amanica_: too much work, too little time for hacking
[16:12] <mzz> MvG: but that's years ago, get_history probably got smarter, and it's usually calling into a completely different bzr repository now
[16:12] <MvG> You mean different repo format?
[16:12] <mzz> MvG: so if removing get_previous works *and* performs reasonably, I'm pretty sure that's the right thing to do
[16:12] <amanica_> bialix: yup, me too. also trying to catch up to the bzr mailing list
[16:13] <mzz> MvG: yep
[16:13] <MvG> I'm not sure my setup is suitable to seriously test performance: I have only a limited number of commits, and quite a number of other factors influencing performance.
[16:14] <mzz> MvG: again, it's been *ages*, but I think the point was that there were a couple of trac webui pages that called get_previous to get something like a "previous changeset" link, while get_history was only called for pages like a log view page (that actually displays more than one log entry)
[16:14] <bialix> maxb: several of your reported bugs in qbzr just fixed. thanks for reports!
[16:15] <MvG> otoh I'm pretty sure your idea can't work: give a revid, to find the previous rev where that thing changed, you have to do one of two things:
[16:15] <MvG> either take the previous revision of the whole branch, find the last modified revisoon of every child, and take the latest of these,
[16:15] <MvG> or take preceeding revisions one after the other in reverse chronological order until you hit one that touches the dir in question or its content.
[16:15] <MvG> Both involve some kind of loop which I don't see in your implementation, but which might be faster than a full get_history.
[16:15] <mzz> MvG: so get_history ended up calling into a bzr api that efficiently extracts a lot of history (in batches) (which made the revision log page a lot faster) while get_previous avoided that.
[16:16] <mzz> MvG: but at that point I was much more interested in getting it fast than in making sure all links everywhere in the webui behaved consistently.
[16:16] <MvG> mzz: Still is that way, and the proken "Previous Chang" link is what got me started to investigate.
[16:16] <mzz> MvG: and since that time the entire thing got a lot smarter about caching etc (I think all of BranchCache was added later)
[16:17] <mzz> MvG: so if it performs acceptably on branches with a nontrivial amount of history you should just kill the function, I think.
[16:17] <MvG> OK, thanks mzz, I'll have another look now, with this info at the back of my head, and will see if I can work out a good fix or will simply drop the method.
[16:19] <mzz> MvG: just make sure you test on a nontrivial branch (few 100 revisions), if what I remember about this is correct that matters
[16:19] <mzz> well, mattered :)
[16:20] <mzz> MvG: and don't worry about "other factors affecting performance", this was an order of magnitude thing, anything less than that is not worth specializing get_previous for
[16:21] <mzz> it's *supposed* to do the same thing as get_history, anything else is me cheating
[16:22] <mzz> and now you've made me remember about http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L85 :(
[16:29] <MvG> mzz: I already made close aquaintance with that __del__ method: https://bugs.launchpad.net/trac-bzr/+bug/484324
[16:29] <mzz> MvG: yeah, I think I saw that one in my bug mail :(
[16:29] <MvG> I guess I should have a read through HACKING, see what it says and what might need updating when I commit stuff.
[16:31] <MvG> Had a close look at get_history. Looks like that's really what is needed, and in case the caller closes the generator after retrieving a single result, the performance impact shouldn't be too high.
[16:34] <mzz> MvG: at the time I wrote get_previous there *was* a noticable performance impact. But I suspect that's simply no longer the case (since someone who cared more about the revision log view than I did at that time optimized it, or I did it myself later)
[16:35] <MvG> mzz: Considering your useful input here, I'd hate to see you leave the team, as you stated somewhere up there.
[16:35] <mzz> MvG: as for the __del__ method: I wonder if you could create a (non-proxy) weakref every time you add a branch with a callback that closes that branch. Although I'm not sure where to store that weakref (on the branch would probably work, but that's ugly)
[16:36] <mzz> MvG: actually, I think you could give your LockedBranches a weakref callback (triggered by the BzrRepository owning it going away) that calls unlock instead of using __del__
[16:36] <MvG> I'm not sure I understood you correctly, but I fear this might cause branches to get collected while I still have use for them.
[16:37] <MvG> any benefit in the weakref callback over the del as I implemented it in LockedBranches?
[16:37] <mzz> MvG: it's not __del__ :) weakrefs don't break the cycle collector like __del__ does.
[16:38] <MvG> __del__ doesn't break a thing is it's not in a cycle. Therefore my new approach works.
[16:39] <mzz> MvG: the practical difference would be that LockedBranches.unlock gets called immediately once the owning BzrRepository goes away, independently of any other (cyclical) references LockedBranches is involved in.
[16:41] <mzz> MvG: so it seems a bit safer, since if anything manages to form a cycle involving LockedBranches you'll be back where you started if it uses __del__.
[16:41] <mzz> but hey, I added the original __del__, I can't complain no matter which way you go here :)
[16:42]  * MvG is reading up on weakref callbacks
[16:43] <mzz> they're easy. Sec, lemme branch
[16:44] <MvG> mzz: I guess what troubles me most is that the weakref on the repo object would /form/ a cycle, even as it's one with a weakref in it so it can be broken, and there shouldn't be a del method.
[16:45] <MvG> And I'm not sure if the callback gets executed if the object owning the weakref becomes collectable before.
[16:45] <MvG> I.e. whether my LockedBranches might get finalized without the callback being ever triggered.
[16:46] <MvG> Any objectsions to me updating the trac-bzr trunk repo to 2a format?
[16:46] <MvG> would allow stacked branches...
[16:47] <mzz> MvG: heh, only I can't test this because I don't have trac installed
[16:50] <Lo-lan-do> Hi all
[16:50] <mzz> MvG: weakrefs are always safer than __del__ as far as cycles goes. If LockedBranches gets finalized before its BzrRepository the weakref wouldn't get called back, but that can't happen unless someone screws with BzrRepository._locked_branches.
[16:51] <Lo-lan-do> jelmer: Ping? Would you have an hour or so in the coming days? I'd like to get bzr-git finished for git push, and I have the frustrating feeling we're *almost* there but not quite.
[16:51] <jelmer> Lo-lan-do, hi
[16:51] <jelmer> Lo-lan-do: Yeah
[16:51] <Lo-lan-do> :-)
[16:52] <MvG> mzz: Why can't that happen? After all, both become collectable at the same time.
[16:52] <Lo-lan-do> jelmer: When would it be convenient for you?
[16:53] <mzz> MvG: see lp:~marienz/trac-bzr/bug484324 (untested!)
[16:53] <jelmer> Lo-lan-do, now would be good I think
[16:54] <Lo-lan-do> Yay
[16:54] <mzz> MvG: the BzrRepository has a strong ref to its LockedBranches, so the LockedBranches refcount won't go to 0 before the BzrRepository
[16:55] <jelmer> Lo-lan-do: Is now good for you as well?
[16:55] <Lo-lan-do> jelmer: Sure. Shall we move to private?
[16:56] <jelmer> yeah
[16:56] <MvG> The BzrRepository refcount won't go to 0 "the normal way" either, because it's part of a cycle. Does the cycle collector really work with refcounts and all that? Or simply clean up all parts of a detected cycle and everything reachable only from it? And how about future python implementations?
[16:56] <MvG> I just don't feel safe here, it's relying a lot on implementation details.
[16:57] <MvG> At least feels that way to me, as I'm still relatively new to Python.
[16:58] <mzz> MvG: __del__ is just way scarier as far as implementation details goes than weakref is, because weakrefs don't get access to the object that just died.
[16:58] <MvG> I had the impression __del__ gets access just before the object dies.
[16:58] <MvG> Which is why __del__ causes trouble in cycles: Python refuses to break the cycle as long as any __del__ might rely on any part of it.
[16:59] <mzz> MvG: __del__ is capable of "reviving" the dying object, which makes it quite icky. If you can structure so you can use a weakref instead of __del__ that is normally preferable.
[16:59] <MvG> weakref is all right for me, but relying on the callback seems bad.
[16:59] <mzz> MvG: how so?
[17:00] <MvG> As I pointed out, I'm not confident the callback will get executed at all.
[17:00] <MvG> I see no spec clearly stating it will.
[17:00] <mzz> MvG: can you describe a way to make it not execute?
[17:00] <mzz> MvG: preferably one where __del__ *will* :)
[17:01] <MvG> Write my own python interpreter, and do so in such a way that the gc first collects all unreachable objects, then finalizes them all, keeping track of weakrefs, and then calls callbacks only if their owners are still alive...
[17:02] <MvG> I guess current standard python implementations don't behave this way, but unless it's specified that no python is allowed to behave this way, I don't feel safe.
[17:02] <MvG> I know __del__ is guaranteed to be called before the object gets collected, and that all outgoing references of the object will stay intact.
[17:03] <MvG> That's a clean and reliable promise, and one I can work with.
[17:03] <mzz> MvG: where are you seeing any guarantees that __del__ gets called that don't apply to weakrefs?
[17:03] <mzz> there are *very* few clean and reliable promises as far as __del__ is concerned.
[17:03] <mzz> "It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits"
[17:04] <mzz> also "Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), but can only be cleaned up if there are no Python-level __del__() methods involved"
[17:05] <MvG> OK, you made a point there.
[17:09] <MvG> mzz: I guess I have an idea that might make me feel safe as well: ensure that the object containing the weakref stays reachable until the callback gets executed.
[17:09] <MvG> Will code that later, gotta east something first...
[17:09] <mzz> MvG: you already have that. BzrRepository has a strong ref to LockedBranches.
[17:10] <MvG> But BzrRepository itself isn't reachable any more.
[17:10] <mzz> MvG: no, but that's the whole point.
[17:11] <mzz> MvG: let me turn that around. With your current code if LockedBranches manages to go away before the BzrRepository does your __del__ would run too early, so you'd also be broken.
[17:12] <MvG> So as BzrRepository isn't reachable, and it's the only one with a reference to LockedBranches, and as it doesn't have a __del__ method so it isn't expected to run any code, then I'm not sure I'd consider LockedBranches reachable.
[17:12] <MvG> No, only if the BzrRepository were to /use/ the branches later on.
[17:13] <MvG> So the order of finalization doesn't matter, as long as neither one is going to run any other code.
[17:13] <MvG> Gotta go, will be back later on...
[19:32] <ibrandt> Greetings All.  My company uses Bazaar internally, but we're going to be enhancing and contributing to a project that is otherwise versioned in Git.  The thinking is we'd produce numerous internal revisions in Bazaar, culminating in the occasional upstream patch.  I was wondering if anyone had any tips for this sort of a workflow?  Our current plan is to checkout a working copy of our project from our shared Bazaar repo, and then clone the Gi
[19:32] <ibrandt> project into a subfolder of that working copy.  Work the subfolder primarily with bzr, but upstream updates and such can fetched with git.  I'm not sure if we'd want to bzr add the .git repo, or bzr ignore it?
[19:33] <LarstiQ> ibrandt: or use bzr-git
[19:34]  * Tak agree
[19:36] <jam> ibrandt: http://bazaar-vcs.org/TrackingUpstream
[19:36] <jam> ibrandt: you may want to look at "Converting and ignoring history"
[19:37] <jam> it talks about cvs, but I imagine it would be about the same for git
[19:37] <ibrandt> Ah, okay.  Thanks!  I'll read up.
[19:40] <LarstiQ> ibrandt: and linked off from that, http://bazaar-vcs.org/BzrForeignBranches/Git
[19:45] <distatica> Anyone here run qbzr on debian lenny? I have backports; and the launchpad site in my sources.list, but when I try to install it says that I need python-central 0.6.11 but 0.6.8 is installed. I could just remove python-central and attempt to download and install 0.6.11 but this can lead to more problems; wonder if someone knows a better route to take.
[19:48] <jam> distatica: I would guess that the dependency isn't a strong one, but just whatever recipe was copied when they made the package
[20:04] <lifeless> moin
[20:07] <lifeless> jelmer: +1 to adding gagern to bzr-trac?
[20:09] <jelmer> lifeless: I think you mean trac-bzr :-) (bzr-trac is an unfriendly fork)
[20:09] <lifeless> $garh
[20:09] <jelmer> lifeless, no objections here, although I'm not really involved with trac-bzr anymore
[20:09] <lifeless> me neither
[20:09] <lifeless> but I figure two not involved people saying yes is better than noone saying no
[20:10] <jelmer> lifeless: I agree, I think it would be hard to find people actually involved atm
[20:10] <lifeless> MvG: hi
[20:11] <MvG> lifeless: hi as well!
[20:11] <MvG> Oh, you been talking about me! :-D
[20:11] <lifeless> MvG: yah
[20:12] <MvG> jam already approved my team mambership...
[20:12] <lifeless> just wanted to say that trac-bzr doesn't really have anyone caring about it in terms of 'maintainers'
[20:12] <lifeless> so don't block on reviews
[20:12] <lifeless> if you don't get a review for a branch in (say) 2 days, I think you should land it.
[20:13] <MvG> glad to hear that.
[20:13] <MvG> Should I request reviews over the launchpad merge request thingy?
[20:13] <lifeless> yup
[20:14] <MvG> gladly.
[20:14] <lifeless> hmm, lets see if trunk has any subscribers
[20:15] <MvG> I'm thinking about a branch for 0.10 compatibility. What do you say?
[20:15] <lifeless> hah, the owner isn't subscribed. \o/ thumper: <- when can we do this search and fix?
[20:16] <thumper> lifeless: I'll get back to you shortly?
[20:16] <lifeless> thumper: :P
[20:16] <lifeless> MvG: I have no opinion. I don't know where trac is at, lifecycle status, userbase that will want bzr for trac 0.10 etc
[20:16] <thumper> lifeless: a call
[20:17] <MvG> 0.10 is widely deployed, and 0.11 introduced some serious changes.
[20:17] <lifeless> MvG: https://code.edge.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges you might like to review the branches that are need review and not from you
[20:17] <MvG> good idea. but tomorrow - its getting late around here...
[20:18] <lifeless> MvG: no rush
[20:18] <lifeless> MvG: just saying :)
[20:18] <MvG> :-)
[20:19] <MvG> I guess I'll add a bunch of branches of my own tomorrow.
[20:19] <LarstiQ> MvG: considering the reality of trac deployment, I'd vote for a 0.10 branhc
[20:19] <LarstiQ> MvG: unless you keep trunk 0.10 compatible that is
[20:19] <LarstiQ> either works, whatever is least hassle
[20:20] <LarstiQ> MvG: and good night ;)
[20:20] <MvG> LarstiQ: Have no 0.10 here to test, and I believe that with respect to url quoting and stuff there might be a lot of changes, so I doubt I'll stay compatible.
[20:20] <MvG> Thus branch and backport as much as feasible, but no more.
[20:21]  * LarstiQ nods
[20:22] <distatica> jam: Sorry for the delayed response, helping my son do a puzzle. So how should I proceed then? I tried installing qbzr via the tar and sudo python setup.py install; however when I run bzr I get: Unable to load plugin 'qbzr' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
[20:22] <LarstiQ> MvG: I run a 0.10 trac, though not actively with bzr. If you ping me I can test though.
[20:22] <jam> distatica: can you run "bzr -Derror" so you can see what is failing?
[20:22] <jam> Like, do you have pyqt and other such dependencies installed?
[20:23] <distatica> Yeah, but I might be missing something I didn't notice.
[20:23] <distatica> or the wrong package was installed.
[20:23] <MvG> LarstiQ: Thanks for the offer. Will ghet back to it when I have two more commits or so in my quoting branch.
[20:23] <LarstiQ> MvG: k
[20:23] <jam> distatica: it could be version skew, depending on what version of bzr you have installed, too
[20:23] <distatica> however, when I run bzr -Derror it just prints the help, bzr -D error says error is a command not found
[20:24] <distatica> hmm
[20:24] <MvG> By the way, how would you deal with the questioon of backwards compatibility? If I change the revno format, do I still have to accept old IDs?
[20:25] <LarstiQ> distatica: no space between -D and error
[20:25] <Lo-lan-do> distatica: try "bzr -Derror qbzr", or howewer you're supposed to run qbzr
[20:26] <LarstiQ> MvG: in general I'd say yes, but that needs more thought for the specific change
[20:26]  * LarstiQ goes to bed
[20:27]  * MvG too
[20:27] <MvG> Thx!
[20:28] <distatica> hmm, that error just shows me that it's not starting, and that it fails when trying to call qbzr
[20:29] <amanica_> Lo-lan-do: with only qbzr you can run each command seperately, see http://bazaar-vcs.org/QBzr
[20:30] <Lo-lan-do> distatica: There's probably some log in .bazaar
[20:30] <distatica> one file, ignore
[20:33] <Lo-lan-do> Oh, it's ~/.bzr.log, sorry
[20:38] <hersonls> hi, where i found how export repo with python?
[20:39] <hersonls> the python api
[20:40] <amanica> hersonls: I think you can only export a branch at a time see: bzr help export
[20:40] <amanica> I think it would be nice to be able to export a repo though
[20:41] <hersonls> amanica, i need ceate a python script to export without bzr comand, understand?
[20:41] <amanica> aah ok
[20:41] <amanica> I may not be able to help now, mabe somebody else can
[20:42] <amanica> you can maybe look in builtins.py
[20:42] <amanica> there you can see how the "branches" command finds branches, and also check there how the "export" command exports them. hth
[20:43] <hersonls> amanica, ok
[20:44] <hersonls> amanica, i belived have documentation for this
[20:45] <jam> hersonls: define "export"
[20:45] <jam> do you want just the files on disk
[20:45] <jam> similar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"
[20:45] <jam> or are you asking to have the history?
[20:46] <jam> amanica: and 'bzr branches' is in bzrtools, not core (yet)
[20:46] <hersonls> similar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"
[20:46] <amanica> jam: whoops, I thought it made it into the core already
[20:47] <jam> hersonls: then you'll want to look at 'builtins.py' for the "cmd_export" code
[20:47] <jam> I think it is generally "Tree.export('path')" but I haven't looked in a long time.
[20:50] <hersonls> jam, amanica hey
[20:51] <hersonls> >>> from bzrlib import export :)
[20:51] <hersonls> export(tree, dest, format=None, root=None, subdir=None, filtered=False)
[20:51] <hersonls> tanks
[20:51] <amanica> cool
[20:52] <hersonls> amanica, tanks
[20:53] <amanica> np
[20:58] <mwhudson> is there a 2.1.0b3 release branch?
[20:59] <mwhudson> or just a tag on the 2.1 branch?
[20:59] <poolie> hello all
[20:59] <poolie> mwhudson: i think the plan is now that it's just tagged on the 2.1 branch
[20:59] <mwhudson> (i should probably know this already but well)
[20:59] <mwhudson> okidoke
[21:05] <jam> mwhudson: 2.1 branch
[21:05] <jam> at least, I'm trying it out
[21:06] <rogererens> Can .bzrignore files contain comment lines (in order to explain why some paths/files are ignored)?
[21:06] <mwhudson> jam: cool
[21:06] <jam> rogererens: with #
[21:06] <mwhudson> of course i remembered the odd push -r behaviour again...
[21:06] <jam> mwhudson: pushing something older than target does nothing?
[21:07] <mwhudson> jam: no much odder than that
[21:07] <mwhudson> jam: https://bugs.edge.launchpad.net/bzr/+bug/484516
[21:08] <jam> ah, yeah that's pretty strage
[21:08] <jam> strange
[21:08] <jam> I think afc argued that we should never update the wt w/ push
[21:08] <jam> as it was "inconsistent"...
[21:08] <jam> I don't ever use it
[21:08] <jam> as cd ../target ; bzr pull works just fine
[21:09] <mwhudson> i was using this to create a new branch at a tag
[21:09] <mwhudson> i guess bzr branch . ../target -r tag:whatever works too
[21:11] <jam> mwhudson: yeah, I think it is a bug and should certainly be fixed, just never run into it because I don't use 'push' to do that sort of thing
[21:12] <rogererens> jam: # to start a comment line; is it also possible to have inline comment? adding # to the end of line seems to wreck the regex
[21:12] <jam> rogererens: I think only a separate comment line
[21:12] <rogererens> jam: thx
[21:12] <jam> yeah, we have:
[21:12] <jam> if not line or line.startswith('#'):
[21:12] <jam>     continue
[21:13] <jam> but nothing about pulling a # comment out of the middle of the line
[21:15] <mwhudson> so if there isn't a 2.1.0b3 release branch, is there a 2.0.2 release branch?
[21:15] <jam> mwhudson: there is, but we're switching to just using a tag on the 2.0 branch when 2.0.3 comes out
[21:16] <jam> well, I guess *I*'ll be switching to that unless I get punted as RM
[21:17]  * jam realizes I've been approaching RM all wrong. I should be extolling the virtues of how wondrous it is to be RM, so someone will take over for me :)
[21:19] <amanica> lol
[21:28] <lamont> how do I abort a merge (that had conflicts)?
[21:29] <Lo-lan-do> revert?
[21:31] <lamont> sounds like it would have worked if I hadn't helped it along first.. OTOH, it wasn't quite where I wanted it anyway, so I'm now back to thinking that I know where I am
[21:53] <stefano-k> hi all
[21:53] <stefano-k> I read in bzr planet that the bazaar documentation is now translated in japanese too... do you know how to contribute to translate it (in Italian)?
[21:56] <servilio> jelmer: is there a bug tracker for bzr-svn? can't remember
[21:56] <jelmer> servilio: launchpad.net/bzr-svn
[21:57] <servilio> jelmer: just there, lapsus mentis, sorry
[21:57] <servilio> jelmer: but just to check, I've just installed it and didn't complain about subvertpy not being available
[21:58] <servilio> it is not listed as a dependency in setup.py
[21:58] <servilio> is this intentional?
[21:59] <nivya> I'd like to have bzr version control on my server  and access it from my laptop. I have bzr installed on both server and client. How to tell bzr to create a project and store files on the server?
[21:59] <Peng> stefano-k: Well... I don't know if there is any documentation on it, but if you get a copy of lp:bzr you can probably mostly figure it out.
[21:59] <Peng> Heh.
[22:08] <nivya> what's the best bzr gui client out there?
[22:10] <servilio> nivya: bzr-explorer
[22:12] <poolie> hi jam
[22:16] <jam> hi poolie
[22:16] <poolie> hi, nm, i sent you mail
[22:19] <jam> poolie: I might ask you to run a snapshot for me. I'm trying here, but it seems to get stuck in the "waiting-for-shutdown" state.
[22:20] <jam> I'll give it a bit longer
[22:20] <jam> I wonder if I need to change the admin password back
[22:20] <jam> I doubt it., but maybe
[22:32] <poolie> jam, doesn't it proceed automatically from that state?
[22:32] <Peng> Heh, branching MySQL without a format conversion took an hour and 200 MB of RAM.
[22:32] <poolie> ie request the snapshot, then os shutdown, snapshot, instance shutdown or reboot should happen automaticalyl?
[22:33] <poolie> Peng: locally? over the network?
[22:34] <Peng> poolie: Over the (not overly fast) network.
[22:34] <poolie> k
[22:34] <poolie> there is a lot of data there
[22:34] <poolie> if you set debug_flags=hpss it will print some stats at the end
[22:34] <jam> poolie: he's comparing it to w/ a conversion
[22:35] <jam> which took hours 200+MB and didn't finish
[22:35] <jam> well, downloaded 300-400MB IIRC
[22:35] <jam> and IIRC it takes at least 5-600 MB to download all of mysql in 1.9 format
[22:35] <jam> drops to around 200 in 2a
[22:37] <Peng> poolie: Yeah, but it also puts a ton of information in .bzr.log, no? I'd love to see the stats, but not the other stuff.
[22:43] <igc> morning
[22:43] <igc> hi jam, poolie
[22:43] <poolie> hi igc
[22:44] <Peng> Currently, pulling revisions 1001-2500 with a conversion is stuck after downloading about 250 MB.
[22:48] <lifeless> Peng: cpu high?
[22:50] <jam> hi igc
[22:51] <Peng> lifeless: No, it hasn't done a damn thing in hours. Most of it has been swapped out by now.
[22:51] <igc> hi jam - how the trip back?
[22:51] <igc> was
[22:51] <jam> igc: trip back went smooth. Long, but smooth
[22:51] <jam> and not as long as the way out :)
[22:51] <Peng> lifeless: Eventually it'll exit saying "Connection closed".
[22:52] <jam> I guess LAX was a bit of a pain 2-hr layover and I had maybe 5min before boarding because you have to go through security again
[22:52] <Peng> jam: FYI, the 1.14 repo is 475 MB.
[22:52] <Peng> jam: No clue how that translated to bandwidth.
[22:52] <jam> Peng: which branch?
[22:52] <jam> lp:mysql ?
[22:52] <Peng> jam: mysql-5.1.
[22:52] <jam> IIRC mysql/6.0 is bigger
[22:52] <Peng> I think that's lp:mysql.
[22:53] <jam> Peng: sounds about right
[22:55] <jam> Peng: du -ksh mysql/.bzr is 629MB here, w/ 5.1 and 6.0 present
[22:56]  * Peng looks up -k
[22:56] <Peng> Oh, neat.
[22:59] <jam> Peng: it is an old habit. I used to work on Unix boxes that have 512byte blocks rather than 1k blocks
[22:59] <jam> and having to divide by 2 all the time was annoying
[22:59] <mwhudson> like os x 10.2 ...
[22:59] <lifeless> uhm
[23:00] <lifeless> -k changes the rounding figure
[23:00] <Peng> jam: The 6.0 branch is pretty old.
[23:00] <lifeless> using it will give wrong answers if the fs is 512 byte blocks
[23:00] <jam> lifeless: it gives the right answer to "how many kb are there"
[23:00] <jam> it gives the wrong answer for "how many blocks are used"
[23:00] <lifeless> jam: it gives the wrong answer to how many kb are there
[23:01] <lifeless> by file-count * block-size-error
[23:01] <jam> lifeless: it gives a much closer to how many 'kb' there are than du without it on 512 byte blocks
[23:01] <jam> :0
[23:01] <jam> :)
[23:01] <jam> sure for 100s of files it may round each one incorrectly
[23:01] <jam> still much easier to parse as a human
[23:01] <Peng> jam: (It hasn't been committed to since 2009-05-16, and accessible since 2009-10-29.)
[23:01] <jam> that was before -h
[23:02] <jam> Peng: sure, I'm not sure where 6.0 series development really is
[23:02] <lifeless> jam: or -b I guess
[23:02] <jam> lifeless: yeah
[23:02] <jam> peng: but I'm sure its active since guilhembi has been reporting bugs for using bzr w/ 6.0 development
[23:03] <Peng> jam: There are some recently-modified branches on https://code.edge.launchpad.net/mysql-server. I just got 5.1 because I didn't know which were most important.
[23:04] <jam> Peng: I'm pretty sure 5.1 is their focus, though I thought they released 5.4?
[23:04] <jam> 6.0 was sort of like py3k, IIRC
[23:04] <jam> 'the future stuff'
[23:05] <Peng> Python 3 got released. :P
[23:05] <Peng> jam: 5.4 branch hasn't been touched in 17 weeks.
[23:05] <jam> Peng: there are releases of 6.0, for what mysql considers releases
[23:05] <Peng> (Note: I know nothing about MySQL.)
[23:05] <jam> I don't think there is a General Availability, but I don't really track it
[23:06] <jam> mysql-server/cluster-6.4 was touched just yesterday
[23:06] <jam> anyway, I'm glad you got the data
[23:06] <jam> its time for me to EOD
[23:09] <Peng> jam: Yeah, but I wanted to look up WTF it was before getting a copy, and didn't feel like doing so right then. :P
[23:15] <bjp> hey, if i have several projects in a directory, and i use bzr-init to create a shared repo in that directory, whats the best way to add the subdirectory projects to the new shared repo?
[23:16] <jam> bjp: they are already branches?
[23:16] <jam> bzr reconfigure --use-shared IIRC
[23:17] <bjp> yes
[23:19] <bjp> cool
[23:29] <bialix> jam: ping
[23:43] <Peng> bialix: He might've left about 15 minutes before you joined.
[23:43] <bialix> perhaps
[23:43]  * bialix sighs