/srv/irclogs.ubuntu.com/2009/11/19/#bzr.txt

mkanatmwhudson: Looks indeed like I was getting the assertion because of actually closing a connection before data came out of it.00:00
mwhudsonmkanat: oh right00:02
phoenixzbzr missing returns a shell exit code 1 if there is branche divergence?00:42
spivphoenixz: that sounds right00:43
phoenixzspiv: ah, since it was not documented in bzr help missing.. I was already wondering about this behaviour00:44
lifelesswe should doc it00:44
spivSimilar to how diff will return non-zero if there are differences.00:44
spivThe docs should say so, though.00:44
phoenixzspiv: what manual?00:45
phoenixzspiv: bzr help missing doesnt have it documented..00:45
phoenixzspiv: http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm also doesn't show00:46
spivphoenixz: bzr help missing probably should, and maybe other places too.00:46
spivWow, 0.10 is seriously old.00:46
spivIs that really the version you are using?00:47
spivphoenixz: by "should" I mean, "probably doesn't yet, but that is something for us to fix"00:47
phoenixzspiv: eh, no, its just a manual I quickly looked up :)00:47
poolielifeless: nice page about pmtu00:50
pooliethe historic problem is what i thought it was, but the auto adaption is new to me, and clever00:51
pooliealso " Just remember: The glass is neither half full nor half empty, it is merely the wrong size. " sounds like you :)00:51
pooliebut him spelling 'microseconds' as 'uS' is like nails on a blackboard00:54
lifeless;)00:56
pooliehttp://en.wikipedia.org/wiki/Siemens_(unit)00:56
poolielifeless: 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 flags00:58
lifelesspoolie: yes, spm has tools to do this01:02
poolieit seems like we should be able to do it at our end?01:02
spmtcmpdump + tcpflow + xplot ftw01:03
spmgarh. s/tcpflow/tcptrace/01:03
poolierly tcmpdump?01:03
spmman. I so can't type today... tcpdump :-)01:03
spmwireshark does the window graphing; but I find the above more versatile and ... obvious01:04
spmpoolie: eg: http://tcptrace.org/manual/node12_mn.html01:05
igchi poolie01:08
igchi spiv01:08
mwhudsonmkanat: are you on ubuntu one?01:56
mkanatmwhudson: Nope.01:56
mwhudsonoh, this log chunk is only 28k01:56
mwhudsonmkanat: what's your email address?01:57
mkanatmwhudson: mkanat at everythingsolved01:57
mkanatdooot coooooom01:57
mkanat01:57
mwhudsonmkanat: you should have mail02:00
mkanatSweet.02:00
mkanatIndeeed.02:00
rubbsHello,02:19
rubbsI'm interested in squashing some documentation bugs02:19
rubbsI need some advice though02:20
rubbsFirst, where should I pull a branch down from? bzr or bzr-alldocs?02:21
spivigc: ^02:21
rubbsand should I just pull one down and hack away? or should I talk some things over with a maintainer first?02:21
igcrubbs: hi02:22
igcrubbs: which docs did you want to fix first?02:22
rubbsigc: hello are you Mr. Clatworthy?02:22
igcrubbs: I am02:22
rubbsigc: cool I'm Pat Regan, I was the newbie on the mailing list who expressed intrest...02:23
rubbsthe first one I was thinking was bug 5960802:23
ubottuLaunchpad bug 59608 in bzr "'bzr ignore' undocumented behaviour and misleading tutorial" [Medium,Confirmed] https://launchpad.net/bugs/5960802:23
rubbsbut I'm thinking it might have already been taken care of.02:23
igcrubbs: most of the doc is maintained inside the main bzr code base02:24
spmmkanat: 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
spmmkanat: and hi, btw :-)02:24
mkanatspm: Thanks!02:24
mkanatspm: Hello. :-)02:25
igcrubbs: so you want to grab lp:bzr02:25
rubbsOk, got one grabbed02:25
igcrubbs: are you using explorer or the command line tool?02:25
spmmkanat: fwiw, if you need any further assist; ping me or a general 'losa ping' to summon myself or one of my fellows02:25
rubbsigc: mostly commandline, but I've got qbzr tools installed too02:25
mkanatspm: Awesome.02:25
igcrubbs: cool02:25
igcrubbs: the doc for each command is inside bzrlib/builtins.py02:26
igcwell, most commands at least02:26
rubbsigc: ok02:26
igclook for cmd_ignore (say)02:26
mkanatspm: 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:26
spmsure. at this stage all that's beeen done is a purely random IP s/r.02:27
mkanats/r = search and replace?02:27
igcrubbs: the tutorials are under the doc/en directory02:27
rubbsigc: k, found it02:27
spmsorry - yes.02:27
mkanatspm: No problem. :-)02:28
rubbsigc: ok, found those too.02:28
igcrubbs: have you submitted a merge proposal using Launchpad before?02:28
rubbsigc: no I haven't. This would be my first ever contribution to anything really.02:29
igcrubbs: no problem. We're here to help02:29
rubbsgreat!02:29
igcrubbs: the basic summary is ...02:29
igc(1) make you changes02:29
spmmkanat: 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) commit02:29
igc(3) push the branch to Launchpad02:30
igc(4) submit a merge proposal02:30
mkanatspm: So these are happening pretty frequently then.02:30
rubbsigc: ok, that makes sense. Not much different than a centralized with local commits workflow then02:30
spmmkanat: :-) you *could* say that. that codebrowse is referred to by us sysadmins as codebounce, is another clue ;-)02:31
mkanatLOL02:31
mkanatInteresting that there are so many /atom requests for exactly two projects right before the hang.02:31
spmright02:31
spmwhere it gets fun is when our nagios check url gets hungup as well.02:32
mkanatHahahaha, omg.02:32
igcrubbs: I need to grab some lunch right now. If you have questions, spiv and many others can help so just ask02:32
igcbbiab02:33
rubbsigc: great thanks for all your help02:33
mwhudsonmkanat: sometimes some requests that usually take a few seconds hang around for minutes02:33
mwhudsonmkanat: i have basically no idea why02:33
mwhudsonmkanat: note that our loggerhead access branches over http02:33
mkanatmwhudson: In terms of the port being open, or what?02:33
mwhudsonnot the local filesystem02:33
mkanatOhh, interesting.02:33
mkanatSo there's going to be a lot more latency than on my systems.02:34
mkanatI didn't even know loggerhead could do that.02:34
mwhudsonbut i've never pinned this down to a real problem02:34
mwhudsonmkanat: well, not much more latency, it accesses the branches over gigE (i think) to apache serving static files02:34
* mkanat nods.02:34
mkanatThere's still pretty good latency in general over the http protocol.02:34
mwhudsonmkanat: as to it being possible, bzr is awesome sometimes :)02:35
mwhudsonopen branch, give it to loggerhead02:35
mwhudsonloggerhead doesn't care about where the branch is from02:35
mkanatThat's pretty awesome.02:35
mkanatYeah, bzr's architecture seems pretty sweet, generally, from the outside.02:35
lifelessthanks02:35
mkanat:-)02:35
spmheh02:36
mkanatHmm, on the memory leak one, I'm actually not currently getting it to go over a certain fixed size.02:37
mkanatI'll have to try other things.02:37
* mkanat is also doing a Bugzilla release simultaneously, right now.02:38
mkanatmwhudson: I was noticing that a few things seem slower than necessary.02:40
mkanatmwhudson: Though I can't quite pin that down either.02:40
* mkanat just got a pause on mine, too, even on localhost.02:40
mkanatWas pretty brief, though.02:40
mkanatmwhudson: Okay, I can at least see which threads are hanging, from the logs.02:51
mwhudsonmkanat: cool02:51
mkanatmwhudson: I can see the "Getting information for" but no "Rendering" for certain requests right before the hang.02:51
mwhudsonmkanat: are they building revision caches?02:51
mkanatmwhudson: Yeah, two of them are.02:51
mkanatI'll check the second hang.02:51
mwhudsoncool02:51
mkanatThe second one's more confusing. :-)02:53
mkanatThere's a lot happening right before that hang.02:53
mkanatmwhudson: And yeah, I see what you mean about the long requests. Getting information for RevisionUI: 201.69120788574219 secs02:56
mkanatmwhudson: Here's an interesting thing. All requests are fast shortly before the hang.02:56
mkanatI mean, *until* shortly before the hang.02:56
mwhudsonso "something" happens, and then suddenly requests are slow, and then we're in a death spiral?02:57
mwhudsonsounds about right02:57
mkanatmwhudson: Yeah, that seems like what's going on.02:57
mkanatmwhudson: And it's never rendering that takes a long time, it's always getting information, from what I can see.02:58
mwhudsonmkanat: now, please tell me what it is that happens02:58
mwhudson:-)02:58
mkanatLOL02:58
mwhudsonmkanat: my /theory/ is that it's basically thrashing02:58
mwhudsontoo much going on at once, too many threads competing for cpu, performance falls into the toilet02:59
mwhudsonit would be good to confirm/deny02:59
mwhudsonmkanat: if you want to enhance logging, we can get new code into production pretty fast for this02:59
mwhudson(<24 hrs)03:00
mkanatmwhudson: Okay, awesome.03:00
mkanatmwhudson: I might want to do that for the memory leak if I don't get anything.03:00
mkanatmwhudson: Just like a "process increased by X size after this request" sort of thing.03:00
mwhudsonmkanat: go wild :)03:00
mwhudsonwe could even try getting meliae dumps i guess03:01
mwhudsonbut they will be, uh, moderately large03:01
mkanatHahahaha.03:01
mkanatYeah, I would imagine.03:01
mkanatI 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:02
mwhudsonfrom my side, i view the hangs as a much more serious and mysterious problem than the leak03:03
mkanatOkay.03:05
mkanatI'll focus on that.03:05
* mkanat had just started to anyway.03:05
mkanatAnd 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:05
mkanatmwhudson: 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
mwhudsonmkanat: yeah, possibly03:06
mwhudsonmkanat: a disk backend would be plenty fast enough though03:07
mkanatAnyhow, back to analysis.03:07
mkanatmwhudson: Okay. :-)03:07
mwhudsonmkanat: a more serious problem is the serialization of the graph03:07
mwhudsonmkanat: we basically deserialize the graph in one lump03:07
mwhudsonand that's crack, it would be really good to stop doing that03:07
mwhudsonmkanat: i guess the memory leak problem will in all likelyhood come back into prominence for us if we fix the hanging problem :-p03:08
mkanatmwhudson: Wow, yeah, I imagine that kills performance for huge projects.03:10
* mkanat nods.03:10
mwhudsonmkanat: i marshal the data and gzip it03:10
mwhudsonmkanat: loading it for launchpad takes ~0.2s03:10
mwhudsonso it's not terrible03:10
mkanatOkay.03:11
mwhudsonbut still crack :)03:11
PengI can make it slower if you want. >.>03:13
mkanatmwhudson: 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
mwhudsonmkanat: not necessarily03:13
mwhudsonit means the requests are piling up :(03:14
mkanatmwhudson: 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:14
mwhudsonmkanat: er03:15
mwhudsonmkanat: can you point me to a line number in the logfile?03:15
mkanatmwhudson: INF [20091118-05:42:04.440] [1084594512] loggerhead.~munin-custom-plugins/munin/munin-plugins-tomcat: Getting information for ChangeLogUI: 3.7736661434173584 secs03:15
mkanatmwhudson: That's the line. I have the log file a bit hacked up at the moment.03:15
mkanatmwhudson: At least, that's where it starts.03:15
mwhudsonmkanat: the requests are being handled by different threads i think03:17
mkanatmwhudson: Oh, are the numbers in brackets not thread ids?03:17
mwhudsonINF [20091118-05:42:07.532] [1093282128] loggerhead.~munin-custom-p...03:18
mwhudson                             ^^^^^^^^^^ thread id doing the logging03:18
mkanatmwhudson: Yeah, that's what I thought.03:18
* mwhudson looks a bit closer03:18
mkanatmwhudson: 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:18
mkanatmwhudson: I can investigate this on my own too, if I'm taking up too much of your time.03:19
mkanatmwhudson: I'm perfectly capable of figuring out everything by digging through the code. :-)03:19
mwhudsonmkanat: that's pretty whack03:19
mkanatYeah!03:19
mkanatThat's what I'm saying! :-D03:19
mkanatmwhudson: Another hung thread does the same thing.03:22
mkanat108879700803:22
mwhudsonmkanat: i would _guess_ that this perhaps means that the client is no longer listening03:23
mkanatmwhudson: 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
mkanatmwhudson: I was just about to ask.03:23
mwhudsonmkanat: oh right, yes, so you should know this: our ProxyTimeout is 20s i think03:23
mwhudson(maybe 30)03:23
mkanatmwhudson: Ah, okay. :-)03:24
mkanatmwhudson: So all these bad threads are getting SIGPIPEd or something. But apparently they keep on living.03:24
mwhudsonwell python ignores sigpipe03:24
mwhudsonbut you should get an error writing to the socket sure03:24
* mkanat nods.03:24
mwhudson(and i think you do, sometimes)03:25
mkanatI've seen it in my own logs, yeah.03:25
mwhudsonmaybe one or more of: paste, apache, python, linux, the universe is screwing us here03:25
mkanatLOL03:25
mkanatYeah, it's possible.03:25
mkanatmwhudson: So python ignores the broken socket, and the thread then...? I guess I should go look at the code at this point.03:26
spm<mwhudson> 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 in03:26
mkanatspm: Hahahaha, okay. :-)03:26
mwhudsonmkanat: what i would have written by now if i had an infinite amount of time would be a stateful log parser03:26
mkanatmwhudson: I could probably write that pretty quickly. That's a Perly sort of job.03:27
mkanatAnd I've written so many state-machine parsers now...03:27
mwhudsonmkanat: 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 state03:27
mkanatmwhudson: Oh, that would be interesting for sure.03:27
mwhudsonand also find threads that don't go through that pattern03:27
mkanatmwhudson: I'll see if I can put together a little script here.03:27
mwhudsonmkanat: that'd be awesome03:28
mwhudsonthen maybe we can fling existing logs at it rather than having to ship them to you and see if any interesting patterns show up03:28
spmwfm03:28
mkanatmwhudson: 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
mwhudsonmkanat: we don't have to tell anyone else about it :-)03:29
mkanatlol, okay.03:29
mkanatIt'll be easier than parsing text stack traces. :-)03:30
mkanat(That's the last stateful parser I wrote.)03:30
mwhudsonshould be03:31
mkanatmwhudson: BTW, what log is this that I'm getting? Because it looks different than my normal loggerhead logs.03:32
mwhudsonmkanat: the entry point we use and all the log setup is in the launchpad-loggerhead branch03:33
mkanatmwhudson: Ahh, okay.03:33
mkanatSo this will be a launchpad-loggerhead log parser, then.03:33
mkanatNot for the standard loggerhead logs.03:34
mwhudsonyes03:34
mkanatWorks for me.03:34
mwhudsonsome of the goodnees in launchpad-loggerhead should probably be moved to loggerhead03:34
mwhudsonnot sure that the log setup counts as goodness mind...03:34
mkanatI dunnow, these logs are more readable, at least.03:34
rubbsOK, 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:42
lifelessbzr push lp:~username/project/branchname03:43
* rubbs slaps forehead. should have remembered that. thanks03:43
rubbsOk, 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:47
rubbsSorry for all the newbie questions, I've just never done this before.03:48
spivrubbs: feel free to just propose it03:48
spivrubbs: no, please ask any questions, that's totally fine03:48
rubbsspiv: great thanks!03:48
spivrubbs: if you're unsure you can ask here or on the mailing list before proposing03:48
rubbsspiv: great! thanks for being patient. I've always good help from this channel.03:49
spivrubbs: but generally a merge proposal is a great venue for a conversation about a branch :)03:49
rubbsspiv: great to know03:49
distaticaHey 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 t03:51
spivdistatica: you got cut off03:53
distaticawhat point?03:53
spiv"to delete t"03:53
spivBut you probably don't want a working tree on the server.03:54
distaticaDo 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
spivThe revision history is all present in the .bzr directory.03:54
distaticathen I'm not sure what I want to do, just upload the whole directory via scp?03:54
spivIf 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
spivdistatica: just "bzr push"03:54
rubbsspiv: thanks for all your help. I've done a merge proposal.03:55
rubbsigc: thanks for all your help too.03:55
spivdistatica: and probably "bzr remove-tree" once on the server to get stop the warnings03:55
mkanatspm: Are those log times in UTC?03:55
distaticathat's what I'm using, for the first time, but then I have to login and delete or else my client complains03:55
distaticahmm03:55
spmmkanat: good Q; that server is on BST; but that may == UTC atm. looking....03:56
spivI'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
spmmkanat: yes. atm, that's UTC03:56
mkanatspm: Okay.03:56
distaticaspiv: I use --create-prefix with push, that does it doesn't it?03:57
spivNo, that's something else.03:57
spivThat's about whether you can push to a/b/c if the directory a/b doesn't exist yet.03:57
distaticabzr push --create-prefix sftp://name@host.net/~/public_html/code/myproj03:58
distaticathat's what I use, myproj doesn't exist.03:58
distaticathen in redmine, I point it to there for the repo.03:58
spivThat seems fine (although if code/ exists then --create-prefix is redundant but harmless)03:58
distaticacode can't exist03:58
distaticabecause if it does, I get the errors03:58
distaticaoh interesting04:00
distaticaif I use that full line, it works04:00
distaticaif I just do 'bzr push' it doesn't.04:00
distaticaI thought push just used my last information..04:00
spivIt uses the "remembered" location.04:01
distaticaI'm confused04:01
spivThe first time you push a branch, it'll remember that location.  But an already remembered location won't be overwritten unless you specify --remember04:01
distaticaoh, how can I see what I'm attemptign to push to?04:02
spivbzr will tell you when it is using a remembered location, it'll say something like  "Using saved push location: ..."04:02
spivYou can also run "bzr info"04:02
distaticaaha04:03
distaticathat's it, pushing to another directory, heh04:03
distaticaoh beautiful, now everything is working. Thank you very much.04:04
spivNot a problem.04:06
spivrubbs: 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:16
lifelessspiv: to check if ~FOO has signed, are you started at ~FOO and their groups, or at the group we care about?04:33
spivlifeless: I look at ~FOO and check their groups, but I also check the wiki page04:38
mkanatmwhudson: I have the parser, now it's just a matter of output and what we do with the parsed input.04:44
mwhudsonmkanat: cool04:45
mwhudsonmkanat: well, how about "what state are all the threads in when codebrowse was restarted" ?04:46
mkanatmwhudson: Yeah, that can be done.04:46
mkanatmwhudson: Here's the fully-parsed log that you sent me: http://pastebin.ubuntu.com/322153/05:14
mkanatmwhudson: It doesn't include lines that don't involve some sort of action.05:14
mkanatmwhudson: It lists threads in reverse time order, but then the actions within the threads in forward time order.05:15
mkanatmwhudson: I did it all by creating objects, so changing the output format should be pretty easy.05:16
mwhudsonmkanat: cool05:17
mwhudsonmkanat: my brain has stopped working for the day, btw :)05:17
mkanatmwhudson: Hahahaha, no problem.05:17
mkanatmwhudson: 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:18
mkanatmwhudson: Though I suppose those completed, so that doesn't help. :-)05:19
mwhudsonmkanat: yeah05:19
mkanatmwhudson: Code's here: bzr://bzr.everythingsolved.com/loggerparse/trunk FWIW.05:23
mwhudsoncool05:24
mwhudsoni'll look tomorrow :)05:24
* mwhudson runs away from the computer05:24
mkanatOkay.05:24
mkanatLOL05:24
spmnight mwhudson!05:24
mkanatNight mwhudson. :-)05:24
distaticaHey 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
distaticaI 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 (e05:41
jelmerdistatica: Are you sure this is the right channel?05:42
distaticaIt should be noted, when debug=0 the problems disappear.05:42
distaticaoh goodness05:43
distaticasorry05:43
jelmerno worries :-)05:43
JohnAlbinBesides lp, are there any publicly-available bzr hosting solutions?05:47
jelmerJohnAlbin, sourceforge does, and I believe savannah as well05:48
distaticabzr hosting? like launchpad?05:48
jelmerJohnAlbin, and anything that support sftp/ftp can be used (although a bit slower than the smart server)05:49
Kamping_Kaiserdepends what 'like launchpad'05:49
Kamping_Kaisermeans05:49
distaticaI 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
distaticaoh geez05:50
distaticaI completely missed the lp, I'm on a role. :/05:51
distaticathought it was a nick05:51
* JohnAlbin is googling savannah and redmine, atm.05:52
JohnAlbinthanks!05:52
distaticaredmine you have to run though, it's not hosted. You need a web host that will let you do a little compiling and supports ruby05:53
JohnAlbinah, ok.05:54
=== JohnAlbin_ is now known as JohnAlbin
mkanatspm: Can I get more logs from around restarts?06:29
mkanatspm: It's hard to say that something is a pattern with just two logs. :-)06:30
mkanatBut I see a few patterns.06:30
spmmkanat: heh. no worries. will do; what are you after; cause the others are possibly quite large?06:30
mkanatspm: Well, mostly I'd just like to see the last five minutes before the hang.06:30
mkanats/crash/hang/06:31
spmoki; that's easy. will round up to nearest 10 I 'spect; easier on my aching regexified eyes06:31
mkanatThat's fine.06:31
spmoki, gimme a few and I'll grep that for you06:33
mkanatOkay. :-)06:34
mkanatAlso, wow, loggerhead is not coping with all the requests it's getting.06:36
mkanatDEB [20091118-05:42:40.758] [47447192702192] paste.httpserver.ThreadPool: Added task (14 tasks queued)06:36
spmharumph. file size == 0. messed something up....06:37
mkanatspm: If you'd rather have it crash than hang, there's a max_zombie_threads_before_die option for Paste that might help.06:47
mwhudsonoh man, if you can belt paste into being a bit more sane that would also be good06:48
mwhudson(or suggest a better container)06:48
mkanatYeah, there's also hung_thread_limit.06:48
mwhudsonpaste is really not expecting threads to be cpu bound though06:49
mwhudsonand the default zombie_thread_timeout is like 1800 seconds06:49
spmcrash/hang - all equally bad from our perspective. no real preference06:49
mkanathung_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
mkanatThough that would screw with building the revision graph.06:49
mwhudsonmkanat: indeed06:50
mwhudsonmkanat: we kill threads after 300 s06:50
mwhudson~ish06:50
mwhudson300s of inactivity06:50
mkanatA workaround for the hang might be to set hung_thread_limit to 300s.06:51
mkanatAlthough you might still get 300s hangs.06:51
mwhudsoni think we do?06:51
mkanat[mkanat@es-compy loggerhead]$ grep -R hung_thread_limit *06:52
mkanat[mkanat@es-compy loggerhead]$06:52
mwhudsonmkanat: not loggerhead06:52
mwhudsonlaunchpad-loggerhead06:52
mkanatmwhudson: Ohh.06:52
mwhudsonmkanat: and in fact we sometimes do recover from the hangs06:52
mwhudsonmkanat: but far too slowly06:53
spmway too slowly06:53
mkanatAhh, okay.06:53
spmand usually die "harder" within the next 30 mins or so fwiw. unscientific observation06:53
mwhudsonmkanat: i had this vague idea that you could push off the revcache generation, not just caching to another process06:53
mwhudsonthen you could just kill threads after 30s and be fine with that06:54
mkanatmwhudson: That would be a good workaround, yeah.06:54
mkanatmwhudson: 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
mkanatI'm mostly just musing aloud, I'm still investigating.06:55
mwhudsonmkanat: hm06:55
JohnAlbinHmm… looks like SourceForge is on 1.10. Guess I'll use lp. :-)06:56
mkanatmwhudson: It's only RevisionUI that builds the graph, right?06:57
mwhudsonmkanat: no06:57
mwhudsonbasically any branch access will06:57
mwhudsonmkanat: look at history,py06:57
mkanatmwhudson: Thanks.07:00
* spiv is done for the day07:12
spmg'night spiv!07:13
mkanatWhat I really wish I could get is a traceback of every thread when it's hung.07:22
spmthat... that's achievable. gdb attach dump goodness I assume?07:23
mkanatspm: Well, it's in Python, so it won't be quite the same.07:23
mkanatspm: Unless gdb can give me a python traceback. :-)07:24
spmmkanat: it can! mwhudson ^^  we use your magic .gdbinit on that one?07:24
mkanatspm: Really? Because that would save me all the trouble of log analysis.07:25
spmreally? in that case, no we cna't. :-P07:25
mwhudsonmkanat: http://pastebin.ubuntu.com/322211/07:25
mkanatspm: lol07:25
mwhudsonstick this in .gdbinit07:25
mwhudsonoh07:26
mwhudsonor do you want this on prod?07:26
mkanatmwhudson: Yeah, on prod, when it's hung, before it's restarted.07:26
mwhudsonspm: in your court i guess07:26
mwhudsonall the bits are there i think07:26
mkanatThe 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
mkanatBecause I can't tell the difference between "client gave up and went away" and "thread is waiting for data".07:27
spmmwhudson: wfm; lets try that then.07:28
spmmkanat: next batch of logs enoute anyway. fwiw.07:28
mkanatspm: Okay, cool.07:28
mkanatI'll see if I can make it hang locally.07:28
spmbbs07:33
mkanatspm: 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:37
spmmkanat: 1stly we'll get a nagios check fail07:38
spmtimes out - from memory07:38
spmwill try the thread-debug trick - see if that dumps anything useful07:39
spmoften that also hangs tho07:39
spmtry a local manual nagios check - 10secs limit - that time out == considered dead. restart.07:39
mkanatHmm.07:40
mkanatOkay.07:40
spmis one of those... greatest good for greatest numbers cases.07:40
* mkanat nods.07:40
spmit sucks for those whose sessions we just KO'd; but....07:40
mkanatSo the hang itself likely happens long before you actually kill the process.07:42
mkanatIt may in fact not even be hanging, just becoming really slow.07:43
mkanatI have a theory, even. If building the revision graph is really taking 4-5 minutes for each thread....07:43
mkanatAnd we get 5 busy threads building revision graphs, then paste won't spawn any more threads.07:43
spmsure. from our perspective the difference is ... not that significant tho07:43
spmhang vs slow as in07:44
spmmkanat: we got one! attaching now.07:53
mkanatspm: Awesome!!07:53
spmwell.. no, but yes :-)07:53
mkanatHahaha. :-)07:55
spmargh. what's the easy way to attach to a process; do the bt/pydump goodness without having to page all the time?07:57
mkanatOh...07:57
* mkanat tries to remember the command.07:57
mkanatspm: Maybe if your output isn't a terminal it just won't ask you to page at all?07:57
spmhrm. tricky....07:57
spmgargh; we're about to lose codehosting anyway - doing a h/w upgrade on it. 2 mins....07:58
spmmkanat: oki; my bad; I'll do some docco reading and be ready for the next one.08:00
mkanatspm: Agh, okay. :-)08:00
spmmkanat: 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/wherever08:03
mkanatGreat. :-)08:03
mkanatHey mthaddon.08:03
mthaddono/08:03
mwhudsonmkanat: btw re bug 156453 i think the problem is likely to be connected to the insane number of branches our loggerhead sees08:06
ubottuLaunchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/15645308:06
mkanatmwhudson: Could be, though I ran on a limited number of branches (five) and still saw a leak.08:07
mkanatmwhudson: If you see the leak faster than me, it could be that there is more than one leak.08:07
BasicOSXeverything ok with LP?08:17
BasicOSXbzr: 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 Unavailable08:17
spmBasicOSX: ahh. I didn't update the topic here. my bad. Codehost is offline for a h/w update. ~ 4 hours unf.08:23
=== spm changed the topic of #bzr to: LP Codehosting offline for H/W update 0800-1200 UTC | Bazaar version control system | 2.0.2 and 2.1.0b3 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
RenatoSilvawhere can I find info about bzr branch formats? google search just returns crap :P08:53
bialixRenatoSilva: what kind of info you need?08:56
RenatoSilvabialix: I-have-no-idea kind :)08:59
bialixcool09:02
rogererensI 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:20
dalinoh that's why nothing works09:36
LarstiQrogererens: launchpad is down for a hw upgrade atm, but the mailing list at https://launchpad.net/~bzr-doc would be a good bet09:36
JohnAlbino_O09:38
* JohnAlbin looks at the channel topic.09:38
JohnAlbinwait. is LP codehosting down right now?09:38
LarstiQyes, the topic says so :p09:38
JohnAlbinI assume that's why I'm getting this error: "ssh: connect to host bazaar.launchpad.net port 22: Connection refused". bah.09:39
LarstiQyes09:40
* JohnAlbin starts watching http://twitter.com/launchpadstatus for updates09:41
rogererensLarstiQ: thanks!09:43
RenatoSilvawhy does everyone uses twitter09:48
RenatoSilva*use09:48
mkanatmwhudson: 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:49
mwhudsonmkanat: cool09:54
mwhudsonmkanat: what is going on?09:54
mkanatmwhudson: You were pretty much right, except that it doesn't actually hang.09:54
mwhudsonok it's just severely degraded?09:54
mkanatmwhudson: Generating the revision graph for a very large branch simultaneously several times in various threads slows loggerhead to a crawl.09:54
mkanatYeah.09:54
mwhudsonmkanat: btw09:54
mwhudsonmkanat: where are you?09:55
mkanatmwhudson: Mountain View.09:55
mwhudsoni'm sure you should sleep at some point09:55
* mkanat shrugs. :-)09:55
mwhudsonoh not too insanely late i guess09:55
mkanatMy girlfriend's still at work, I'd probably be waiting up for her anyway. :-)09:55
mwhudsontime for me to zzz anyway09:55
mkanatmwhudson: Anyhow I suspect that just opening a few revisions on a launchpad branch that hasn't been graphed yet will cause it.09:56
mkanatlaunchpad itself, bzr itself, mysql -- those seem to be the only ones large enough to cause it.09:56
mkanatI'll send off an email about it to you and Francis.09:56
mwhudsonthanks, sounds like a good result for day 109:56
RenatoSilvabialix: can't find anything about branch formats in bzr docs10:09
bialixRenatoSilva: bzr help formats ?10:13
* bialix still does not understand what RenatoSilva looking for10:14
bialixRenatoSilva: what you looking for?10:14
bialixdefinition of formats?10:15
bialixor understanding what's under the hood?10:15
mkanatmwhudson: Welcome. :-)10:16
RenatoSilvabialix: I am just one that has no idea about it and is curious about all those weird format specs10:19
RenatoSilvabialix: bzr help formats tells about rich-root but does not explain or points the user to somewhere else10:20
bialixbzr help current-formats10:20
RenatoSilvabialix: in general, it just says 2a ig good and you should be using it, it's not new to me10:20
bialixbzr help other-fromats10:20
RenatoSilvabialix: I have run bzr help current-formats already10:20
bialixRenatoSilva: bzr core devs think that understanding of deeper internals is not for mere mortals10:21
RenatoSilvabialix: I'm still reading it but it doesn't seem to include any explanation of what is rich-root10:21
bialixso there is no detailed spec on repo format10:21
bialixcompare to git where you need to understand all internals first you even start using it10:21
RenatoSilvabialix: the format names are out of order, if there should be any10:21
bialixrich-root is repository format variant which store unique id for root of your tree10:22
bialixRenatoSilva: open .bzr/checkout/dirstate file and look at it10:22
RenatoSilvabialix: e.g are B+trees in 1.9 an improvement (included by all further formats), or an specific feature of that format?10:22
bialixRenatoSilva: in bzr you need to remember that there is 3 different beasts: branch, repository and working tree10:23
bialixthat's complicate understanding a lot10:23
bialixrich-root is the "feature" of repository10:23
bialixRenatoSilva: 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 it10:24
bialixB+trees index introduced in 1.9, yes10:25
bialixit may be using in all later formats, e.g. 2a10:25
RenatoSilvabialix: ok I just suggest to order help current-formats10:25
bialixthey are sorted for me10:26
RenatoSilvabialix: 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
bialixit's format zoo, not format shop10:26
bialixyou may call it a log10:27
bialixdoes not really matter10:27
RenatoSilvaI 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 now10:27
RenatoSilvabialix: sorry it's ordered, except 2a is displayed 1st10:28
bialixRenatoSilva: http://pastebin.com/d78d7b28810:29
lifelessRenatoSilva: 2a is the one you should use10:29
RenatoSilvabialix: in the first place that's what I wanted, and overview of the current formats etc10:29
bialixRenatoSilva: there was decision helper from lifeless: use either default format or what your upstream use. if you're using bzr-svn -- use rich-root10:29
bialixlifeless: I have big doubts10:30
RenatoSilvabialix: I just thought I would find it in the docs, not bzr help10:30
RenatoSilvabialix: so, thanks :)10:30
bialixmost docs generated from help10:30
lifelessbialix: about 2a? I saw your comment about merge, but thats a working tree thing, not repository layer10:30
bialixit seems these topics are not found their way to docs yet10:30
bialixlifeless: wt thing?10:30
lifelessthe same id for '' issue10:31
lifelesssorry, different id for ''10:31
bialixBug 484706?10:31
ubottuLaunchpad bug 484706 in bzr "merge 2 unrelated branches in rich-root format cause path conflict for the same file-id" [Low,Confirmed] https://launchpad.net/bugs/48470610:31
RenatoSilvabialix: about your paste, I see 2a in the top, and yours is missing it10:32
lifelessyeah10:32
bialixRenatoSilva: this is from bzr 2.1.0b310:32
RenatoSilvabialix: which removed 2a from the help?10:32
bialixRenatoSilva: lol10:32
bialixI dunno10:32
bialix2a listed as default10:33
bialixbut yes it hould be there10:33
bialixbut yes it should be there10:33
bialixtime for filing a bug?10:33
bialixghaa! 2a now listed in other-formats10:34
RenatoSilvabialix: 2.0.2: http://pastie.org/705698.txt10:34
bialixI think it's a bug10:34
bialixlifeless: does 2a will not default format in 2.1?10:34
RenatoSilvaeven if not default (o.O), I think it should be there10:34
lifelessbialix: I don't think we'll change the default for a while now10:34
lifelessbialix: so 2a should still be the default10:35
lifelessbialix: do you have a plugin that changes the default perhaps/10:35
lifeless?10:35
bialixRenatoSilva: please, file a bug about this topics?10:35
bialixoh10:35
bialixyes10:35
bialixI am10:35
bialixsorry guys10:35
bialixmy bad10:35
RenatoSilvathat plugin also removes the 2a text?10:36
lifelessits a side effect10:36
lifelesscurrent-formats is dynamic10:36
bialixcool10:36
RenatoSilvawhy would it remove it, for what reason10:36
RenatoSilvajust because it is not default? but none of them are default except one of course10:37
bialixRenatoSilva: I have plugin format1 which forces usgae of pack-0.92 as default format10:37
RenatoSilvaand they're all listed there10:37
bialixRenatoSilva: I have plugin format1 which forces usage of pack-0.92 as default format10:37
RenatoSilvabialix: 0.92 is a very old format I suppose10:37
bialixyes, but I need it10:37
bialixfor my work10:37
bialixsome our machines have installed bzr 1.210:38
RenatoSilvabialix: but the plugin should not remove the 2a text, should it?10:38
RenatoSilvabialix: 1.2 oohh10:38
bialixRenatoSilva: no, plugin does not working with help text, but the text itslef generated dynamically10:38
RenatoSilvabialix: is it you that sends some msgs twice, or is your irc client? :)10:38
bialixso there is some side effects10:38
bialixit's me10:39
RenatoSilvabialix: so it it a bug or not?10:39
bialixno10:39
bialixit's not bug in bzr10:39
RenatoSilva*is it, ok so cancel my report10:39
bialixat least it's not worth to file it.10:39
RenatoSilvaimho it is a bug, but ok10:39
bialixresolution on this bug would be: bialix is dumb10:39
bialixit's bug from plugin, so maybe I should fix it in my plugin10:40
RenatoSilvaah ok10:40
* RenatoSilva is curious about checking what formats his local branches are using10:41
RenatoSilvabzr format is not a command :(10:41
RenatoSilvabzr info maybe, lmt10:41
RenatoSilvaoh, why is it 0.92 here too?10:42
bialixbranches not auto-magically upgraded10:42
RenatoSilvaI have other one here 'unnamed' o.O10:42
bialixyou have to upgrade each branch manually10:42
bialixbzr info -v10:42
bialixunnnamed -- means a mix of different fomats of branch/repo and wt10:43
RenatoSilvabialix: but 0.92 sounds like I created the branch in the time of bzr 0.92 (?)10:43
bialix0.92 was default format until bzr 2.010:43
RenatoSilvawhy?10:43
bialixso any branch created by default in this format10:43
bialixwhy? what whay?10:44
bialixwhy it was default?10:44
bialixmaybe for backward-compatibility reasons10:44
RenatoSilvaoh I see, and it's fine to break it in big releases (2.x), nice :)10:45
bialixyep10:45
bialixfurthermore it's backward-incompatible break10:46
RenatoSilvabzr 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
bialixonce you upgrade to rich-root (2a) you can't go back to poor-roots10:46
RenatoSilvais there any rich-root explanations for dummies? :)10:46
bialixlol10:47
RenatoSilvabialix: about bz info, can't get format 1,2, 3,4...10:47
bialixRenatoSilva: most likely you have 2a branch ion shared repo which is 1.910:47
bialixor something like that10:48
RenatoSilvaI'd expect to see the format names displayed in help rather than ordinal specs10:48
bialixwhat is ordinal specs?10:49
RenatoSilvathe names, format 1, 2, 3, 410:50
RenatoSilvabialix: 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:50
bialixit's internal10:51
bialixthey are internal names10:51
bialixformats like pack-0.92 or 2a is combine names10:51
bialixs/is/are/10:51
bialixbecause you have sum of 3 formats (Mets directory format 1 is not changed for years)10:52
RenatoSilvabialix: in LP there's a section in the branch "Repository format:  Packs 6 (uses btree indexes, requires bzr 1.9)"10:54
bialixit's eq to 1.9 format10:54
RenatoSilvawouldn't one be interested in the "storage formats" like displayed in bzr help current-formats?10:55
RenatoSilvarather that this specific internal info?10:55
bialixheh10:56
bialixthis is question not to me10:57
bialixthe strings you see are hardcoded now forever10:57
bialixyou can see them in .bzr/branch/format10:57
bialix.bzr/repository/format10:57
bialix.bzr/checkout/format10:57
bialixrhey are identify of specific format10:58
RenatoSilvaI mean in LP10:58
bialixwell, I dunno10:58
* bialix -> lunch10:59
RenatoSilvathanks for help bialix11:00
=== mthaddon changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b3 have gone gold! time to build those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Current pilot: spiv
RenatoSilvalp-users-editable bzr wiki is recent?11:09
gioelehello11:17
gioeleI 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:19
RenatoSilvaI'd resubmit the merge proposal and/or subscribe the reviewers to the branch (try also #launchpad)11:20
Glenjaminhi guys, i'm getting a bunch of NoSuchRevision exceptions when trying to diff local trees which are checkouts from an SVN repository11:23
Glenjaminis there any way to resolve these, or failing that just remove all the Bzr metadata from the SVN repo and start afresh11:24
salgadolifeless, still around?11:28
boogiepetshi all11:36
boogiepetsi have a question on bazaar explorer11:36
boogiepetswhen i hit the "Commit" button on the toolbar11:37
boogiepetsthe "Commit" window pops up11:38
boogiepetswhich is "always on top"11:38
boogiepetswhy is that?11:38
boogiepetsi am used to inspecting the diff while i am preparing to commit11:38
boogiepetsin order to write details about the commit in the "Message" area11:39
boogiepetswith the "Commit" window always on top i have to scroll it in order to see the diff window which is rather annoying11:39
boogiepetsanyone willing to help?11:40
boogiepetsis there any way to change this behaviour?11:40
bialixboogiepets: there is diff button in commit window11:40
bialixboogiepets: are you using explorer + bzr-gtk11:41
bialix?11:41
boogiepetsyes, exactly11:41
bialixsorry, I dunno then11:41
bialixare you mysqler?11:41
boogiepetsnope11:42
boogiepetsthe "Diff" button is indeed there11:42
bialixthen install qbzr and use it as your gui widgets for explorer11:42
boogiepetsbut when i press it, the diff window pops behind the commit window11:42
bialixhmm11:43
bialixwe have one bug report in qbzr about such weird behavior11:43
boogiepetshmmmm, okay i'll try qbzr although i was getting quite fond with bazaar explorer11:43
bialixthere is still no understanding what's going on11:43
boogiepetsexactly the same thing?11:43
boogiepetscommit window "alwasy on top"?11:44
bialixboogiepets: explorer will use qbzr widgets11:44
bialixlemme find bug report11:44
boogiepetssoorrrrry11:44
boogiepetsjust a mo11:44
boogiepetsi am using nautilus and bzr-gtk11:44
boogiepetsi am in Ubuntu 9.04 environment11:44
bialixboogiepets: in Explorer: Tools -> Options and then select Suite -> qbzr11:45
bialixbug 42103911:46
ubottuLaunchpad bug 421039 in qbzr "Diff windows launched from qci are always in the background" [High,Confirmed] https://launchpad.net/bugs/42103911:46
bialixboogiepets: ^11:46
bialixcheck if you encounter the same bug, please11:47
bialixadd the comments there about your system and library versions'11:47
boogiepetsOK, for me that was "Edit -> Preferences"11:47
boogiepetsand qbzr was already selected11:47
bialixwill be nice if Gary can figure out what's the problem11:47
boogiepetsi see that gtk provides a different window on commit11:48
bialixboogiepets: ok, so you're using qbzr in fact11:48
boogiepetsbut i like the qbzr one more11:48
boogiepetsyes correct11:48
bialixyes, bzr-gtk and qbzr are 2 different plugins11:48
boogiepetsallright, installing the various things got me confused11:48
boogiepetsso i am using qbzr at the "Suite" option11:49
boogiepetsi'll check the bug report now11:49
bialixok, bbl11:49
boogiepetsok, posted comment on launchpad12:04
boogiepetswould really like to see this fixed12:04
boogiepetsthanks bialix12:04
boogiepetssee ya12:04
NET||abusehey guys.12:54
NET||abusei'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:54
NET||abusei'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||abusethe problem is that it takes FOREVER!12:55
NET||abuse34 megs will transfer on our network in under a minute.12:55
LarstiQNET||abuse: how long is forever?12:56
NET||abuseI've been waiting a good 10 minutes at this point.12:56
LarstiQNET||abuse: and what version of bzr, and what transports?12:56
NET||abuseand i'ts only 36% in Build phase: Adding file contents12:56
NET||abuseon windows bzr 1.18.112:57
NET||abusetransports? network shares, smb12:57
NET||abuseis that what you mean?12:57
LarstiQNET||abuse: hmm, I guess that gives me enough info12:57
* LarstiQ was after sftp://, bzr+ssh:// etc12:57
LarstiQin `bzr push bzr+ssh://host/path/`12:58
NET||abuseit's a dapper drake ahh :)12:58
LarstiQbut it seems you're treating it as a local filesystem12:58
LarstiQwhich will mean it creates a workingtree12:58
NET||abusein windows it's bzr push P:\graphicdesign\sitedesign\12:58
NET||abusethough i'm using hte tortoisebzr interface right now :)12:58
LarstiQok12:59
LarstiQNET||abuse: what format is it in? `bzr info` will tell you12:59
NET||abusestandalone tree (format: pack-0.92)13:00
LarstiQNET||abuse: ok, you might want to try 2a13:00
LarstiQNET||abuse: and if you don't need the working tree, getting rid of that will help a lot13:00
NET||abusewell, 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 pull13:01
NET||abuseor bzr add; bzr commit; bzr merge; bzr commit; bzr push13:02
LarstiQNET||abuse: ok, so you absolutely need the working tree then13:02
NET||abuseand one final bzr up on the share again .13:02
LarstiQNET||abuse: are you the only one who interacts with it via bzr?13:02
NET||abuseyeh. 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 produced13:02
NET||abuseat the moment yeh.13:02
LarstiQok13:02
NET||abusei'm the only bzr user.13:02
NET||abusei just check for new stuff being dropped in periodically.13:03
LarstiQNET||abuse: then please try `bzr upgrade --2a` and see what the effect is of that13:03
LarstiQif it's still slow, why needs figuring out13:03
NET||abusehehe, 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:04
NET||abuseLarstiQ, 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||abusei just didn't realise it was doing that.13:05
NET||abusestill,, what's the advantage of the 2a version?13:05
NET||abuseis it just hte archiving schema? what does it do better?13:05
LarstiQNET||abuse: the important part here being a more efficient storage, let me look up the link13:09
NET||abusehmm, cool. ok.13:09
NET||abusewhy does it not create that format by default? is my bzr version on windows just too old?13:10
LarstiQit creates it by default from bzr version 2.0.013:10
NET||abuseah,, but my windows bzr install is only bzr 1.18.113:12
LarstiQhttp://bazaar-vcs.org/Benchmarks?highlight=%28benchmark%29 is what I was thinking of iirc13:12
LarstiQNET||abuse: right, but 1.18 can read and write 2a13:12
LarstiQbut it hadn't been made the default yet13:13
LarstiQso when the switch was made, there were a couple of older clients that could handle the format too13:13
NET||abuseahh, ok13:13
NET||abusemight see if i can get a 2.x client version for my windows box then.13:14
NET||abusemy linux laptop is ubuntu karmic, which is packaged with 2.0.1 , is that the most recent stable?13:14
LarstiQNET||abuse: it is right now, 2.0.2 is on it's way to release13:14
NET||abusecool.13:15
NET||abusehave to say, it's getting better than when i first used it.13:15
NET||abuseor at least i'm getting more comfortable with it..13:15
LarstiQthat's the idea with software development ;)13:15
NET||abuseswitching from svn is tricky :)13:15
NET||abusein terms of changing your mindset on how things should work.13:16
* LarstiQ nods13:16
NET||abusei 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||abusehave to say, svn is good in that your certain it's going to work.13:16
NET||abusei'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:17
LarstiQsvns maturity (and thus 3rd party support) is certainly a feature13:18
NET||abuseaha,,, i imagine bzr or git will probably make it's way to primary use in our office soon.13:19
NET||abuseright, i need lunch :)13:20
NET||abuseoh, one more thing, i need a good workflow for managing web dev projects, i design sites and code php or python,13:21
NET||abuseat 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:21
NET||abusefor each directory of stuff that needs copying..13:22
RenatoSilvahow to extend bug tracker support for commit --fixes?13:22
NET||abusei'm wondering about a better deployment management strategy.13:22
LarstiQNET||abuse: I'd use bzr-upload13:22
LarstiQNET||abuse: http://bazaar-vcs.org/BazaarForWebDevs http://bazaar-vcs.org/BazaarUploadForWebDev13:23
RenatoSilvahow to extend bug tracker support for commit --fixes? can I define new prefixes? like bzr bugs fb=http://foo.bar13:23
LarstiQRenatoSilva: yes, see `bzr help bugs`13:24
RenatoSilvathanks!13:31
RenatoSilvabut why bugzilla_squid_url = http://www.squid-cache.org/bugs13:36
RenatoSilvawhy not be free to create a template like13:36
RenatoSilvabugs_prefix = http://www.anyone.org/this_work/this_way?bug_id=%s13:37
RenatoSilvaso that you bzr commit --fixes=prefix:12313:38
LarstiQRenatoSilva: 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:38
RenatoSilvaLarstiQ: 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:40
LarstiQRenatoSilva: the sentence before that: along with a template mechanism for other bugtrackers with simple URL schemes.13:41
LarstiQRenatoSilva: maybe that should be "this will cover most bugtrackers"?13:42
RenatoSilvawhy would not that template mechanish doesn't work with some bug tracker?13:42
RenatoSilvas/mechanish doesn't work /mechanism work13:43
LarstiQRenatoSilva: because some are convoluted and you can't just plug in a bug number13:43
RenatoSilvaah. Do you know one?13:44
LarstiQRenatoSilva: not off the top of my head, I may have repressed knowledge of such a beast13:45
maxbHrm, didn't qbzr display branch nicks before the most recent version?13:51
maxbthe truncation of branch names in the tree is also less than welcome13:55
=== jam1 is now known as jam
maxbHm, the branch nicks were lost in a refactor merged yesterday14:07
MvGHi! 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:11
MvGI'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:13
MvGNow 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:14
MvGTrouble 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:16
MvGSo 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:17
MvGThere 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
MvGWhat do you think? Bug? Feature request? Or simple misconfiguration, as python should know the file system encoding?14:18
MvGOut 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:54
MvGIs "bzr serve --directory=/some/dir" guaranteed to restrict access to said directory?14:57
bialixmaxb: hello15:03
maxbhello15:03
bialixcan you elaborate on "the truncation of branch names in the tree is also less than welcome"?15:04
bialixmaxb: can you test my fix for Bug 48513315:04
ubottuLaunchpad bug 485133 in qbzr "Reference to undefined name 'revids_load' in log.py" [High,In progress] https://launchpad.net/bugs/48513315:04
bialix?15:04
maxb1: I'd rather see my long branch names in full, even if they are long15:05
maxb2: I will try later, but I don't really know what I did to provoke it in the first place, so it may be difficult15:05
bialixmaxb: I've added truncation long ago on 20 symbols15:06
bialixwe can move this into config15:06
maxbIndeed, I have no idea why I only just noticed it15:06
bialixbut I can suggest you where in the code you can change the limit15:06
maxbAlso, it only seems to apply to branch names, not tag names, which is a bit inconsistent15:06
bialixabout nick and tags and bugs: this is indeed regression from garyvdm15:07
bialixGary!15:07
bialixyes, only branch names truncated, because I had evidence of 120 chars long nick15:07
bialixbtw, this is branch nicks, not branch names15:08
bialixso you can do: bzr nick "my very very very very very very very long nick" and guess what happnes15:08
bialixmaxb: you can change branch nick with `bzr nick` command15:09
maxbyes. But equally you can do: bzr tag my-very-very-very-very-very-very-very-very-very-very-long-tag15:09
bialixtags is psecial15:10
bialixsorry15:10
LeoNerdSurely a certain amount of "you're doing it wrong" applies if you need names -that- long..?15:10
bialixtags is special15:10
bialixmaxb: truncation done in loggraphprovider.py around line 36715:11
bialix                tag = bi.branch.nick15:11
bialix                if len(tag) > 20:15:11
bialix                    tag = tag[:20]+'...'15:11
maxbLeoNerd: Arguably there's a certain amount of "you're doing it wrong" if you're using CVS, but we are :-)15:12
bialixbut yes, we're not very consistent here15:12
LeoNerdmaxb: Oh.. is this for cvs->bzr branch conversion?15:12
maxbyup15:12
LeoNerdHeh.. :) Might have guessed...15:12
bialixmaxb: really?15:14
bialixscary15:14
maxbYes it is, that is why I am attempting to drag my team kicking and screaming out of the dark ages and to bzr15:14
bialixmaxb: about truncation: I won't mind if you file this wish as bug report15:18
jamMvG: "bzr serve --directory=/foo/bar" does guarantee to not serve outside of /some/dir15:32
bialixhi jam15:32
jamjelmer: if you are around... "bzr branch lp:bzr-svn" still seems to be broken for me...15:32
jamhi bialix15:32
jamI don't know if you and mwh, et al sorted out a plan for fixing it?15:33
MvGjam: thx!15:33
jelmerjam: I'll have a look15:34
jamMvG: as for trac-bzr, it definitely needs to know the fs is utf-815:34
jamI don't know how to tell it that, though.15:34
MvGjam: Found out, at least for my case: reconfigured my mod_fastcgi to set the LANG environment variable.15:35
MvGI guess it's not worth the effort to work around a possible misconfiguration on the bzr side.15:35
jamMvG: it is hard to do, because we are relying on the underlying python implementation for a lot of things15:36
MvGIt would be possible, but probably would require case distinctions for different os.15:36
MvGNever mind, and thanks for your opinion.15:37
jamMvG: 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:37
MvGIn some cases yes, in others no...15:38
jamjelmer: I'm not sure if you followed mwh's discussion of how it happened15:38
jambut basically, your dev focus used to be a mirrored branch15:38
jamso all your lp branches are stacked on it15:38
MvGOh, and by the way, jam, thanks for approving my trac-bzr team membership!15:38
jamwhen you changed it to hosted, then the newly created branch got stacked elsewhere, and things got circular15:38
jamMvG: np, you've been doing a lot of work there anyway15:39
MvGjam: 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:39
jamMvG: I think trac-bzr is pretty 'loose' in changes15:41
jamI don't know that anyone is actually maintaining trunk15:41
jamwell, actively maintaining15:41
MvGIn 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
MvGThere 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:42
MvGhttps://lists.launchpad.net/trac-bzr-team/15:43
mzzI really should remove myself from that team, it's not like I actually know the code anymore15:44
jamMvG: I believe it is because there were none15:44
jammzz: I'm sure you know it better than *I* do :)15:46
mzzjam: you might be surprised!15:46
jammzz: since I've never read it at all...15:46
jamat best we would be equal :)15:47
mzzI don't even remember if any code I wrote is in this incarnation of the plugin15:48
bialixoh! trac-bzr hackers here!15:48
MvGquote so.15:49
mzzMvG: 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:49
MvGI'm only touching the most prominent issues so far.15:50
MvGNothing seems impossible yet... ;-)15:50
bialixI'm still using old version of trac-bzr with trac 0.10.515:51
bialixwith bzrlib from bzr 1.515:51
bialixthen something becomes broken15:51
bialixI really hope that I can upgrade my trac setup soon15:51
bialixMvG: does new improvements to trac-bzr will require upgrade to trac 0.11?15:52
MvGmzz: 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
mzzwell, I can try15:52
MvGbialix: 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:52
MvGdo you consider 0.10 support important?15:53
MvGIf so, it might be worth a branch...15:53
gioeleMvG: Trac 0.10 is very widely deployed15:53
MvGBecause 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
mzzMvG: 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 anything15:54
bialixI won't object to upgrade to 0.11 and support only it if it helps to make trac-bzr better15:54
ubott2Launchpad bug 484983 in trac-bzr "BzrDirNode.get_previous broken" [Undecided,New]15:54
bialixjust in 2007 when I've installed it on my work it was difficult to use 0.11 on Windows15:55
gioeleMvG: anyway, if the trac-bzr is not going to be released soon, maybe it makes more sense to concentrate on 0.11 only15:55
ubott2Launchpad bug 484640 in trac-bzr "Branches wiki macro is defunct" [Undecided,New]15:55
MvGgioele: 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:55
gioeleMvG: go ahead and forget my remarks about 0.10.x ;)15:57
MvGBut 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.15:57
mzzMvG: did you spot http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L50 ?16:00
MvGmzz: not yet.16:01
mzzMvG: it is likely trac changed substantially since I wrote that function and just removing it is now sane16:01
mzzMvG: 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 history16:04
Adyshow do I show a diff from one specific rev to another?16:05
mzzbut I'm still re-reading16:05
mzzAdys: bzr di -rfirstrev..secondrev16:05
Adysthanks16:05
bialixhello amanica_16:08
mzzMvG: 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 anywhere16:09
MvGmzz: It's the part about "avoiding get_history" for which I don't understand how it works, and which would affect performance.16:10
MvGRight now it does use get_history, I guess.16:10
mzzMvG: iirc if you just remove the function the default implementation calls get_history16:11
amanica_hi bialix16:11
bialixhow are you?16:11
amanica_not bad thanks, almost recovered from flu16:11
amanica_you?16:11
mzzMvG: 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 faster16:12
bialixamanica_: too much work, too little time for hacking16:12
mzzMvG: but that's years ago, get_history probably got smarter, and it's usually calling into a completely different bzr repository now16:12
MvGYou mean different repo format?16:12
mzzMvG: so if removing get_previous works *and* performs reasonably, I'm pretty sure that's the right thing to do16:12
amanica_bialix: yup, me too. also trying to catch up to the bzr mailing list16:12
mzzMvG: yep16:13
MvGI'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:13
mzzMvG: 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
bialixmaxb: several of your reported bugs in qbzr just fixed. thanks for reports!16:14
MvGotoh 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
MvGeither take the previous revision of the whole branch, find the last modified revisoon of every child, and take the latest of these,16:15
MvGor 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
MvGBoth 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
mzzMvG: 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:15
mzzMvG: 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
MvGmzz: Still is that way, and the proken "Previous Chang" link is what got me started to investigate.16:16
mzzMvG: and since that time the entire thing got a lot smarter about caching etc (I think all of BranchCache was added later)16:16
mzzMvG: so if it performs acceptably on branches with a nontrivial amount of history you should just kill the function, I think.16:17
=== ubott2 is now known as ubottu
MvGOK, 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:17
mzzMvG: just make sure you test on a nontrivial branch (few 100 revisions), if what I remember about this is correct that matters16:19
mzzwell, mattered :)16:19
=== bac is now known as bac-lunch
mzzMvG: 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 for16:20
mzzit's *supposed* to do the same thing as get_history, anything else is me cheating16:21
mzzand now you've made me remember about http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/head%3A/HACKING#L85 :(16:22
MvGmzz: I already made close aquaintance with that __del__ method: https://bugs.launchpad.net/trac-bzr/+bug/48432416:29
ubottuLaunchpad bug 484324 in trac-bzr "memory leak due to uncollectable BzrRepository" [Undecided,New]16:29
mzzMvG: yeah, I think I saw that one in my bug mail :(16:29
MvGI guess I should have a read through HACKING, see what it says and what might need updating when I commit stuff.16:29
MvGHad 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:31
mzzMvG: 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:34
MvGmzz: Considering your useful input here, I'd hate to see you leave the team, as you stated somewhere up there.16:35
mzzMvG: 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:35
mzzMvG: 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
MvGI'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:36
MvGany benefit in the weakref callback over the del as I implemented it in LockedBranches?16:37
mzzMvG: it's not __del__ :) weakrefs don't break the cycle collector like __del__ does.16:37
MvG__del__ doesn't break a thing is it's not in a cycle. Therefore my new approach works.16:38
mzzMvG: 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:39
mzzMvG: 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
mzzbut hey, I added the original __del__, I can't complain no matter which way you go here :)16:41
* MvG is reading up on weakref callbacks16:42
mzzthey're easy. Sec, lemme branch16:43
MvGmzz: 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:44
MvGAnd I'm not sure if the callback gets executed if the object owning the weakref becomes collectable before.16:45
MvGI.e. whether my LockedBranches might get finalized without the callback being ever triggered.16:45
MvGAny objectsions to me updating the trac-bzr trunk repo to 2a format?16:46
MvGwould allow stacked branches...16:46
mzzMvG: heh, only I can't test this because I don't have trac installed16:47
Lo-lan-doHi all16:50
mzzMvG: 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:50
Lo-lan-dojelmer: 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
jelmerLo-lan-do, hi16:51
jelmerLo-lan-do: Yeah16:51
Lo-lan-do:-)16:51
MvGmzz: Why can't that happen? After all, both become collectable at the same time.16:52
Lo-lan-dojelmer: When would it be convenient for you?16:52
mzzMvG: see lp:~marienz/trac-bzr/bug484324 (untested!)16:53
jelmerLo-lan-do, now would be good I think16:53
Lo-lan-doYay16:54
mzzMvG: the BzrRepository has a strong ref to its LockedBranches, so the LockedBranches refcount won't go to 0 before the BzrRepository16:54
jelmerLo-lan-do: Is now good for you as well?16:55
Lo-lan-dojelmer: Sure. Shall we move to private?16:55
jelmeryeah16:56
MvGThe 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
MvGI just don't feel safe here, it's relying a lot on implementation details.16:56
MvGAt least feels that way to me, as I'm still relatively new to Python.16:57
mzzMvG: __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
MvGI had the impression __del__ gets access just before the object dies.16:58
MvGWhich 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:58
mzzMvG: __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
MvGweakref is all right for me, but relying on the callback seems bad.16:59
mzzMvG: how so?16:59
MvGAs I pointed out, I'm not confident the callback will get executed at all.17:00
MvGI see no spec clearly stating it will.17:00
mzzMvG: can you describe a way to make it not execute?17:00
mzzMvG: preferably one where __del__ *will* :)17:00
MvGWrite 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:01
MvGI 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
MvGI know __del__ is guaranteed to be called before the object gets collected, and that all outgoing references of the object will stay intact.17:02
MvGThat's a clean and reliable promise, and one I can work with.17:03
mzzMvG: where are you seeing any guarantees that __del__ gets called that don't apply to weakrefs?17:03
mzzthere 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:03
mzzalso "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:04
MvGOK, you made a point there.17:05
MvGmzz: 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
MvGWill code that later, gotta east something first...17:09
mzzMvG: you already have that. BzrRepository has a strong ref to LockedBranches.17:09
MvGBut BzrRepository itself isn't reachable any more.17:10
mzzMvG: no, but that's the whole point.17:10
mzzMvG: 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:11
MvGSo 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
MvGNo, only if the BzrRepository were to /use/ the branches later on.17:12
MvGSo the order of finalization doesn't matter, as long as neither one is going to run any other code.17:13
MvGGotta go, will be back later on...17:13
=== amanica2 is now known as amanica
=== LeoNerd is now known as LeoNerdTest
=== LeoNerdTest is now known as LeoNerd
=== bac-lunch is now known as bac
=== fenris__ is now known as ejat
ibrandtGreetings 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 Gi19:32
ibrandtproject 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:32
LarstiQibrandt: or use bzr-git19:33
* Tak agree19:34
jamibrandt: http://bazaar-vcs.org/TrackingUpstream19:36
jamibrandt: you may want to look at "Converting and ignoring history"19:36
jamit talks about cvs, but I imagine it would be about the same for git19:37
ibrandtAh, okay.  Thanks!  I'll read up.19:37
LarstiQibrandt: and linked off from that, http://bazaar-vcs.org/BzrForeignBranches/Git19:40
distaticaAnyone 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:45
jamdistatica: I would guess that the dependency isn't a strong one, but just whatever recipe was copied when they made the package19:48
lifelessmoin20:04
lifelessjelmer: +1 to adding gagern to bzr-trac?20:07
jelmerlifeless: I think you mean trac-bzr :-) (bzr-trac is an unfriendly fork)20:09
lifeless$garh20:09
jelmerlifeless, no objections here, although I'm not really involved with trac-bzr anymore20:09
lifelessme neither20:09
lifelessbut I figure two not involved people saying yes is better than noone saying no20:09
jelmerlifeless: I agree, I think it would be hard to find people actually involved atm20:10
lifelessMvG: hi20:10
MvGlifeless: hi as well!20:11
MvGOh, you been talking about me! :-D20:11
lifelessMvG: yah20:11
MvGjam already approved my team mambership...20:12
lifelessjust wanted to say that trac-bzr doesn't really have anyone caring about it in terms of 'maintainers'20:12
lifelessso don't block on reviews20:12
lifelessif you don't get a review for a branch in (say) 2 days, I think you should land it.20:12
MvGglad to hear that.20:13
MvGShould I request reviews over the launchpad merge request thingy?20:13
lifelessyup20:13
MvGgladly.20:14
lifelesshmm, lets see if trunk has any subscribers20:14
MvGI'm thinking about a branch for 0.10 compatibility. What do you say?20:15
lifelesshah, the owner isn't subscribed. \o/ thumper: <- when can we do this search and fix?20:15
thumperlifeless: I'll get back to you shortly?20:16
lifelessthumper: :P20:16
lifelessMvG: I have no opinion. I don't know where trac is at, lifecycle status, userbase that will want bzr for trac 0.10 etc20:16
thumperlifeless: a call20:16
MvG0.10 is widely deployed, and 0.11 introduced some serious changes.20:17
lifelessMvG: 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 you20:17
MvGgood idea. but tomorrow - its getting late around here...20:17
lifelessMvG: no rush20:18
lifelessMvG: just saying :)20:18
MvG:-)20:18
MvGI guess I'll add a bunch of branches of my own tomorrow.20:19
LarstiQMvG: considering the reality of trac deployment, I'd vote for a 0.10 branhc20:19
LarstiQMvG: unless you keep trunk 0.10 compatible that is20:19
LarstiQeither works, whatever is least hassle20:19
LarstiQMvG: and good night ;)20:20
MvGLarstiQ: 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
MvGThus branch and backport as much as feasible, but no more.20:20
* LarstiQ nods20:21
distaticajam: 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
LarstiQMvG: I run a 0.10 trac, though not actively with bzr. If you ping me I can test though.20:22
jamdistatica: can you run "bzr -Derror" so you can see what is failing?20:22
jamLike, do you have pyqt and other such dependencies installed?20:22
distaticaYeah, but I might be missing something I didn't notice.20:23
distaticaor the wrong package was installed.20:23
MvGLarstiQ: Thanks for the offer. Will ghet back to it when I have two more commits or so in my quoting branch.20:23
=== mwhudson_ is now known as mwhudson
LarstiQMvG: k20:23
jamdistatica: it could be version skew, depending on what version of bzr you have installed, too20:23
distaticahowever, when I run bzr -Derror it just prints the help, bzr -D error says error is a command not found20:23
distaticahmm20:24
MvGBy 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:24
LarstiQdistatica: no space between -D and error20:25
Lo-lan-dodistatica: try "bzr -Derror qbzr", or howewer you're supposed to run qbzr20:25
LarstiQMvG: in general I'd say yes, but that needs more thought for the specific change20:26
* LarstiQ goes to bed20:26
* MvG too20:27
MvGThx!20:27
distaticahmm, that error just shows me that it's not starting, and that it fails when trying to call qbzr20:28
amanica_Lo-lan-do: with only qbzr you can run each command seperately, see http://bazaar-vcs.org/QBzr20:29
Lo-lan-dodistatica: There's probably some log in .bazaar20:30
distaticaone file, ignore20:30
Lo-lan-doOh, it's ~/.bzr.log, sorry20:33
hersonlshi, where i found how export repo with python?20:38
hersonlsthe python api20:39
amanicahersonls: I think you can only export a branch at a time see: bzr help export20:40
amanicaI think it would be nice to be able to export a repo though20:40
hersonlsamanica, i need ceate a python script to export without bzr comand, understand?20:41
amanicaaah ok20:41
amanicaI may not be able to help now, mabe somebody else can20:41
amanicayou can maybe look in builtins.py20:42
amanicathere you can see how the "branches" command finds branches, and also check there how the "export" command exports them. hth20:42
hersonlsamanica, ok20:43
hersonlsamanica, i belived have documentation for this20:44
jamhersonls: define "export"20:45
jamdo you want just the files on disk20:45
jamsimilar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"20:45
jamor are you asking to have the history?20:45
jamamanica: and 'bzr branches' is in bzrtools, not core (yet)20:46
hersonlssimilar to "bzr export ../foo.tar.gz" or "bzr export ../to_dir"20:46
amanicajam: whoops, I thought it made it into the core already20:46
jamhersonls: then you'll want to look at 'builtins.py' for the "cmd_export" code20:47
jamI think it is generally "Tree.export('path')" but I haven't looked in a long time.20:47
hersonlsjam, amanica hey20:50
hersonls>>> from bzrlib import export :)20:51
hersonlsexport(tree, dest, format=None, root=None, subdir=None, filtered=False)20:51
hersonlstanks20:51
amanicacool20:51
hersonlsamanica, tanks20:52
amanicanp20:53
mwhudsonis there a 2.1.0b3 release branch?20:58
mwhudsonor just a tag on the 2.1 branch?20:59
pooliehello all20:59
pooliemwhudson: i think the plan is now that it's just tagged on the 2.1 branch20:59
mwhudson(i should probably know this already but well)20:59
mwhudsonokidoke20:59
jammwhudson: 2.1 branch21:05
jamat least, I'm trying it out21:05
rogererensCan .bzrignore files contain comment lines (in order to explain why some paths/files are ignored)?21:06
mwhudsonjam: cool21:06
jamrogererens: with #21:06
mwhudsonof course i remembered the odd push -r behaviour again...21:06
jammwhudson: pushing something older than target does nothing?21:06
mwhudsonjam: no much odder than that21:07
mwhudsonjam: https://bugs.edge.launchpad.net/bzr/+bug/48451621:07
ubottuLaunchpad bug 484516 in bzr "bzr push -r $revspec ../foo creates branch with working tree from tip, not that of $revspec" [Undecided,New]21:07
jamah, yeah that's pretty strage21:08
jamstrange21:08
jamI think afc argued that we should never update the wt w/ push21:08
jamas it was "inconsistent"...21:08
jamI don't ever use it21:08
jamas cd ../target ; bzr pull works just fine21:08
mwhudsoni was using this to create a new branch at a tag21:09
mwhudsoni guess bzr branch . ../target -r tag:whatever works too21:09
jammwhudson: 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 thing21:11
rogererensjam: # to start a comment line; is it also possible to have inline comment? adding # to the end of line seems to wreck the regex21:12
jamrogererens: I think only a separate comment line21:12
rogererensjam: thx21:12
jamyeah, we have:21:12
jamif not line or line.startswith('#'):21:12
jam    continue21:12
jambut nothing about pulling a # comment out of the middle of the line21:13
mwhudsonso if there isn't a 2.1.0b3 release branch, is there a 2.0.2 release branch?21:15
jammwhudson: there is, but we're switching to just using a tag on the 2.0 branch when 2.0.3 comes out21:15
jamwell, I guess *I*'ll be switching to that unless I get punted as RM21:16
* 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:17
amanicalol21:19
lamonthow do I abort a merge (that had conflicts)?21:28
Lo-lan-dorevert?21:29
lamontsounds 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 am21:31
stefano-khi all21:53
stefano-kI 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:53
serviliojelmer: is there a bug tracker for bzr-svn? can't remember21:56
jelmerservilio: launchpad.net/bzr-svn21:56
serviliojelmer: just there, lapsus mentis, sorry21:57
serviliojelmer: but just to check, I've just installed it and didn't complain about subvertpy not being available21:57
servilioit is not listed as a dependency in setup.py21:58
=== abentley1 is now known as abentley
serviliois this intentional?21:58
nivyaI'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
Pengstefano-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
PengHeh.21:59
nivyawhat's the best bzr gui client out there?22:08
servilionivya: bzr-explorer22:10
pooliehi jam22:12
jamhi poolie22:16
pooliehi, nm, i sent you mail22:16
jampoolie: 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:19
jamI'll give it a bit longer22:20
jamI wonder if I need to change the admin password back22:20
jamI doubt it., but maybe22:20
pooliejam, doesn't it proceed automatically from that state?22:32
PengHeh, branching MySQL without a format conversion took an hour and 200 MB of RAM.22:32
poolieie request the snapshot, then os shutdown, snapshot, instance shutdown or reboot should happen automaticalyl?22:32
pooliePeng: locally? over the network?22:33
Pengpoolie: Over the (not overly fast) network.22:34
pooliek22:34
pooliethere is a lot of data there22:34
poolieif you set debug_flags=hpss it will print some stats at the end22:34
jampoolie: he's comparing it to w/ a conversion22:34
jamwhich took hours 200+MB and didn't finish22:35
jamwell, downloaded 300-400MB IIRC22:35
jamand IIRC it takes at least 5-600 MB to download all of mysql in 1.9 format22:35
jamdrops to around 200 in 2a22:35
Pengpoolie: 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:37
igcmorning22:43
igchi jam, poolie22:43
pooliehi igc22:43
PengCurrently, pulling revisions 1001-2500 with a conversion is stuck after downloading about 250 MB.22:44
lifelessPeng: cpu high?22:48
jamhi igc22:50
Penglifeless: No, it hasn't done a damn thing in hours. Most of it has been swapped out by now.22:51
igchi jam - how the trip back?22:51
igcwas22:51
jamigc: trip back went smooth. Long, but smooth22:51
jamand not as long as the way out :)22:51
Penglifeless: Eventually it'll exit saying "Connection closed".22:51
jamI 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 again22:52
Pengjam: FYI, the 1.14 repo is 475 MB.22:52
Pengjam: No clue how that translated to bandwidth.22:52
jamPeng: which branch?22:52
jamlp:mysql ?22:52
Pengjam: mysql-5.1.22:52
jamIIRC mysql/6.0 is bigger22:52
PengI think that's lp:mysql.22:52
jamPeng: sounds about right22:53
jamPeng: du -ksh mysql/.bzr is 629MB here, w/ 5.1 and 6.0 present22:55
* Peng looks up -k22:56
PengOh, neat.22:56
jamPeng: it is an old habit. I used to work on Unix boxes that have 512byte blocks rather than 1k blocks22:59
jamand having to divide by 2 all the time was annoying22:59
mwhudsonlike os x 10.2 ...22:59
lifelessuhm22:59
lifeless-k changes the rounding figure23:00
Pengjam: The 6.0 branch is pretty old.23:00
lifelessusing it will give wrong answers if the fs is 512 byte blocks23:00
jamlifeless: it gives the right answer to "how many kb are there"23:00
jamit gives the wrong answer for "how many blocks are used"23:00
lifelessjam: it gives the wrong answer to how many kb are there23:00
lifelessby file-count * block-size-error23:01
jamlifeless: it gives a much closer to how many 'kb' there are than du without it on 512 byte blocks23:01
jam:023:01
jam:)23:01
jamsure for 100s of files it may round each one incorrectly23:01
jamstill much easier to parse as a human23:01
Pengjam: (It hasn't been committed to since 2009-05-16, and accessible since 2009-10-29.)23:01
jamthat was before -h23:01
jamPeng: sure, I'm not sure where 6.0 series development really is23:02
lifelessjam: or -b I guess23:02
jamlifeless: yeah23:02
jampeng: but I'm sure its active since guilhembi has been reporting bugs for using bzr w/ 6.0 development23:02
Pengjam: 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:03
jamPeng: I'm pretty sure 5.1 is their focus, though I thought they released 5.4?23:04
jam6.0 was sort of like py3k, IIRC23:04
jam'the future stuff'23:04
PengPython 3 got released. :P23:05
Pengjam: 5.4 branch hasn't been touched in 17 weeks.23:05
jamPeng: there are releases of 6.0, for what mysql considers releases23:05
Peng(Note: I know nothing about MySQL.)23:05
jamI don't think there is a General Availability, but I don't really track it23:05
jammysql-server/cluster-6.4 was touched just yesterday23:06
jamanyway, I'm glad you got the data23:06
jamits time for me to EOD23:06
Pengjam: Yeah, but I wanted to look up WTF it was before getting a copy, and didn't feel like doing so right then. :P23:09
bjphey, 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:15
jambjp: they are already branches?23:16
jambzr reconfigure --use-shared IIRC23:16
bjpyes23:17
bjpcool23:19
bialixjam: ping23:29
Pengbialix: He might've left about 15 minutes before you joined.23:43
bialixperhaps23:43
* bialix sighs23:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!