| lifeless | I think we could do it internally incrementally if we want to; I can answer the points you've put up, but debate-in-detail is often unfruitful for this sort of discussion | 00:00 |
|---|---|---|
| abentley | lifeless: I know about your strong feelings. The time to voice them was when I put CompositeTree up for review. | 00:00 |
| lifeless | abentley: I did | 00:01 |
| abentley | lifeless: Either veto my patch, or stop casting aspersions on it. | 00:01 |
| lifeless | abentley: I'll shut up then; I've been hoping to change your mind, not to insult your patch | 00:02 |
| lifeless | vetoing would block you and unilaterally impose my opinion | 00:02 |
| lifeless | I don't want to do that | 00:02 |
| abentley | lifeless: that could actually be productive, because at least we would resolve this. | 00:03 |
| abentley | lifeless: Right now, your objections are functioning as FUD. | 00:03 |
| lifeless | argh. ok. | 00:03 |
| lifeless | ok, I'll veto and we can discuss | 00:04 |
| abentley | thumper: I no longer have any idea how long Nested Trees will take to land. | 00:06 |
| thumper | :( | 00:07 |
| thumper | what's the issue? | 00:07 |
| abentley | thumper: see above. lifeless is vetoing CompositeTree. | 00:08 |
| thumper | poolie: ping | 00:09 |
| jelmer_ | jonnydee2: hi | 00:16 |
| jelmer_ | jonnydee2: is bzr-config-cli still alive? | 00:16 |
| jml | which format should I be dogfooding? | 00:19 |
| jml | bzr: ERROR: ambiguous option: --development (--development-rich-root, --development-subtree, --development6-rich-root?) | 00:19 |
| mwhudson | jml: the one with '6' in | 00:20 |
| lifeless | jml: --development-rich-root, | 00:20 |
| lifeless | jml: note its a rich-root upgrade, so safe for bzr-svn imports and little else at this point | 00:20 |
| jml | well, this is a new branch | 00:21 |
| jml | designed to carry one emacs lisp file | 00:21 |
| lifeless | go for it | 00:22 |
| jml | if it's not safe for that, there should probably be brighter, flashier, redder lights around the help text | 00:22 |
| lifeless | its supported release by release, be sure to upgrade each release of bzr. | 00:22 |
| jml | *nod* | 00:22 |
| poolie | thumper: hi | 00:29 |
| thumper | poolie: can we have a quick call? | 00:30 |
| poolie | sure give me 5m? then just call if you want | 00:30 |
| lifeless | if its re nested trees, mail is composed | 00:31 |
| lifeless | ok, sent | 00:32 |
| jml | lifeless: aws-status says I have 6 instances running | 00:35 |
| jml | lifeless: amazon says I have one. | 00:35 |
| jml | (I thought I had zero) | 00:35 |
| lifeless | jml: it refreshes every 60 seconds | 00:36 |
| lifeless | jml: could this be a 60-second out window? | 00:36 |
| jml | lifeless: the instances shut down yesterday. | 00:36 |
| lifeless | all but one :P | 00:36 |
| jml | lifeless: it's more likely a network reliability issue. | 00:36 |
| lifeless | did you run it from a console? | 00:36 |
| jml | yeah, I just saw the stacktrace | 00:36 |
| jml | pasting now | 00:37 |
| jml | http://paste.ubuntu.com/164555/ | 00:37 |
| lifeless | ok, please turn that into a bug | 00:37 |
| lifeless | I'll fix after work | 00:37 |
| lifeless | beuno: I think you're exaggerating more than a little | 00:54 |
| jml | spiv: ping | 01:14 |
| lifeless | spiv: ping | 01:15 |
| lifeless | jam: ping | 01:17 |
| lifeless | spiv: I'd like to get together middayish, my place if possible, to plan out the rest of the week. | 01:17 |
| lifeless | abentley: ping | 01:28 |
| abentley | lifeless: pong | 01:28 |
| lifeless | abentley: I have a question about root renames | 01:28 |
| lifeless | I'm testing the issue with upgrade to rich roots you found | 01:28 |
| lifeless | would you expect tree.rename_one('', 'child') to work ? | 01:28 |
| abentley | lifeless: No. | 01:29 |
| lifeless | ok | 01:29 |
| lifeless | I'll do an unversion, add, add dance then | 01:29 |
| lifeless | (I'm using branchbuilder) | 01:29 |
| abentley | lifeless: You could apply an inventory delta, one that added a new root. | 01:30 |
| lifeless | I don't think branchbuilder takes inv deltas | 01:31 |
| lifeless | anyhow, unversion, add, add has worked - lovely test failures | 01:32 |
| abentley | lifeless: Okay. | 01:32 |
| lifeless | this fix should be done today | 01:34 |
| lifeless | I had one other question, which is - have I missed any cases | 01:34 |
| lifeless | I have: | 01:34 |
| lifeless | No parents rev -> No parents | 01:35 |
| lifeless | 1 parent rev -> 1 parent | 01:35 |
| lifeless | 1 ghost parent -> No parents | 01:35 |
| lifeless | 2 parents both heads -> 2 parents | 01:35 |
| lifeless | 2 parents one head -> 1 parent | 01:35 |
| lifeless | 1 parent different fileid, ours missing -> no parents | 01:35 |
| lifeless | 1 parent different fileid, ours moved -> 1 parent | 01:35 |
| lifeless | 2 parents, 1 different fileid, our second missing -> 1 parent | 01:36 |
| lifeless | 2 parents, 1 different fileid, our second moved -> 2 parent | 01:36 |
| lifeless | fin | 01:38 |
| lifeless | abentley: ^ | 01:39 |
| === arjenAU2_ is now known as arjenAU | ||
| abentley | lifeless: This is re: syntheizing a root history? | 01:40 |
| lifeless | yes | 01:40 |
| lifeless | the InterDifferingSerializer wasn't doing the same thing as the reconcile code looks for | 01:40 |
| lifeless | fetch may be doing something subtley different again | 01:40 |
| lifeless | I want to squash it solidly and permanently | 01:41 |
| lifeless | so if you can think of other dimensions I should be testing across, or other values in the current space I should be checking, that would be grand | 01:49 |
| beuno | lifeless, you should try and hang out during european working hours with developers | 01:52 |
| beuno | working with bzr for the past month or two has been an enourmous pain in the ass | 01:52 |
| beuno | I branch about a dozen branches a day | 01:53 |
| beuno | maybe in one of them I can use the smart server | 01:53 |
| beuno | the rest, sftp | 01:54 |
| beuno | so basically it now takes about 7 times more to get something to review | 01:54 |
| lifeless | beuno: yes, I really appreciate that. Note the difference between unreleased and released! | 01:54 |
| beuno | lifeless, 1.13? 1.14? | 01:54 |
| lifeless | 1.13 doesn't suffer bugs pulling | 01:54 |
| lifeless | I need to grab some food, back in 15 | 01:55 |
| beuno | no, it creates broken branches | 01:55 |
| beuno | if all of Canonical is going to be dogfooding bzr, we need more responsivness | 01:57 |
| beuno | and that includes in a big part, better communication | 02:02 |
| emmajane | beuno, you're so radical! :) | 02:04 |
| beuno | :) | 02:07 |
| beuno | hi emmajane | 02:07 |
| * emmajane smiles and waves | 02:07 | |
| * beuno is grumpy | 02:08 | |
| * emmajane grins. | 02:08 | |
| emmajane | I'm *shocked* | 02:08 |
| lifeless | beuno: so does 1.12 | 02:09 |
| emmajane | You may find humour in this: http://twitter.com/mmurray/status/1698763594 | 02:09 |
| lifeless | beuno: and 1.11 | 02:09 |
| lifeless | beuno: etc | 02:09 |
| lifeless | beuno: once lp gets the hotfix, 1.13 pushing to bzr+ssh won't create broken branches | 02:09 |
| lifeless | mwhudson: which reminds me, ^ | 02:10 |
| emmajane | beuno, apparently I'm getting a little soft in my old age. :) | 02:10 |
| beuno | lifeless, right, and no good communication with all the teams as to how to avoid this has been made | 02:10 |
| lifeless | beuno: what has been unclear; the bugs in question have good summaries, they've been the primary focus to fix, but they are not simple things to fix | 02:10 |
| beuno | lifeless, as well as not deploying the script to fix this | 02:10 |
| thumper | is 1.13.2 in jaunty-updates? | 02:11 |
| beuno | as well as not cherrypicking a version that warns people when creating the broken branches | 02:11 |
| lifeless | beuno: ?!?!?! | 02:11 |
| lifeless | beuno: such a version would equally well not create broken branches | 02:11 |
| lifeless | beuno: and we have - 1.13.2 is such a version | 02:11 |
| beuno | lifeless, and the people who don't have 1.13.2? | 02:12 |
| beuno | they continue to create broken branches | 02:12 |
| lifeless | beuno: will, like the people who have 1.12 upload branches with insufficient data; the code team are looking at how to fixup those branches post-push at the moment | 02:12 |
| lifeless | beuno: there are 6 separate releases *all of which* will create the ACF situation | 02:13 |
| beuno | lifeless, I understand | 02:13 |
| beuno | now | 02:13 |
| beuno | you have to understand | 02:13 |
| beuno | that the end result | 02:13 |
| beuno | is that it's a pain in the ass to work on a daily basis | 02:13 |
| lifeless | why didn' you downgrade to 1.13, the current release at the time? | 02:14 |
| beuno | we *could* have told everyone STOP USING 1.13 NOW | 02:14 |
| thumper | lifeless: the code treatment is likely to be "upgrade" | 02:14 |
| beuno | because I wanted to actually help fix the problem | 02:14 |
| beuno | and, as it proved | 02:14 |
| lifeless | beuno: once we know the bug, suffering doesn't help fix it - once a fix is prepared testing the fix is good and helpful | 02:14 |
| beuno | being on bzr.dev helped bubble up the NoRevisionPresent problem | 02:14 |
| beuno | we have a policy of using bzr nightlies in most teams | 02:15 |
| beuno | to help development | 02:15 |
| beuno | replying "you should be using releases" is really not good for anyone | 02:15 |
| lifeless | beuno: right, which is good. But when there is an issue in trunk you have to be willing to revert to stable, which has been QA'd. Bugs take time to fix. | 02:15 |
| beuno | lifeless, no, telling people how to avoid making it worst, and making sure a stop-gap measure is in place ASAP is the way to go | 02:16 |
| lifeless | beuno: I'm not saying 'change your policy to be 'use stable'', I'm saying 'when a nightly breaks, report a bug and switch to stable until its fixed' | 02:16 |
| beuno | you have a script that fixes broken branches | 02:16 |
| lifeless | beuno: yes, which is on the bug | 02:16 |
| beuno | lifeless, right, which is basically as if it didn't exist for most people not following bzr development | 02:16 |
| beuno | that script should be deployed already | 02:16 |
| lifeless | beuno: you're really confusing me, you're jumping all over the place with different, largely unrelated things | 02:16 |
| beuno | and/or in a plugin | 02:17 |
| beuno | lifeless, maybe. I'm just saying, almost 2 months of brokeness, no matter what the reasons are, is very bad | 02:17 |
| lifeless | beuno: see above, the code team are looking at running the script, harass thumper :) | 02:18 |
| thumper | lifeless: we may run the script of the existing ones, and reject old clients, but we are not going to run the script post push on everything | 02:18 |
| lifeless | beuno: we try to keep trunk as solid as possible, but sometimes this will happen. Running trunk *has risks*. We certainly appreciate people doing that and giving feedback, but don't be masoschists when there is a problem. | 02:18 |
| beuno | lifeless, you guys need to coordinate | 02:19 |
| beuno | not me | 02:19 |
| lifeless | beuno: when edge breaks, people use production | 02:19 |
| beuno | make sure the code team runs it | 02:19 |
| lifeless | beuno: we *are coordinating*, but you're the one going critical here | 02:19 |
| beuno | because users don't care on who's plate it is | 02:19 |
| beuno | lifeless, yes. Almost 2 months, and still broken. Sounds pretty critical to me. | 02:20 |
| lifeless | beuno: when a user chooses to run crack of the day, they need to be making an informed choice | 02:20 |
| lifeless | beuno: go get some sleep or something. | 02:20 |
| lifeless | beuno: we didn't have the fix script 2 months ago | 02:20 |
| beuno | lifeless, I'm just saying something in the process needs to be improved | 02:21 |
| lifeless | beuno: what precisely? We landed the code on the 17 march, in the 1.14 cycle | 02:21 |
| lifeless | 1.14 released with the bug fixed. | 02:21 |
| lifeless | lp is running 1.14 and putting together stuff to fix up existing branches | 02:22 |
| beuno | lifeless, step zero is to communicate better | 02:22 |
| beuno | when something like this happens | 02:22 |
| lifeless | beuno: I asked about that before and got told about nightlies instead | 02:22 |
| beuno | go in, and tell everyone what to do | 02:23 |
| beuno | otherwise, you have half the people in 1.13, creating broken branches | 02:23 |
| lifeless | beuno: they should stay on 1.13 during that period | 02:23 |
| beuno | and the otgher half suffering with 1.14 | 02:23 |
| lifeless | beuno: because 1.13 1.12 1.11 1.10 1.9 1.8 1.7 1.6 all create broken branches | 02:23 |
| beuno | lifeless, don't tell me | 02:23 |
| lifeless | we put it in the bug | 02:24 |
| beuno | tell the 70-ish developers cursing every time they have to review someone's branch | 02:24 |
| beuno | lifeless, it turns out, not everyone reads all bugs in Launchpad | 02:24 |
| lifeless | beuno: they don't lookup the symptoms when they encounter a problem ? | 02:24 |
| beuno | lifeless, no, they ask around until someone unblocks their work | 02:25 |
| beuno | people get fed random recipies | 02:25 |
| beuno | which make problems worst | 02:25 |
| lifeless | please be a little more concrete. Are you saying blog? mail bzr-announce? mail bzr-dev ? (which we did, I think) | 02:25 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/354036 | 02:25 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] | 02:25 |
| lifeless | that bug was *reported* april 3rd | 02:25 |
| lifeless | one month | 02:25 |
| beuno | lifeless, I think this merits a blog post with the details + email to warthogs | 02:26 |
| lifeless | I get your frustration, but you're not actually helping much right now. Better communication - *how*. What forum is there for 'users of unreleased code' that will get 'everyone' which seems to be your gold standard for better communication | 02:26 |
| SamB | lifeless: hitting them upside the head with a ... hmm ... copy of the Linux Kernel, on paper? | 02:27 |
| beuno | lifeless, for Canonical folks, warthogs | 02:27 |
| lifeless | SamB: that would certain get their attention, if they remember the incident through the retrograde amnesia that will ensue | 02:27 |
| SamB | lifeless: could use just a small fraction of it, then | 02:28 |
| beuno | lifeless, and a blog post on planet | 02:28 |
| lifeless | beuno: It seems to me like we have a bunch of people running trunk that aren't tracking the project; this is like running Ubuntu's devel version without being on Ubuntu-devel - its not that good an idea. | 02:28 |
| lifeless | *things happen* during development. | 02:29 |
| beuno | lifeless, it isn't when it's a company policy | 02:29 |
| lifeless | beuno: policy doesn't change risk | 02:29 |
| lifeless | beuno: are you on ubuntu-devel? I certainly am | 02:29 |
| beuno | lifeless, I'm everywhere | 02:29 |
| beuno | but that's not the point :) | 02:30 |
| * SamB only runs bzr.dev because jelmer is always telling him to pull it ;-P | 02:30 | |
| lifeless | beuno: I think it rather is | 02:30 |
| beuno | lifeless, you don't really expect all developers to track bzr's development? | 02:30 |
| lifeless | we can certainly mail warthogs about the current status of this, now and in future. | 02:30 |
| beuno | I understand how hard this is | 02:30 |
| lifeless | beuno: I don't expect people to track *trunk* and not be at least following something [perhap bzr-announce?] to ensure they can be communicated with | 02:31 |
| lifeless | we have a group for launchpad beta users | 02:31 |
| SamB | beuno: who made a policy like that? | 02:31 |
| lifeless | I assume everyone in the company is in that group | 02:31 |
| lifeless | SamB: Canonical has a general dogfood policy - where we create something, we use it ourselves | 02:31 |
| beuno | lifeless, sure, we may have to adjust things | 02:31 |
| SamB | lifeless: oh, is he in canonical? | 02:31 |
| lifeless | SamB: (use it in beta and release at minimum), to improve quality | 02:31 |
| lifeless | SamB: we hired beuno, yes | 02:31 |
| SamB | ah. | 02:31 |
| SamB | must have missed that | 02:32 |
| lifeless | beuno: you need to communicate better :P | 02:32 |
| SamB | maybe you should have a company-wide email list or something | 02:32 |
| * beuno grins | 02:32 | |
| beuno | SamB, we have like 60 mailing lists | 02:32 |
| lifeless | SamB: we do, but this issue is equally applicable to folk outside the company tracking trunk | 02:32 |
| SamB | lifeless: yeah. | 02:32 |
| === gorozco is now known as p4tux | ||
| jelmer_ | maybe you need to do more cross-posting >-) | 02:32 |
| SamB | maybe! | 02:32 |
| SamB | okay, so what's this list I should be on but aren't? | 02:33 |
| lifeless | beuno: So I think two things; one is the policy should be more clear about what to do when there is an issue - ensure there is a bug, downgrade to release, get on with your work. | 02:33 |
| lifeless | SamB: bazaar@lists.canonical.com is the current list that issues with trunk are discussed on | 02:33 |
| beuno | lifeless, if bzr breaks something so critical, I expect the team to actively engage it's major users, no matter who they are | 02:33 |
| beuno | lifeless, yes, a big part of it is policy | 02:33 |
| SamB | hmm. | 02:34 |
| beuno | which we need to coordinate better | 02:34 |
| beuno | I'm sorry to jump out of this one, but I *really* need food | 02:34 |
| SamB | lifeless: that's way too high-traffic for me to actually follow | 02:34 |
| lifeless | beuno: secondly, perhaps we should have another list/lp team/whatever where people that are tracking trunk to contribute, but not interested in discussing bzr at all, should subscribe to | 02:34 |
| * emmajane offers beuno some birthday cake. | 02:35 | |
| lifeless | SamB: yes, and even if it was just regular users I think it would be too | 02:35 |
| lifeless | SamB: bzr is actually fairly popular :P | 02:35 |
| poolie | lifeless: spiv is away sick today | 02:36 |
| emmajane | SamB, did you know you can ignore a lot of the messages? There are subscription options that make the list a lot more manageable. | 02:36 |
| lifeless | poolie: ah | 02:36 |
| emmajane | SamB, I also sort by thread and *ahem* delete a lot of the stuff that's over my head. | 02:37 |
| emmajane | SamB, Filters help too. I only look in my "bazaar" folder when I've got extra energy. | 02:38 |
| poolie | lifeless: since andrew is away and since beuno reports it's hurting people a lot, would it make sense for you to work on bug 360791 ? do you have enough of the state? | 02:39 |
| ubottu | Launchpad bug 360791 in bzr/1.14 "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress] https://launchpad.net/bugs/360791 | 02:39 |
| lifeless | poolie: I can acquire that state; do you know if spiv has stuff in-flight that I should get off him? | 02:40 |
| lifeless | poolie: I want to finish the current patch first, as its nearly done. | 02:40 |
| poolie | he was still working on it yesterday | 02:40 |
| poolie | he's apparently still somewhat alive so you could perhaps call him briefly | 02:40 |
| lifeless | poolie: and is also quite critical, given it blocks people upgrading accurately to rich roots - its critical path for bbc transition | 02:41 |
| poolie | right, i know | 02:41 |
| lifeless | I propose that I finish the current patch to avoid thrashing; and ring him when I'm done to ensure I have his in-progress work. | 02:42 |
| abentley | lifeless: I don't know what "moved" means. | 02:42 |
| lifeless | abentley: old tree: '' is ROOT_ID, 'child' is 'my-root'. new tree: '' is 'my-root' | 02:42 |
| lifeless | abentley: so 'my-root' has moved from 'child' to ''. | 02:43 |
| SamB | emmajane: I do subscribe to the list, but I never really look at it unless either someone tells me to or ... well, I can't think of another reason ;-) | 02:44 |
| emmajane | SamB, do you have the list filters on so that you don't get the code-y things? | 02:44 |
| emmajane | SamB, MERGE and something else can be filtered out IIRC | 02:44 |
| abentley | lifeless: I can't think of any more cases. | 02:44 |
| SamB | hmm, yeah, merge would be easy to filter out | 02:44 |
| lifeless | abentley: cool, thanks. | 02:44 |
| emmajane | SamB, check the mailman page. There are some built-in options for the list. | 02:45 |
| SamB | but shouldn't there be a list for really important issues to be announced on? | 02:45 |
| lifeless | we have bazaar-announce | 02:45 |
| emmajane | SamB, it's version control. Everything is important. :) | 02:45 |
| lifeless | but I would expect packagers and release-only users to perhaps be unhappy about issues with unreleased code going there | 02:46 |
| SamB | I'm thinking bugs where your data gets messed up but you don't know until way later | 02:46 |
| SamB | lifeless: it also doesn't sound dangery enough | 02:46 |
| SamB | bazaar-warn, maybe? | 02:46 |
| lifeless | I'd really rather not call a list that ;) | 02:46 |
| emmajane | bazaar-omgwtfbbq? | 02:47 |
| SamB | bazaar-bleed? | 02:47 |
| lifeless | emmajane: :) | 02:47 |
| emmajane | bazaar-yourerunningtrunkyoushouldknowbetter? | 02:47 |
| SamB | bazaar-oh-great | 02:48 |
| emmajane | bazaar-SRLSY? | 02:48 |
| * emmajane goes back to her bazaar-scotch. :) | 02:48 | |
| * SamB wonders what the easiest way to run a program in a Linux kernel under a debugger is ... | 02:50 | |
| SamB | (that is, the kernel is under the debugger ...) | 02:50 |
| lifeless | hmmm, I have load 11 | 02:51 |
| lifeless | but no disk and the system is snappy... anyone else seeing this on jaunty? | 02:51 |
| SamB | what is this load thing? | 02:52 |
| SamB | is it possibly a highly-bogus figure? | 02:52 |
| AfC | SamB: load := number of processes in the runable state | 02:52 |
| SamB | that sounds pretty bogus to me | 02:53 |
| SamB | (once it starts to average more than 1) | 02:53 |
| fullermd | All metrics are bogus :p | 02:53 |
| SamB | yeah, but that sounds more bogus than bogomips! | 02:53 |
| fullermd | As a measure of contention for CPU, load average is often a decent rule of thumb check. | 02:54 |
| fullermd | Mind, by the time it hits 3000 or so, it starts getting too expensive to calculate to be worthwhile... | 02:54 |
| SamB | it doesn't account for niceness or anything though | 02:55 |
| lifeless | AfC: linux also includes procs waiting on IO | 02:55 |
| AfC | lifeless: I didn't know that. Huh. Thanks! | 02:55 |
| fullermd | Nor for network or disk IO, or memory pressure, or any number of other things. But then, defining something that broad that distills to a single number is somewhat more difficult. | 02:56 |
| lifeless | http://en.wikipedia.org/wiki/Load_(computing) | 02:56 |
| * SamB wishes top showed IO utilization ... | 02:56 | |
| lifeless | SamB: iotop | 02:56 |
| * fullermd looks at his top which DOES have an IO showing mode... | 02:56 | |
| fullermd | (of course, assigning IO to a particular process isn't a faultless process either) | 02:57 |
| SamB | fullermd: I meant in each row | 02:57 |
| SamB | or did you also? | 02:57 |
| fullermd | Yah. | 02:57 |
| fullermd | PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND | 02:57 |
| SamB | what top is that? | 02:57 |
| SamB | or, er, how do you get that? | 02:57 |
| lifeless | bsd :) | 02:57 |
| SamB | oh | 02:57 |
| SamB | pooh | 02:57 |
| SamB | anyway, I know it's not faultless, but it's nice to know *A* process that needs the IO done ;-) | 02:58 |
| * igc food | 03:03 | |
| lifeless | SamB: try iotop out | 03:03 |
| === timchen1` is now known as nasloc__ | ||
| wgrant | Why would I be getting a mismatched rich-root support error when attempting to reconfigure --standalone? | 03:06 |
| lifeless | bug something or other | 03:11 |
| lifeless | reconfigure doesn't preserve format | 03:11 |
| mwhudson | jelmer_: so you fixed a memory usage issue you say? | 03:20 |
| mwhudson | oh nm | 03:21 |
| mwhudson | https://code.edge.launchpad.net/~jelmer/openoffice/hosted now has over 250k revisions :) | 04:14 |
| lifeless | nice | 04:15 |
| mwhudson | and codebrowse continues to somewhat work | 04:16 |
| Peng_ | It somewhat works? That's somewhat good to know. :P | 04:42 |
| === BlackKnight is now known as UdontKnow | ||
| * mwhudson reads planet bazaar, becomes hungry | 05:06 | |
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| vila | hi all | 07:12 |
| vila | Argh, no wonder nobody reviewed my payches.... mail don't go out since last saturday :-( | 07:15 |
| poolie | hello vila | 07:25 |
| poolie | igc, what's the reasoning behind copying HACKING.txt around when building the docs? | 07:26 |
| igc | poolie: the doc gets built & copied as a full tree, e.g. http://doc.bazaar-vcs.org/latest/developers/index.html | 07:35 |
| poolie | i guess what i meant is | 07:36 |
| poolie | the rest source lives in doc/developers/HACKING | 07:36 |
| poolie | but the html output is sent to doc/en/developer-guide/HACKING.html | 07:37 |
| poolie | i guess this is just for historical reasons | 07:37 |
| igc | poolie: I'm happy for the rest source to move | 07:37 |
| poolie | done | 07:37 |
| poolie | thanks | 07:37 |
| igc | poolie: it location is historical | 07:37 |
| poolie | i thought so | 07:38 |
| igc | poolie: once upon a time before we had the nice catalogs we do now, I guess the source location was more important | 07:38 |
| igc | poolie: now I'd expect most developers to find the html easily enough | 07:39 |
| poolie | i've just moved the source to be in the same location as the html to avoid minor confusion | 07:39 |
| poolie | i think i once started editing the wrong copy of the text file | 07:39 |
| igc | poolie: cool. Thanks. | 07:40 |
| poolie | it's all fine now though, thanks | 07:40 |
| lifeless | hi vila | 08:25 |
| vila | lifeless: hi | 08:26 |
| * igc dinner | 09:41 | |
| Lo-lan-do | Hi all | 09:44 |
| Lo-lan-do | Is there a way to get bzr to "forget" the submit or parent branch? | 09:45 |
| Lo-lan-do | (Apart from editing the .bzr/branch.conf, that is) | 09:45 |
| lifeless | Lo-lan-do: remember a new one | 09:53 |
| poolie1 | night all | 09:59 |
| Lo-lan-do | Hm. Yes, that would work, of course. | 10:00 |
| Lo-lan-do | Except it needs some non-transparent operation to happen, doesn't it? | 10:00 |
| Lo-lan-do | Such as merging (for the submit branch) or... I don't even know how to remember a new parent branch. | 10:01 |
| intellectronica | hi, trying to branch from an LP-hosted branch using bzr from the nightlies PPA, i get "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")". any ideas? | 10:26 |
| lifeless | intellectronica: use nosmart+ before the url or an sftp url | 10:27 |
| lifeless | intellectronica: there is a bug in older bzr's that causes branches to individually generate that message | 10:27 |
| intellectronica | oh right, so if i re-upload the branch with a new bzr it will be ok? | 10:28 |
| lifeless | intellectronica: or you can run te fix script | 10:40 |
| lifeless | https://bugs.edge.launchpad.net/bugs/354036 | 10:41 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] | 10:41 |
| lifeless | there are a couple of bugs related to streaming at the moment; in general ifyou can't get a brnach use nosmart:+ or a http or sftp url. | 10:41 |
| maxriskfactor | i have been trying to use bzrlib to list the files under a working directory, can someone help me in this reguard | 11:22 |
| === jelmer_ is now known as Guest54966 | ||
| awilkins | jelmer: Did bzr-gtk get upgraded to rich-root? | 12:00 |
| jelmer | awilkins: yep | 12:00 |
| awilkins | aha. | 12:00 |
| awilkins | jelmer: 1.9 or 1.14? | 12:01 |
| awilkins | Hmmph, info says "unnamed". V.unhelpful. | 12:02 |
| jelmer | awilkins: either should work | 12:02 |
| jelmer | awilkins: I upgraded to 1.9-rich-root | 12:02 |
| awilkins | I'll stick to 1.9, my users are still on 1.13 | 12:02 |
| jelmer | lifeless: ping | 12:03 |
| jelmer | awilkins: I think 1.14 only matters for the working tree format anyway | 12:03 |
| awilkins | I only really use bzr-gtk for gconflicts now | 12:08 |
| awilkins | And a local patch of it, at that | 12:09 |
| jelmer | awilkins: no viz? | 12:11 |
| awilkins | I use qlog for that | 12:11 |
| awilkins | How's viz now? | 12:11 |
| jelmer | ah | 12:11 |
| jelmer | viz is still the same | 12:11 |
| jelmer | what's better about qlog? | 12:11 |
| awilkins | Let me try viz again for a mo and I'll think about it | 12:11 |
| awilkins | Ok (silly) : qlog looks more native on win32 and has font smoothing, etc | 12:12 |
| jelmer | ah, of course. I'd forgotten you were on win32 | 12:13 |
| awilkins | (practical) qlog has a "files that changed" pane from which you can trigger a file diff | 12:13 |
| awilkins | It also has expansion of merge points | 12:13 |
| awilkins | Over half the width is consumed with the DAG on viz, on qlog you only get this if you expand a few nodes | 12:14 |
| james_w | double click a revision to see the changes | 12:15 |
| awilkins | qlog could do with a heck of a lot more context options (which viz seems to have in menus) | 12:15 |
| awilkins | Both of them need to be able to be configured to use external diff utils | 12:16 |
| awilkins | When considering this sort of thing I think TortoiseSVN is a great place to start | 12:17 |
| awilkins | You can't go too far wrong just ripping off their feature sheet | 12:17 |
| awilkins | Maybe I should post some thoughts on the list when I have time ; I've used TSVN a hell of a lot, I admin our in-house SVN repositories. | 12:20 |
| awilkins | There are things like the filter box - needs a path filter option (even if it would be slow although I'm not sure how slow it is on the newer branch formats now) | 12:21 |
| lifeless | jelmer: pong; just fixing raid controller software, so you'll only get a little bit of attention | 12:25 |
| jelmer | lifeless: does PQM ignore duplicate submissions? | 12:28 |
| lifeless | jelmer: GPG dups yes, others no, but if no changes are found it bounces the second | 12:29 |
| jelmer | lifeless: ok, then it'll bounce - thanks | 12:29 |
| ronny | moin | 12:39 |
| jelmer | hey ronny | 12:41 |
| ronny | sup | 12:41 |
| ronny | older bzr versions still arent easy_install-able | 12:42 |
| zyga | hello, I wrote a simple plugin that allows for filtering by changeset author | 12:43 |
| jelmer | ronny: I think LarstiQ was looking into that | 12:43 |
| jelmer | LarstiQ: ^ | 12:43 |
| zyga | I did it in a pretty hacky way because I could not find any better APIs to do it | 12:43 |
| zyga | I removed log._make_search_filter from available log adapters | 12:43 |
| zyga | and then added my own _make_author_filter function that understands author: prefix of the search argument | 12:44 |
| zyga | I was wondering if there is a better way to do it | 12:44 |
| jelmer | igc: you might want to talk to igc when he's around, I think he did a lot of work on log recently | 12:44 |
| zyga | basically I'd like to have "bzr log | grep author" that is smarter | 12:44 |
| zyga | can anyone please point me to some API's/people that could show the way? | 12:45 |
| Lo-lan-do | zyga: I think jelmer's last message was for you :-) | 12:45 |
| jelmer | zyga: one way is to just register a new log formatter that only shows revisions by a particular author | 12:45 |
| zyga | Lo-lan-do: oh, thanks - I'll look for igc then | 12:46 |
| zyga | hmm | 12:46 |
| zyga | hmm :-) | 12:46 |
| zyga | I'll look into that, maybe it's easier than I though | 12:46 |
| Lo-lan-do | jelmer: Does the current lp:bzr-git depend on some dulwich version newer than 0.2.0? | 12:48 |
| zyga | that's bad in one way though: you loose all the --long --short, etc options | 12:48 |
| zyga | I really thought that the search filter was a good idea except for lack of sensible API for adding new search terms (I had to hijack the whole search to do it) | 12:48 |
| igc | zyga: An improved search filter is the right general approach | 12:50 |
| igc | zyga: see http://bazaar-vcs.org/Roadmap/Log as well | 12:51 |
| igc | zyga: basically, we need: | 12:51 |
| igc | 1. some agreed search language | 12:51 |
| zyga | igc: hi, | 12:51 |
| igc | 2. a parser that converts it into a compiled query object | 12:52 |
| igc | 3. a search filter that takes that query object and returns matching results | 12:52 |
| jelmer | Lo-lan-do: yeah, it depends on dulwich trunk | 12:53 |
| zyga | igc: right | 12:53 |
| igc | #3 can probably be done first | 12:53 |
| jelmer | Lo-lan-do: bzr-git 0.2.0 and dulwich 0.2.0 should work together | 12:53 |
| zyga | igc: maybe 3 can be done now as a plugin | 12:54 |
| Lo-lan-do | jelmer: I see. I just found out that I could bzr branch git://something (I didn't manage to branch a local repo), I'll experiment with that before trying to upgrade. | 12:54 |
| zyga | along with a new log command that uses it | 12:54 |
| zyga | (logging is pretty complex though) | 12:54 |
| zyga | as for 1 and 2 that can be simplified for now as long as we keep api for 3 stable and keep it off the bzr.dev | 12:55 |
| zyga | (this way nobody has expectations on stability of the UI) | 12:55 |
| zyga | and a sensible thing can be though out later | 12:55 |
| igc | zyga: hmm - I'd like #3 to be core code; then plugins can experiment with various languages for building the queries | 12:56 |
| igc | zyga: a plugin to try out #3 is fine though | 12:56 |
| jelmer | Lo-lan-do: local repositories should also work | 12:57 |
| zyga | igc: yes that's sensible - I was thinking about devloping the whole thing as a plugin (it's easier for me) and then keeping 1 and 2 unstable until some brainstorm decides about them since they are UI features | 12:57 |
| Lo-lan-do | jelmer: Maybe I'm doing something wrong then, but I get an AttributeError: 'Repo' object has no attribute 'open_index' | 12:57 |
| jelmer | Lo-lan-do: that means you need a newer dulwich | 12:58 |
| jml | lifeless: is the presence of a '.' in an hpss method name a necessary and sufficient indicator that that method is *not* a VFS call | 12:59 |
| jml | ? | 12:59 |
| igc | zyga: sure | 12:59 |
| Lo-lan-do | jelmer: Right. So I'll keep trying out what I currently have and upgrade dulwich when I find myself familiar with how things work. | 12:59 |
| jml | actually, I'll throw that question to the whole channel | 12:59 |
| zyga | igc: I'll hack on a copy of cmd_log and craft a simple search support on that | 12:59 |
| zyga | when author search works again I'll publish the code so that someone can have a look at it | 13:00 |
| zyga | thanks for the insight and help | 13:00 |
| igc | zyga: why do you think you need a custom cmd_log? | 13:00 |
| zyga | how would you add new features to cmd_log? | 13:00 |
| igc | zyga: we're just extending the -s option with a smarter string, yes? | 13:01 |
| igc | zyga: take a look at the bzr-search plugin | 13:01 |
| zyga | igc: ok wait | 13:02 |
| igc | zyga: from memory, it provides a custom implementation of the search filter just like you need to | 13:02 |
| zyga | yeah I just noticed it's mentioned in cmd_log docstring | 13:02 |
| jml | Answer: no | 13:02 |
| zyga | igc: argh, it requires a built index | 13:07 |
| zyga | igc: that's bad - but I'll look at the API | 13:07 |
| igc | zyga: you don't need to do anything as complex as bzr-search, just reuse the pattern it uses to patch in it's own search filter | 13:08 |
| * jml runs a full selftest | 13:09 | |
| jml | how long does it take these days? | 13:09 |
| bob2 | FOREVER | 13:10 |
| zyga | igc: hmm, it's doing something similar as I did but with additional trick :-() | 13:11 |
| zyga | igc: it removes the original log adapters but instead of totally loosing them it calls them in their own adapter as a fallback | 13:12 |
| jml | hmm. | 13:12 |
| jml | I don't have forever. | 13:12 |
| zyga | igc: but I still don't get something | 13:12 |
| zyga | igc: how do I extend log to add search without new cmd_log2? | 13:13 |
| igc | zyga: cmd_log should be calling into the log adapter "pipeline" ... | 13:15 |
| igc | zyga: changing the pipeline ought to be enough IIUIC | 13:15 |
| zyga | It already does | 13:15 |
| zyga | but how to add new options (search query) | 13:16 |
| igc | zyga: ah | 13:16 |
| igc | I don't think you want a new option | 13:16 |
| igc | just extend the meaning of the -s value | 13:16 |
| igc | e.g. ... | 13:16 |
| zyga | -s ? where is it defined | 13:17 |
| igc | bzr log -s "author:me" ... | 13:17 |
| zyga | (I'm based on 1.14.1 | 13:17 |
| * jml just sent a simple patch to the list. | 13:17 | |
| lifeless | jml: --parallel=fork | 13:18 |
| lifeless | jml: also, no, its not in principle, but it may be enough for now, and please file a bug that you want to be able to know reliably. | 13:18 |
| jml | lifeless: I figured something else out instead. | 13:18 |
| jml | lifeless: see the patch I just sent to the list | 13:19 |
| jml | but maybe not now, since I'm going to prepare a hot chocolate and retire for the evening. | 13:19 |
| lifeless | jml: remind me tomorrow and it will get my full attention | 13:19 |
| igc | zyga: sorry - I meant --message or -m | 13:20 |
| jml | lifeless: will do. | 13:20 |
| zyga | ah | 13:20 |
| zyga | that's sensible | 13:20 |
| zyga | I'll look into it | 13:20 |
| igc | zyga: we can always alias --message to --search later | 13:21 |
| zyga | right | 13:21 |
| lifeless | zyga: bzr-search uses -m too | 13:25 |
| zyga | yeah I'm on to it - just wait for a moment | 13:25 |
| lifeless | zyga: I'd love to change the meaning of -m to be a nicer language than regex, it limits bzr-search a lot | 13:25 |
| === thekorn_ is now known as thekorn | ||
| zyga | what is the python version all bzr code should run on? | 13:36 |
| zyga | 2.4? | 13:36 |
| jelmer | zyga: yep | 13:38 |
| lifeless | zyga: for bzr core, 2.4. plugins can choose to support only newer versions if they want, but we like it when they support 2.4 and up. | 13:39 |
| igc | night all | 13:42 |
| lifeless | gnight igc | 13:43 |
| vxnick | has anyone any experience integrating bzr with redmine (http://redmine.org) | 13:56 |
| jelmer | igc: thanks for the reviews | 13:56 |
| jelmer | 'night igc, lifeless | 13:56 |
| jelmer | beuno: ping | 14:21 |
| beuno | jelmer, hi | 14:22 |
| jelmer | beuno: What happened to your plugin management code? | 14:22 |
| lifeless | jelmer: I wrote bzr-plugin-info which is meant to seed a plugin db | 14:23 |
| beuno | jelmer, I never finished it, unfortunetely. Code is out there (or I could push it), but it's diverged by maybe a year by now :) | 14:24 |
| jelmer | beuno: :-/ | 14:25 |
| jelmer | lifeless: it's a bit of a chicken-egg problem I guess | 14:26 |
| zyga | wooyt | 14:31 |
| zyga | igc: it works :-) | 14:31 |
| zyga | igc: the API is not perfect yet because it hardcodes all(...) but it's not far away from full-blown logic tree | 14:34 |
| zyga | igc: search terms are pluggable | 14:34 |
| zyga | igc: simple searching for properties like author is trivial to add | 14:34 |
| zyga | igc: I'd love to have a python-like logical expression parser: | 14:35 |
| zyga | something that could parse: | 14:35 |
| zyga | EXPR: EXPR and EXPR | EXPR or EXPR | not EXPR | 14:35 |
| zyga | EXPR: property | 14:36 |
| zyga | EXPR: property=value | 14:36 |
| zyga | right now I can do: bzr log -m author:someone | 14:36 |
| zyga | which works rather well :-) | 14:36 |
| liw | do you think it would be acceptable for "bzr add", when it walks the directory tree, to go through subdirectories in alphabetical order? this would make it easier to have a clue about how far it's gotten, for very large trees | 14:46 |
| james_w | liw: does "bzr add -v" print info about what is being added? | 14:48 |
| james_w | or you already have the info and you just want to know what is coming next? | 14:48 |
| liw | james_w, it prints the names it adds already, yes | 14:49 |
| liw | what I mainly want is to know how much longer this is going to take, of course | 14:49 |
| james_w | it may be that adding a sorted() call is easy | 14:49 |
| james_w | or it may be that it would not perform at all well | 14:49 |
| james_w | having full progress info is difficult though, as it requires two full tree walks, and the assumption that nothing changes between the two | 14:50 |
| liw | yeah, that's why I thought just sorting the list of directories would be good enough (for me) | 14:50 |
| jelmer | Is there some easy way to import an arbitrary file as a module in Python? | 14:52 |
| liw | jelmer, I think so | 14:52 |
| liw | jelmer, the imp module, I think | 14:53 |
| jelmer | liw: Ah, thanks | 14:53 |
| liw | hm, it's as if it is doing the directory tree twice anyway (I'm sure I've seen those directory names before) | 14:55 |
| Lo-lan-do | jelmer: My git.db is acurrently 152M, and I'm only "fetching revisions 4962/6104". Does that sound right? | 14:56 |
| lifeless | zyga: I rather like googles search syntax; it sounds like you are doing something similar - +1 to that :) | 15:04 |
| * ronny pokes LarstiQ | 15:04 | |
| jelmer | Lo-lan-do: Yeah, it can become pretty large | 15:07 |
| Lo-lan-do | The "bzr branch" seems to be slowing down pretty drastically, too. | 15:15 |
| liw | does 5+ gigabytes of RSS memory count as a big bzr process? | 15:17 |
| jelmer | liw: YES | 15:18 |
| jelmer | I mean, yes | 15:18 |
| jelmer | Didn't mean to shout :-) | 15:18 |
| jelmer | Lo-lan-do: For better performance try newer dulwich/bzr-git | 15:18 |
| liw | at least it's still running | 15:18 |
| jelmer | liw: what are you trying to do exactly? | 15:19 |
| liw | jelmer, I have a fever and a cold, so I am not able to do anything that requires a brain... so I'm being silly and torturing bzr | 15:19 |
| liw | by importing jaunty's unpacked source packages | 15:19 |
| liw | bzr has stopped printing out pathnames, I wonder if that means it's about to be done? | 15:21 |
| Lo-lan-do | bzr branch lp:dulwich says bzr: ERROR: bzrlib.errors.SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x9202fec> corrupt: sha-1 of reconstructed text does not match expected sha-1 | 15:24 |
| zyga | lifeless: I can do simple boolean logic over expressions but I'd like to hear some kind of agreement over what is really wanted | 15:25 |
| zyga | lifeless: I can publish my plugin soon (corporate env) | 15:25 |
| jelmer | Lo-lan-do: You've probably hit a bug in bzr-git | 15:27 |
| jelmer | vila: ping | 15:48 |
| vila | jelmer: pong | 15:48 |
| jelmer | vila: can you include a copy of the GPL in bzr-webdav? | 15:48 |
| jelmer | vila: (required for inclusion in Ubuntu) | 15:48 |
| Lo-lan-do | jelmer: "bzr --no-plugins branch http://people.samba.org/bzr/jelmer/dulwich/trunk/" fails similarly | 15:49 |
| jelmer | Lo-lan-do: Ah, this must be a bug I fixed recently | 15:51 |
| jelmer | Lo-lan-do: (dulwich is maintained in git but developed using bzr) | 15:51 |
| Lo-lan-do | Nice to know such a setup already works :-) | 15:51 |
| vila | jelmer: done and committed on lp | 15:52 |
| jelmer | vila: thanks | 15:52 |
| Lo-lan-do | jelmer: Is the reverse already possible (bzr repo accessed through git)? | 15:54 |
| Lo-lan-do | I guess it's the bzr-*-pack stuff, but I have no idea if/how it works :-) | 15:54 |
| Lo-lan-do | Also, in your setup, can you handle several branches? | 15:56 |
| jelmer | Lo-lan-do: you mean a git-compatible smart server that accesses bzr branches? | 16:00 |
| jelmer | Lo-lan-do: jc2k has done some work on that, I'm not sure what the current state of it is | 16:00 |
| jelmer | Lo-lan-do: I do have multiple branches, but can't access anything other than HEAD in git repositories (since bzr doens't support colocated branches yet) | 16:01 |
| liw | success! | 16:02 |
| liw | I did "bzr add" on the unpacked ubuntu jaunty source tree | 16:02 |
| liw | now let's see if commit works | 16:03 |
| jelmer | whoa :-) | 16:03 |
| Lo-lan-do | jelmer: Thanks. | 16:03 |
| liw | the add required about 8 gigabytes of RAM | 16:03 |
| Lo-lan-do | Jc2k: Ping (status of bzr-{send,receive}-pack?) | 16:04 |
| Lo-lan-do | liw: You're crazy. But it had to be tried :-) | 16:04 |
| Lo-lan-do | liw: Next step: try the same on Debian. | 16:04 |
| liw | Lo-lan-do, I've tried it on etch sources before, years ago, and bzr failed | 16:04 |
| Lo-lan-do | If bzr can handle that, it'll handle anything :-) | 16:05 |
| liw | ubuntu and debian should be on the order of magnitude the same size, shouldn't they? | 16:05 |
| Lo-lan-do | Possibly. I was under the impression that we had lots more crap^W"fringe packages" in Debian. | 16:07 |
| lifeless | liw: --development-rich-root? | 16:14 |
| liw | lifeless, yes | 16:20 |
| LarstiQ | ronny: hey, I still want to read the easy_install code to see if it can handle multiple indirections. I'm going to do that tomorrow (wednesday is my day off) | 16:20 |
| LarstiQ | ronny: if that fails, I'll take one of the other outlined measures | 16:21 |
| LarstiQ | ronny: so expect easy_installability tomorrow | 16:21 |
| exarkun | So I'm curious about how the revision data associated with a revision number in a particular branch can change over time | 16:30 |
| exarkun | Is there something I should read? | 16:30 |
| Lo-lan-do | exarkun: Revision numbers are just a convenience. What matters is the revision id. | 16:31 |
| Lo-lan-do | If a branch is overwritten, the revision numbers will overlap, but not the revids. | 16:32 |
| exarkun | But even if you don't overwrite a branch, then you still can't treat revision numbers as stable, right? | 16:32 |
| exarkun | Or is resolving divergence equivalent to overwriting a branch? | 16:33 |
| Lo-lan-do | You're right. If you pull from another branch, even if you only add revisions, you might change your numbers. | 16:33 |
| james_w | exarkun: if you only "merge" other branches then numbers will only be added | 16:34 |
| james_w | any numbers you currently have will not change | 16:34 |
| exarkun | thanks | 16:38 |
| ronny | LarstiQ: dont try to read easy_install, its a fucked up pain | 16:44 |
| dahoste | I have a bzr 'admin newb' question. I want to manage authentication for a shared repo similar to how I've done it with svn, namely via DAV in a <Location> block in apache, which lets me use things like either basic apache auth, or defer to LDAP, etc.. All of the bzr examples I'm seeing are using sftp, and I don't want to give full shell accounts just to grant write access to a bzr repo. I'm not seeing documentation for bzr that talks about how | 16:52 |
| dahoste | to administer auth for a repo. Can anyone point me to some relevant howto or something. Apologies if it's someplace obvious and I missed it. | 16:52 |
| liw | dahoste, you can a) use the bzr server mode ("bzr serve" I think, though I haven't done that myself); b) set up a "patch queue mananger" (PQM); or c) configure ssh for the accounts to only allow sftp | 16:56 |
| liw | dahoste, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server might be useful | 16:56 |
| liw | dahoste, there may be other ways, too, but I'm too ignorant | 16:58 |
| === dereine[OFF] is now known as dereine | ||
| dahoste | liw, roger that. (a) isn't appealing, I want to get this working through apache. (b) probably will come into play - I like the PQM model. (c) doesn't work for me, since I don't want to muddy my user's auth with YetAnotherLogin - I want to get bzr access working alongside existing svn repos, and I have users with long-standing auth credentials used for svn (and other stuff -- some of it's LDAP). | 17:00 |
| dahoste | liw, I think I need to get smarter about the bzr writing via the http-webdav plugin. That might be the ticket. | 17:01 |
| dahoste | liw, this just struck me as a common 'migration from svn' issue, since a shared svn+http/s repo with users auth'd through apache is par for the course for svn. Figured surely there'd be an easy way to get the same usage working for bzr. | 17:03 |
| pygi | dahoste, what's wrong with using clue-bzrserver? | 17:29 |
| dahoste | pygi, possibly nothing. I'm not aware of it. Or wasn't... | 17:30 |
| a_c_m1 | can you clear the slate (so to speak) with anything thats not yet commited | 17:30 |
| a_c_m1 | e.g. i bzr add by mistake | 17:30 |
| Lo-lan-do | a_c_m1: bzr revert | 17:31 |
| pygi | dahoste, its bzr+http, but oh well :) | 17:31 |
| pygi | dahoste, I mean it still isn't perfect, but it works | 17:31 |
| a_c_m1 | Lo-lan-do: thanks :) | 17:31 |
| Lo-lan-do | a_c_m1: You can even use it on one particular file if you just want to revert that one. | 17:31 |
| dahoste | pygi, well... anything that lets me auth without having to hand out full shell accounts is a candidate as far as I'm concerned. | 17:32 |
| pygi | dahoste, ok, clue-bzrserver works then | 17:32 |
| pygi | did you already google it or? | 17:32 |
| dahoste | pygi, reading now... | 17:33 |
| === dahoste is now known as dahoste|away | ||
| Peng_ | jelmer: ping | 18:43 |
| Lo-lan-do | $ bzr help dpush | 18:51 |
| Lo-lan-do | Purpose: Push diffs into a foreign version control system without any | 18:51 |
| Lo-lan-do | Usage: bzr dpush [LOCATION] | 18:51 |
| Lo-lan-do | Without any what? | 18:51 |
| Lo-lan-do | Purpose? | 18:51 |
| jelmer | Peng_: pong | 18:52 |
| Peng_ | Heh. | 18:52 |
| jelmer | Lo-lan-do: that's fixed in 1.14 IIRC | 18:52 |
| Peng_ | jelmer: I thought so too, but it doesn't seem to be. | 18:52 |
| Lo-lan-do | Oh. I guess it's the "Bazaar-specific metadata." later on. | 18:52 |
| Peng_ | Lo-lan-do: Yeah. | 18:52 |
| Lo-lan-do | 1.14-2 here | 18:52 |
| Peng_ | Lo-lan-do: It doesn't push any of the metadata. This way your svn repo won't have tons of "bzr:" properties, but OTOH when you pull again bzr won't recognize it as a bzr revision. | 18:52 |
| Peng_ | jelmer: With lp:~jelmer/loggerhead/transport, why did you move the stat() in directory_ui? | 18:53 |
| Lo-lan-do | Thanks to jelmer, I have ceased doing dpush on SVN (bound branches work so much better). | 18:53 |
| Lo-lan-do | I was reading on dpush for git. | 18:53 |
| jelmer | Lo-lan-do: yeah, dpush works quite well for git atm | 18:55 |
| Lo-lan-do | Good to know, but since I collaborate with git users on several branches, I guess I'll have to either wait for the colocated branches or (my favourite) the git-{receive,upload}-pack stuff to work. | 18:57 |
| Lo-lan-do | In the meantime, we keep SVN as a pivot. | 18:58 |
| jelmer | Jc2k: ping | 18:58 |
| Lo-lan-do | No hurry... I'm about to go out for drinks. | 18:59 |
| Lo-lan-do | But I'll read the backlog when back :-) | 19:00 |
| jelmer | Peng_: Which stat? | 19:05 |
| Peng_ | jelmer: The one over the directory listing to make sure they're all directories. It used to be done to filter the list, but you moved it to only be done if Branch.open failed. Then I moved it back. | 19:07 |
| Peng_ | jelmer: Was it just to get rid of the list comprehension or to reduce the number of stat()s done or something else? | 19:11 |
| jelmer | Peng_: to reduce the number of stats, as we'd only do it in case something is not a branch now | 19:27 |
| Peng_ | jelmer: OK, I'll put it back, then. | 19:33 |
| Peng_ | Sorry. :\ | 19:36 |
| === zirpu2 is now known as zirpu | ||
| Jc2k | jelmer: pong | 19:45 |
| TDT | Hey all, I'm running into a weird issue that just came up today - I'm receiving this error: bzr: ERROR: Server sent an unexpected error: ('error', 'No module named bz2') -- I googled for this information, and didn't find anything. Does this have to do with compression when sending chunks over the net? | 19:52 |
| jelmer | Jc2k: hi | 19:53 |
| jelmer | Jc2k: we were just wondering what the status of bzr-*pack in bzr-git is atm, does it work? | 19:53 |
| jelmer | Jc2k: also, did you see my msg about hg-git picking up dulwich? | 19:54 |
| jelmer | vila: bzr-webdav is now in karmic | 19:56 |
| jelmer | vila: your http multi-auth patch is huge :-/ | 19:56 |
| LarstiQ | TDT: ehm, it is a bit surprising the standard bz2 module is missing from your python install? | 19:57 |
| Jc2k | jelmer: i saw your message and blogged it :) | 19:59 |
| Jc2k | jelmer: i dont know about the state of bzr-*-pack - it might have bit rot | 19:59 |
| Jc2k | jelmer: when i last played with it, it worked for git-only stuff | 19:59 |
| jelmer | Jc2k: ah, nice, haven't seen that yet | 20:05 |
| TDT | LarstiQ: Very surprising actually, especially since 3 machines, two if which I'm sure worked, suddenly don't...recompiling to see what happened. | 20:07 |
| LarstiQ | TDT: did they get upgraded? | 20:09 |
| * LarstiQ catches the tram | 20:11 | |
| TDT | LarstiQ: Fixed it, was a horribly stupid reason this was happening...didn't expect it to be a problem, but meh | 20:17 |
| orsonj | does bzr determine that a number of different files are identical and store them compactly in the repo? | 20:21 |
| Peng_ | orsonj: No. Well, the new disk format (development6-rich-root) does, IIRC. | 20:29 |
| orsonj | I might have to play with that. I have one situation where I have a bunch of files that are hard linked several times each | 20:35 |
| orsonj | The repo ended up taking up a lot more space than the actual files. | 20:36 |
| orsonj | Is there a way to remove files from the version history without bothering other versioned files? | 20:37 |
| orsonj | (aka to save space, this has been a space hogging experiment) | 20:37 |
| GaryvdM | No - by design - you can | 20:39 |
| === dahoste|away is now known as dahoste | ||
| GaryvdM | 't modify any old revisions | 20:39 |
| GaryvdM | sorry - enter instead of ' | 20:39 |
| orsonj | I only have a few revisions, so I'll just extract and rebuild without the large files. | 20:39 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| AmanicA | you may be able to filter them out with bzr-fastimport , but I don't really know how | 20:54 |
| AmanicA | orsonj: if you installed the bzr-fastimport plugin, see bzr help fast-import-filter | 21:01 |
| AmanicA | it seems to be able to do what you want | 21:01 |
| LarstiQ | or maybe just `bzr uncommit`, if it's recent history | 21:04 |
| Lo-lan-do | Jc2k: I think bzr-upload-pack does indeed suffer from bitrot or something: http://pastebin.com/d4b66f616 | 21:15 |
| Lo-lan-do | Um. I'm wondering why it's using the system-wide git plugin rather than the up-to-date one in ~/.bazaar | 21:16 |
| Lo-lan-do | Uninstalling the system-wide git plugin gives me a "ImportError: No module named git.server" | 21:19 |
| Lo-lan-do | Seems to me the local server.py isn't properly registered. | 21:19 |
| Lo-lan-do | jelmer: Any idea about that? | 21:19 |
| jelmer | Lo-lan-do: not off the top of my head | 21:37 |
| jelmer | Lo-lan-do: I'd have to look into it deeper, but I think there will be more issues like that atm | 21:38 |
| Lo-lan-do | Does "import bzrlib" suffice to load all plugins? | 21:38 |
| Lo-lan-do | An strace seems to indicate that the git plugin isn't loaded when bzr-upload-pack tries to import part of it. | 21:38 |
| jelmer | Lo-lan-do: you need 'from bzrlib.plugin import load_plugins; load_plugins()' to make sure all plugins are loaded | 21:40 |
| Lo-lan-do | I'm sending a patch your way | 21:45 |
| Lo-lan-do | It's not fixing the problem I pasted into the pastebin, but at least the version of server.py that gets used is the proper one. | 21:46 |
| jelmer | Lo-lan-do: ENOPATCH ? :-) | 21:54 |
| Lo-lan-do | bzr send failed to attach it? | 21:54 |
| Lo-lan-do | http://pastebin.com/f4ab696b5 it is then | 21:55 |
| jelmer | yeah, apparently | 21:55 |
| Lo-lan-do | This guest account isn't properly configured. It's reset at each reboot, and I don't open sessions with it, only su. | 21:56 |
| jelmer | Lo-lan-do: thanks, merged | 21:57 |
| Lo-lan-do | jelmer: How about http://pastebin.com/f69a8b139 ? | 21:59 |
| jelmer | Lo-lan-do: Yeah, that looks like a good idea :-) | 22:00 |
| jelmer | Lo-lan-do: pushed | 22:01 |
| Lo-lan-do | And before I go to sleep: http://pastebin.com/f1c569a76 is the current state I get and not a patch, but maybe it's an obvious problem to you? | 22:05 |
| jelmer | Lo-lan-do: we changed what some of the arguments / return values look like | 22:06 |
| jelmer | Lo-lan-do: something must've made us return a tuple | 22:07 |
| vila | jelmer: huge ??? | 22:08 |
| jelmer | vila: well, pretty large at least | 22:09 |
| mwhudson | jelmer: let me try that again: hi | 22:09 |
| jelmer | mwhudson: hey | 22:09 |
| mwhudson | (damn routers/isps) | 22:09 |
| mwhudson | jelmer: so a bzr-git question: how much ram/time would you expect an import of banshee into 1.9-rich-root to take? | 22:10 |
| poolie | hi all | 22:13 |
| vila | the main part (in auth_required) is due to reindenting a block... Anyway, I don't think it's large :) | 22:14 |
| vila | jelmer: a bit hackish, yes, but large, it's just an added loop and one more if :) | 22:14 |
| vila | jelmer: and thanks for webdav :) | 22:15 |
| jelmer | vila: I guess I should do more careful reading then :-) I skimmed over it only | 22:15 |
| jelmer | mwhudson: 200Mb RAM, < 30min I would say | 22:16 |
| * jelmer gives it a shot | 22:16 | |
| mwhudson | jelmer: i was seeing 1.8 gigs and >1 hour :) | 22:17 |
| mwhudson | but i may not have been using the updated code | 22:17 |
| jelmer | mwhudson: are you running dulwich trunk though? | 22:17 |
| vila | jelmer: haaa, that explains it then :) Unfortunately that part of the http implementation (auth) is the most obscure due to the urllib2 underlying design which requires resending the same request with the added header and *that* makes it really hard to follow | 22:17 |
| mwhudson | jelmer: well 0.2.1 or whatever it was | 22:17 |
| mwhudson | i hope :) | 22:17 |
| jelmer | yeah, that doesn't have a particular fix yet (iterobjects remembering *all* undeltified objects while walking a pack) | 22:18 |
| mwhudson | jelmer: it's possible i stuffed up and was using the old dulwich, i'll try agai | 22:18 |
| mwhudson | jelmer: oh | 22:18 |
| jelmer | mwhudson: I also just fixed a bug in the offset handling in dulwich/bzr-git | 22:19 |
| jelmer | mwhudson: which may corrupt repositories if you're not in UTC | 22:19 |
| mwhudson | a | 22:19 |
| mwhudson | h | 22:19 |
| jelmer | mwhudson: mainly matters for dpush though | 22:19 |
| mwhudson | jelmer: ok, pretty sure launchpad won't be doing that :) | 22:20 |
| thumper | mwhudson: but our users might :) | 22:21 |
| jelmer | one of the side effects is that some of the commits in dulwich are now in timezone "+0020" | 22:21 |
| mwhudson | jelmer: so is there a new dulwich/bzr-git combo that will work with python2.4 and bzr 1.14 ? | 22:22 |
| jelmer | mwhudson: I don't think I've made any 2.4-incompatible changes but let me check.. | 22:23 |
| jelmer | mwhudson: yeah, 1.14/2.4 should be fine with both trunks | 22:24 |
| mwhudson | jelmer: have you rebased dulwich trunk again? | 22:26 |
| jelmer | mwhudson: yes, that's this offset bug I was talking about | 22:27 |
| mwhudson | argh | 22:27 |
| jelmer | sorry :-/ | 22:27 |
| jelmer | it's dogfooding dpush that finds these bugs though | 22:27 |
| mwhudson | i guess :) | 22:28 |
| jelmer | mwhudson: banshee import: RAM usage seems to vary somewhere between 120Mb and 60Mb, takes about 1000s wall clock time on my thinkpad | 22:28 |
| mwhudson | jelmer: dulwich r295, bzr-git r442 | 22:29 |
| mwhudson | jelmer: ok | 22:29 |
| mwhudson | jelmer: can you check my revnos ^ | 22:31 |
| jelmer | mwhudson: ack | 22:32 |
| jelmer | mwhudson: they match what I have here | 22:32 |
| mwhudson | jelmer: cool | 22:32 |
| poolie | i'm just catching up on the 1.4rc date thread from when i was away | 22:36 |
| poolie | so long | 22:37 |
| poolie | some useful ideas though | 22:37 |
| === phinze_ is now known as phinze | ||
| === lifeless_ is now known as lifeless | ||
| awmcclain | Is there a way I can move a branch into a subfolder of another branch while retaining my version history? | 22:48 |
| mwhudson | awmcclain: i think the merge-into plugin can do this | 22:50 |
| awmcclain | thank you | 22:50 |
| jelmer | lifeless: are there any plans for upgrading bzr.dev to rich-roots yet ? | 22:53 |
| lifeless | jelmer: yes | 22:56 |
| lifeless | jelmer: I've been posting to the list regularly about that ;P | 22:56 |
| jelmer | lifeless: oh, oops | 22:57 |
| jelmer | lifeless: I must've missed that, or do you mean the rich root upgrade bugfixes you've been posting? | 22:57 |
| lifeless | jelmer: I posted saying we should upgrade, and lets test on smaller projects | 22:59 |
| jelmer | lifeless: yeah, I saw that bit and the upgrade of bzrtools | 22:59 |
| lifeless | so the plan is to fix those bugs then try again | 23:00 |
| === dahoste is now known as dahoste|away | ||
| jelmer | ah, cool | 23:00 |
| jam | lifeless: something recently in bzr.dev is now not letting me branch the launchpad conversion. My guess is ghosts, possibly in the mainline history (since the failure is on an Arch- revision) | 23:01 |
| jam | I'm trying to investigate now | 23:02 |
| jml | lifeless: so, I was going to remind you about "[MERGE] Report the number of VFS calls in -Dhpss output" | 23:06 |
| lifeless | jam: thanks | 23:06 |
| jam | I'm trying a reconcile right now (which of course spends a huge amount of time in "Finding text references"...) | 23:10 |
| jam | it would seem that bzr.1.14.1 also fails to branch | 23:11 |
| jam | so it might not be something new | 23:11 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/368418 | 23:12 |
| ubottu | Ubuntu bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] | 23:12 |
| lifeless | jam: is https://bugs.edge.launchpad.net/bzr/+bug/182715 fixed? | 23:14 |
| ubottu | Ubuntu bug 182715 in bzr "Graph.heads() gives false heads sometimes" [Medium,Confirmed] | 23:14 |
| lifeless | jam: bug 368418 has a branch that should fix it for yoy | 23:15 |
| ubottu | Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418 | 23:15 |
| jam | lifeless: for bug 182715, afaik ghosts still confuse things | 23:15 |
| ubottu | Launchpad bug 182715 in bzr "Graph.heads() gives false heads sometimes" [Medium,Confirmed] https://launchpad.net/bugs/182715 | 23:15 |
| lifeless | yah, just had to read it again to figure that out | 23:15 |
| jam | Other than changing the api (or raising an exception) I don't think there is a lot to do for ghosts | 23:15 |
| jelmer | mwhudson: crap, I think I think the timezone handling still might not be correct | 23:16 |
| jelmer | mwhudson: you might want to hold off for a bit, I'm writing some extra unit tests to make sure it's really right this time | 23:16 |
| mwhudson | jelmer: will this mean you need to rebase dulwich again? | 23:17 |
| jam | lifeless: branching that gives 'AbsentContentFactory' .... :( | 23:17 |
| lifeless | jam: hilarity ensues | 23:17 |
| jelmer | mwhudson: probably, unfortunately | 23:17 |
| mwhudson | jelmer: spm finished the dance to get the new dulwich in seconds before you typed that :) | 23:18 |
| lifeless | spiv: if you're well enough, please fix-branch your fix for bug 368418 | 23:18 |
| ubottu | Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418 | 23:18 |
| lifeless | jam: you can probably get the patch via loggerhead | 23:18 |
| jam | I'm trying via nosmart+ | 23:18 |
| jam | which seems to do just fine | 23:18 |
| lifeless | that too | 23:18 |
| mwhudson | jelmer: is bzr-git reasonably good at progress reporting? | 23:19 |
| jam | lifeless: with patch applied, same failure | 23:19 |
| jelmer | mwhudson: it should be doing either activity reporting or progress bars | 23:20 |
| mwhudson | ok | 23:20 |
| jml | poolie: I've updated that patch, btw | 23:20 |
| poolie | for dhpss | 23:20 |
| mwhudson | hmm, i need to look into activity reporting actually | 23:20 |
| poolie | i saw, thanks | 23:20 |
| mwhudson | might help https://bugs.launchpad.net/bugs/370491 | 23:21 |
| ubottu | Ubuntu bug 370491 in launchpad-code "Unable to handle reasonably sized development6 branches" [High,Triaged] | 23:21 |
| poolie | spiv was sick yesterday, i don't know about today | 23:21 |
| poolie | jml: if you're impatient i'll just merge it | 23:23 |
| poolie | it definitely sounds like useful data | 23:23 |
| poolie | jml: do you have pqm access? | 23:23 |
| jml | I am a little impatient, yes :) | 23:23 |
| mwhudson | poolie: very quick UI factory question, should/could a call to report_transport_activity be seen as a sign of activity? | 23:23 |
| jml | no I don't. | 23:23 |
| lifeless | mwhudson: it means something is networking | 23:24 |
| mwhudson | good enough for me | 23:24 |
| poolie | mwhudson: well, yes, but maybe i misunderstand the qn | 23:24 |
| poolie | as opposed to what? | 23:24 |
| lifeless | mwhudson: it doesn't mean its not in an infinite loop; but then no activity doesn't mean anything either way either | 23:24 |
| mwhudson | poolie: good question | 23:24 |
| mwhudson | poolie: it wouldn't be called if the network connection stalled? | 23:24 |
| mwhudson | lifeless: we've not had anything do that to us yet, touch wood | 23:25 |
| poolie | mwhudson: no, it doesn't | 23:25 |
| mwhudson | poolie: i can't imagine why it would be, i'm just feeling paranoid | 23:25 |
| lifeless | mwhudson: its called when bytes are read or written; a stall where we can write, get no error, and keep doing that would fool you | 23:26 |
| poolie | typically (for the text ui) if it stalls it will just stay stuck on the last activity rate | 23:26 |
| poolie | which is not ideal | 23:26 |
| lifeless | I think thats an unikely scenario | 23:26 |
| lifeless | poolie: this is for the robot ui | 23:26 |
| mwhudson | lifeless: that hasn't been a problem in practice (yet, touch wood again) | 23:28 |
| mwhudson | i want a "commit the change in this tree to a new branch" command :/ | 23:29 |
| mwhudson | i guess that's not so hard, just a bit shell scripty | 23:29 |
| lifeless | its easy with ric | 23:29 |
| lifeless | we just have to finish adjusting iter_changes so ric can be always used | 23:29 |
| mwhudson | ric? | 23:29 |
| === abentley1 is now known as abentley | ||
| lifeless | jam: ^ are you likely to get to that soon? / not in your pipeline? | 23:30 |
| lifeless | mwhudson: record_iter_changes, the fast path commit code | 23:30 |
| mwhudson | oh right | 23:30 |
| mwhudson | well it's not so hard in a shell script really, bzr branch, bzr merge --uncommitted, bzr ci | 23:30 |
| lifeless | mwhudson: I mean 'bzr commit --to ../newbranch' | 23:31 |
| mwhudson | yeah | 23:31 |
| poolie | yes i realize it's for the robot | 23:34 |
| poolie | mwhudson: if you'refeeling paranoid i suggest you check the 'action' or whatever it's called is 'read'/'write' | 23:34 |
| mwhudson | merge --uncommitted seems broken :( | 23:34 |
| mwhudson | oh oops | 23:34 |
| mwhudson | pebkac | 23:35 |
| mwhudson | but still | 23:35 |
| poolie | if we add a soft timeout like 'no io for two seconds' then we'd make a new action | 23:35 |
| mwhudson | "bzr merge --uncomm ." explodes | 23:35 |
| mwhudson | poolie: ah, ok, that makes sese | 23:35 |
| mwhudson | poolie: the parameter seems to be called "direction" currently? | 23:36 |
| mwhudson | tbh | 23:37 |
| mwhudson | if we have a network write in the puller, something's gone a bit funky :) | 23:37 |
| mwhudson | i wonder how to test this | 23:38 |
| jelmer | mwhudson: ok, I have finally fixed it now *and* added tests | 23:53 |
| jelmer | mwhudson: pushing dulwich again now, should be there soon | 23:54 |
| mwhudson | jelmer: did you have to rebase? | 23:54 |
| mwhudson | ok | 23:54 |
| jelmer | mwhudson: yes, a bit | 23:54 |
| mwhudson | jelmer: how do you rebase a bit? :) | 23:55 |
| jelmer | mwhudson: only the identity of the last few revisions has changed, the first few are still as they were before | 23:57 |
| mwhudson | jelmer: oh ok | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!