[00:00] it will make subunit-ls clearer, so if you get the time to review, assume its gone :) [00:00] ronny: have you read "xUnit test patterns"? [00:01] spiv: stacked [merge] sent [00:02] mwhudson: no [00:03] ronny: the first 100 pages or so is well worth reading for provoking thoughts about testing [00:03] hmm, added to my should read list [00:04] it's unfortunate that you have to buy the other 700 pages too :) [00:04] ew [00:18] igc: ping [00:22] edcrypt_: pong [00:25] igc: hi, I the one who made that bug report about views [00:25] igc: what is the view-aware API to iterate on the WT? [00:26] edcrypt_: there probably isn't one ... [00:26] I tend to trap most things at the UI layer inside builtins.py ... [00:27] so that the list of files is automagically passed to commands without needing to change their internals [00:27] edcrypt_: there are exceptions though ... [00:27] igc: shouldn't it filter at the tree? [00:27] diff comes to mind [00:27] igc: so that plugins work [00:28] lifeless:it depends [00:28] whether to use a filtered view needs to be considered on a case by case basis [00:29] igc: WorkingTree..inventory.iter_entries_by_dir() gives all files, but probaly I shouldn't be using it [00:30] edcrypt_: so if you look at the code for cmd_diff in builtins.py, you'll see it passed apply_view flag down to the next layer [00:31] edcrypt_: you certainly can use that API, you'll just need to post filter the results by seeing if the path falls inside the view or not [00:31] thst's not hard - see the examples at the top of builtins.py (like internal_files_for_add say) [00:31] s/thst/that/ [00:32] igc: ok, taking a look, thanks! [00:32] np [00:32] edcrypt_: any you looking at fixing ls for me? :-) [00:33] igc: in what cases is the answer 'no' so far? [00:33] lifeless: merge, log, info at least [00:34] igc: hehe, maybe, I have just learned hwo to create a plugin! [00:37] igc: _check_path_in_view() [00:38] ops, diff._check_path_in_view() [00:40] lifeless: reviewed, bb:approve [00:42] woo [00:42] edcrypt_: might be good to make that a public function in views.py instead of a private one in diff.py. [00:47] igc: indeed [00:57] spiv: ok, thats sent. === abadger19991 is now known as abadger1999 [01:08] luke-jr, hi [01:08] poolie: fyi, here's my plan for today [01:08] luke-jr, any chance you can comment on bug 326278? [01:08] Launchpad bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,Incomplete] https://launchpad.net/bugs/326278 [01:08] 1. get usertest tweaked with some of the changes on the roadmap [01:09] jelmer: ping [01:09] lifeless, pongz0rz [01:09] 2. ping you and we'll update orchadas [01:09] 3. land content filtering after chatting with you [01:09] * igc bbiab - food calling [01:11] jelmer: could you do a pass over your subunit branches, and submit for merge where relevant [01:12] lifeless, k [01:13] thanks [01:14] igc, sounds good [01:14] my laptop won't boot, i'm guessing because of bug 333073 in jaunty :/ [01:14] Launchpad bug 333073 in linux "very slow boot with lvm-on-dmcrypt" [Undecided,New] https://launchpad.net/bugs/333073 [01:14] that gave me a bit of a setback [01:14] but let's talk anyhow when you're done [01:17] Hi - when I run bzr shelve - I get the following prompt: [01:17] Shelve? [yNfq] [01:18] yes No f???? q???? [01:18] Where can I find more info. bzr help shelve does not say anything. [01:19] q is quit [01:19] does ? do anything? [01:20] no [01:20] no - ? seams to cause no which is the default action - lol [01:20] srsl? :( [01:21] f flips the defaults [01:21] Odd_Bloke: is workng on this I thought [01:22] mwhudson - I jest tested that - f seems to do a "full" diff? [01:23] oh [01:23] i'm wrong then [01:24] ok - it easy to figure out - but irritating. [01:30] it should definitely be able to give you help [01:31] igc, back in 5 === bob2_ is now known as bob2 [01:37] spiv: ok with that sent off I'm looking at the next round trip [01:42] spiv: another regression - we're not using find_repository to do the iteration for us [01:42] we're walking up dirs manually [01:44] lifeless: actually, I'm not sure if that ever worked... [01:44] But yes, it'd be good to fix that. [01:44] Also, coffee is good... [01:44] * spiv does something about that [01:44] I'm fairly sure it did at one time ;) [01:44] but I could be wrong [01:45] Me too :) [01:51] new small lp-open patch just sent to mailing list. [01:52] * jml doubles as an IRC notification bot. [01:53] :) [02:04] spiv: I want to delete InterPackToRemotePack [02:09] igc, i'm free now if you are [02:09] lifeless: +1 (minus a bit for not being right there in the code atm) [02:17] lifeless: so that was only doing two things [02:17] lifeless: (IIRC). calling the autopack RPC, and making sure _walk_to_common_revisions walks 50 revs at a time [02:18] lifeless: the streaming push takes care of the former, I think the latter might be taken care of by the InterOtherToRemote? [02:18] lifeless: if so, I don't see any reason to keep it either [02:21] spiv: yeah [02:21] spiv: thats why I want to delete it; and am doing so ;) [02:21] Ok. +1 :) [02:21] I'm glad to see the set of InterRepos shrinking for once :) [02:22] http://paste.ubuntu.com/121655/ [02:22] I'd like to just toss that at pqm - pass land fail I'll look into it [02:22] spiv: ^ [02:27] lifeless: sure, if it passes, then +1 [02:27] lifeless: or rather, bb:approve :) [02:36] jml: your blug reports footnote doesn't seem to exist [02:39] mwhudson: mea culpa [02:43] i think i just made the annotate view in loggerhead twice as fast [02:44] mwhudson: good [02:44] :) [02:44] by not calling annotate_iter twice! [02:44] * mwhudson sighs [02:46] mwhudson: its amazing how little things can make a difference :) [02:46] mwhudson: I have a suggestion for you [02:46] * mwhudson listens [02:46] this is for testing [02:47] create a little delegate branch [02:47] which logs all the calls made to it [02:47] and has a repository object it can return which likewise does the same for the branches repository [02:47] you can do two things with this [02:47] when asking 'why is X slow' you can see the api calls being made [02:48] and secondly you can write a test that no more than a certain number of calls/exact calls etc are made [02:49] hmm [02:49] the former is useful for exploring [02:49] the latter is useful for locking down a behaviour ratchet [02:51] certainly, something i've been doing lately is removing the layers between loggerhead and bzrlib [02:52] and it was in the process of doing this that i found this problem [02:58] spiv: I'd like to make RemoteRepository.*write_group* no-ops like knit/weave repositories [03:00] lifeless: the _real_repo would still need to have a write group, though? [03:00] well [03:00] lifeless: or are we avoiding enough vfs ops now? [03:01] as a start point we may find points that break [03:01] at the moment though it and repo.lock_write are triggering _ensure_real [03:01] actually [03:01] lock_write doesn't trigger _ensure real [03:01] but its a noop for pack repos [03:03] * spiv nods [03:04] light weight commits will still need vfs [03:04] but bound commit shouldn't [03:05] calls 13 through 18 are RemoteRepository.start_write_group(), in the acceptance test [03:18] spiv: ok, BranchFormat.network_name next I think [03:18] spiv: ping [03:18] bah [03:18] spm: ping [03:18] lifeless: pong [03:18] spm: I think pqm is hung, can you check please? [03:18] sure [03:23] did jelmer's clean-tree patch get reviewed? [03:27] lifeless: it was wedged pretty good. should be rockin again [03:27] spm: did you note the cause? [03:28] looked like the old email thing; but that didn't fix it. the sendmail was then hanging around as a defunct process. ie still wedged. [03:28] ok, I'll try the merge again [03:33] damn. it's rewedged itself. looks like on the original one too. [03:34] poolie: I'm back [03:34] spm: ok, patch is bad anyhow, so I suggest just removing the request from me and killing the bzr child [03:35] spm: you shouldn't ever kill the pqm parent when a test is wedged [03:35] is it just me or does bazaar-vcs.org seem really slow these last few days? [03:36] lifeless: yeah - that was a pebkac. :-( did the chroot kill without a dir specified. clobbered everything :-( x 3 [03:36] spiv: we need a 'refresh your data' api for all repositories [03:36] spiv: because this streaming push can work for knits, but we can't let it try :> [05:17] igc, hi? [05:18] hi polie [05:18] poolie:^ [05:19] poolie: you ready to do this orchadas stuff? [05:19] hey [05:19] i am [05:19] i hit an ubuntu bug 332270 that stopped my laptop booting and messed up my day a bit [05:19] Ubuntu bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270 [05:20] poolie: yum [05:20] poolie: let's start by having a quick call maybe? [05:20] that's why it's called an alpha [05:20] good idea [05:20] i'll call your home? [05:21] sure [05:22] lifeless: I have some theoretical reasons why multiparent with xdelta is smaller than gc, care to have a call about it tomorrow? [05:22] hello jam [05:22] hi poolie [05:23] just heading off to bed after perusing the ~200 emails that came in over the weekend... [05:23] jam: I'd be delighted [05:23] lifeless: k, ping me when you wake up [05:23] I'm going to sleep now [05:35] jam: ciao [05:36] jam: I'd expect the theoretical reason is deltas composition rather than recipes [05:36] but see recipes for why gc is fast at extraction [05:37] um, bzr just said "bzr: ERROR: exceptions.AttributeError: children" and aborted the commit i told it to do. how do i make it successfully commit? [05:38] maco: what bzr version? [05:39] 1.12 [05:42] maco: uhm [05:43] maco: is there more in ~/.bzr.log ? [05:52] lifeless: it spit out a backtrace [05:52] i'll pastebin it [05:57] kernel panicked === maco_ is now known as maco [06:02] http://paste.ubuntu.com/121690/ [06:02] lifeless: ^ [06:09] maco: can you pastebin the output from 'bzr st' please [06:09] (parent appears not to be a directory) [06:10] just "added: .kde@" [06:11] so .kde is a symlink [06:11] i just made ~/config-backup, cd'd there, and did "bzr init" then tried to do "bzr add ~/.kde/share" and some other directories, but it didn't like that, so i made the symlink [06:11] yes [06:11] ok [06:12] so we'll make a bug for the error, because it shouldn't be happening; but if you're trying to backup your .kde directory, a symlink to it won't do that - bzr will version the symlink [06:12] i didnt give it ~/.kde to version though [06:12] igc: merge request sent (make ls aware of views) [06:12] i gave it ~/.kde/share and ~/.kde/Autostart and ~/.kde/env [06:12] you need to either make ~/.kde a symlink to your bzr tree, or actually bzr init in ~/.kde [06:13] maco: you did 'ln -s ~/.kde' inside config-backup didn't you? [06:13] yes [06:13] edcrypt_: thanks! [06:13] but then i did bzr add on .kde/share, not on all of .kde [06:14] igc: np [06:14] maco: right, so I think I know what the bug is [06:14] maco: however fixing it won't do what you want, so give me a second to record the issue [06:14] was trying to get around it giving "NotBranchError: Not a branch: "/home/maco/.kde/share/"." when i did "bzr add ~/.kde/share" [06:14] ok [06:15] igc, ok, i got a report with just one tool running [06:15] is it not possible to give an absolute path to bzr add? [06:15] now i'll try it with some more though that will be slower [06:15] maco: no, its not possible [06:16] maco: bzr requires that all the files it versions are underneath a .bzr directory containing the 'tree' to be versioned [06:16] maco: roughly, thats where you do 'bzr init' [06:16] maco: so if you want to version ~/.kde/share, you must have done 'bzr init' in one of: ~/.kde/share, or ~/.kde, or ~ [06:18] maco: I've filed a bug for the specific error you're getting, but the actual fault is in 'bzr add' :( [06:19] lifeless: ok thanks. a friend suggested avoiding putting it in ~/.kde in case of the next time i blow away ~.kde but i'll just have to remember to keep a backup of the .bzr that's in there [06:19] maco: put it in ~/.kde like so: [06:20] rm -rf ~/config-backup; cd ~/.kde; bzr init; bzr add [things]; bzr commit -m "start versioning ~/.kde"; bzr push ~/config-backup [06:20] poolie: cool [06:20] maco: now config-backup is a backup [06:20] ah ok good idea. thanks! [06:21] my pleasure [06:30] http://benchmark.bazaar-vcs.org/usertest/summary.html [06:46] if i do "bzr remove" it doesnt remove the file, right? just stops doing version control on it? [06:46] if you do rm --keep it will do that [06:49] or well...how do i tell it to not track anything in share/apps/kmail/*/*? bzr ignore? and will that get rid of its past control of those files or not? [06:49] if you have already added them, and you want to just ignore them in future you need to both remove --keep and also ignore them [06:51] igc, still here? [06:53] ok [06:53] thanks [06:53] poolie: yep [06:54] i'd like to make something that will feed usertest output into rrd [06:54] so we have an over-time plot of results [06:54] er, was i supposed to ignore or remove first? bzr diff still shows stuff from those files [06:54] maco: bzr ignore ./share/apps/kmail/ [06:54] i'd probably start with getting the total scenario time for each tool [06:54] and recording that each time we execute [06:54] maco: ignore and remove [06:57] so firstly ,is this redundant with something you've done [06:57] ok thanks [06:57] poolie: no, I'm yet to produce rrd friendly output [06:57] bearing in mind it has to run on a dapper machine with no added software [06:57] and secondly, what should i start from? [06:57] oh [06:58] actually for the overall time, now that we're running each test separately, it's obviously easy [06:58] to do it from the driver script [06:58] i'll do that first then see how we go [06:58] poolie: ok [06:58] poolie: btw, new usertest just pushed with Description column added to the html report [06:59] poolie: that will reduce the # of times I need to explain what each task/action does :-) [06:59] scalability :) [07:00] rev 151 also fixes the colouring when multiple projects are given in the one html report [07:00] i.e. colouring is per project, not just against the first column :-( === chx is now known as chx_sleeping === picturesque is now known as domas [09:10] * igc dinner [09:44] lifeless: I have a branch to fix the prompt up. I'll send it in now (as the branch it depends on has been merged now). [10:52] yo [11:01] lifeless: FWIW, I always run latest bzr.dev, and the streaming push work hasn't broken anything for me. I don't use stacking though. [11:18] Peng_: that's good to know. Does that include using bzr.dev on the server? [11:34] spiv: Yes. [11:35] Except for once half an hour ago, where the revisions on the client and server were incompatible, so I had to do one push over sftp. [12:05] Peng_: thanks [12:05] Peng_: is it faster? [12:06] lifeless: Sorry, but I don't really pay attention. It takes more than 1 second, so I always do something else while it runs. [12:06] Peng_: fair enough [12:06] I always run it through "time", and yet I never read the results. :P [12:06] LOL [12:16] moin lifeless, Peng [12:19] lifeless: are there any plans to support custom objects in the history store at one point? [12:19] jelmer: Good morning. [12:20] ronny: no; as we discussed before I think we'd need to see more examples of custom things before being able to design a good reliable & sufficient interface [12:20] ronny: so its not 'no, never' its 'no, no _plans_ at the moment, open to things as we see people doing it in plugins' [12:23] k [12:23] lifeless, what happened to the annotated code stuff you were discussing with James in London during the summer? [12:23] can't remember the exact name you were using [12:28] the main use-cases *i* see is signed tags, code-review, testresults [12:30] jelmer: "marks"? [12:31] james_w, yeah, that's it [12:32] I don't know if lifeless has done any work on it, I certainly haven't [12:32] I would love to have it though [12:33] the thing that I'm not sure about is how to store the marks [12:33] "file-id hunk-start hunk-end sha-of-hunk" might work I guess [12:43] jelmer: views [12:43] jelmer: erm [12:43] views/filters/tags something like that [12:43] marks maybe? [12:43] james_w: yeh I started sketching htat [12:43] hmm [12:43] haven't gone far; performance is a major issue first [12:45] ronny: so for all of those, I'd definitely help you get support in the core as hooks, so that plugins can do them [12:45] and once we see what plugins *do* with those hooks look at the design for core inclusion of extensible things [12:50] lifeless: atm im puting together a nosetest plugin for subunit [12:51] lifeless: if you've committed anything I'd love to take a look [12:51] lifeless: I understand that it's not your first priority [12:55] lifeless: subunit could use a setup.py [12:55] ronny: yeh, though it builds native C and shell and stuff; setup.py isn't really a good fit there [12:55] scons isn't either though >-) [12:56] lifeless: at least for the python part [12:56] jelmer: scons was an awful nightmare that I regret [12:56] ronny: certainly thats doable yes [12:56] I think there is a branch [12:56] ronny: http://www.somethingaboutorange.com/mrl/projects/nose/doc/plugin_interface.html#prepareTestResult [12:56] prepareTestResult(self, result) [12:56] seems to be the bit [12:57] lp:~lifeless/subunit/filter has the latest subunit branch I was tweaking [12:58] would you mind if i would put nosetest support directly into subunit ? its basically just replacing the reporter === vednis is now known as mars === mvo_ is now known as mvo [13:15] ronny: I'm not sure what you're asking [13:15] ronny: but note bug 332770 [13:15] Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770 [13:16] lifeless: thats what i do atm [13:16] which is to say, I'd like it if installing subunit added an option to nose [if nose is installed] [13:16] I don't want subunit to depend on nose though [13:16] I consider it a lower level helper [13:16] ok, so separate repo it is [13:17] ronny: hm? Not sure I follow, however I'm tired :) [13:17] so - chat with you in ~ 7-8 hours [13:17] k [13:17] cu later === montywi|zzz is now known as montywi === mvo__ is now known as mvo === serg_ is now known as serg === beaumonta is now known as abeaumont === chx_sleeping is now known as chx === montywi is now known as montywi|meeting [16:10] morning vila, I hope you had a good weekend [16:11] jam: hehe, hi ! Yes, pretty good, didn't touch a mouse nor a keyboard (didn't happen for a while :) [16:11] jam: how was yours ? [16:11] jelmer: I'm getting timeouts while trying to access a signature file on your dulwich branch [16:11] vila: pretty good [16:12] sat was a kids birthday party [16:12] so it was fun to see Kareem playing with the neighbor kids [16:12] I didn't get back to a comp until late Sunday night as well [16:12] jelmer: lp also seems to be having problems with that branch [16:12] jam: us2 seems to be under heavy load at the moment, one of the admins is looking into it [16:13] jelmer: k. It seems funny since everything works until the .six [16:16] vila: still looking into the mysql stuff? [16:16] jam: on my right screen, yes [16:17] jam: trying to find a better ftp test server on the left one [16:17] jam: I was so close :-/ And had problems *again* with FtpStatResult and the test suite being too demanding for ftp :-/ [16:17] Hmm, it took 438.396 seconds to pull one revision from subvertpy. bzr-svn is still going. Did my connection hiccup? [16:18] jam: the idea was to spend a couple of hours only on it and then address the fact that we can't test under 2.6 anymore until we avoid using medusa there which requires another one [16:19] jam: I hate ftp [16:19] that was rude, ftp doen't like me that much [16:21] Peng_, server is having issues [16:21] vila: Would it be easier to just get medusa working with 2.6 ? [16:21] Oh. Oh! I did read backlog, just not enough to understand it. Alright. :) [16:23] jam: no, far harder as the bug is deep down inside asyncore/asynchat or something (I suspect the problem is roughly that somewhere in an iterator str() objects are special-cased and unicode isn't, ugly business), so the idea was to just stop using medusa for >= 2.6 and find another ftp test server [16:24] jam: I found one that doesn't require running as root, only to find that it returns an empty list when asked to list a non-existing directory and has no problem giving the *size* of a directory [16:24] vila: why would we be using Unicode anywhere... [16:24] at the FTP level, everything should be 8-bit strings, (I think) [16:25] utf-8 (sorry) [16:25] vila: we wouldn't be special casing a utf-8 string [16:25] as it is just another 8-bit string [16:25] but at some point giving utf-8 means handling unicode (from memory) [16:25] jam: I don't remember exactly the problem, certainly it was on server side, and ... well there is little we can do there :( [16:26] vila: I don't know the failures, but everything *under* FTPTransport should be 8-bit strings. I suppose if we have a unicode file on disk there may be other issues [16:26] vila: does everything fail? [16:26] Or is it just a couple tests that we could say "py2.6 + unicode files + medusa is KnownFailure" [16:26] vila: I certainly would rather you spending your time on other things :) [16:27] under 2.6 with medusa, failures are about utf-8 encoded file names IIRC [16:27] vila: exactly, so wrap tests that do exactly that with KnownFailure and get on with your life :) [16:27] jam: I know :-/ I hoped to be done with it far quicker and then... well each bug looks like the solution was close :) [16:28] Can I expect the Mac OS X 10.5 Installer for bzr 1.12 soon? [16:28] hmm, not sure we can peak under the cover to realize we are under 2.6 + medusa + whatever, the idea was to shorcut at get_transport_permutations [16:29] get_test_permutations I meant [16:29] eferraiuolo: "tonight (European time)" according to a post on the mailing list :) [16:30] Peng_: thanks for the info :-) [16:30] jam: to be precise, I have a test server that pass the test suite, with a relaxing constraints patch against bzr.dev, so that's not *that* bad :-) [16:31] jelmer: I have a trivial patch to 'dulwich' which should help the performance of 'apply_delta'. Care to test it out? [16:31] http://paste.ubuntu.com/121930/ [16:32] jam: on the bbc front all the remaining failures will require a bit of work and I wanted to start with a bzr.dev merge which raise to many conflicts to be solved quickly, so *that* was pushed out of the parrallel activities which are now back to the two mentioned above :) [16:32] vila: sure. I'm also submitting the "trailing whitespace" fix [16:32] jam, Is that against the current trunk? James also submitted a performance improvement yesterday [16:32] which is going to be bad for merging into bbc [16:32] jelmer: versus 154 [16:32] it just changes to use a list and append [16:32] and then ''.join() at the end [16:33] jam, ah, cool [16:33] jam, can you "bzr send" or is it easier if I just pick up from pastebin? [16:33] that should avoid O(N^2) performance [16:33] I haven't committed, but I can and I'll send it [16:33] jam: by the way, if *you* are able to merge bzr.dev cleanly in bbc, just tell me :-) [16:33] nice [16:34] there are probably a couple more places in that file where that approach could be used [16:34] jam: Please do :-) [16:34] jam, vila: Also, if you can have a look at my InterBranch patch that would be really helpful for bzr-git.. [16:35] * jelmer is still wondering what the magic trick is to get a patch reviewed [16:35] jelmer: sent [16:35] jam: Thanks :-) [16:35] vila: I'm sure I'm not [16:35] I changed some code in fetch [16:36] which Robert changed with the network streaming stuff [16:36] hi channel [16:36] I added a progress bar [16:36] whats bazaar all about ?? [16:36] jam: yeah, so at least you know *one* side of the conflict as opposed to None :-) [16:37] jelmer: I think it is beer. And submitting patches that directly effect other people. The problem with InterBranch is that I haven't worked out whether the added complexity is worth the benefit for non-core code. I'll try to give it a look [16:37] arshad: freedom :) [16:38] ok . . . . . . but freedom for what ?? [16:38] jelmer: I assume that is the cause of "AttributeError: 'module' object has no attribute 'InterBranch'" with a newer bzr-git? [16:38] arshad: That was a trivial response. To give you a better one, how much do you *know* so I don't repeat myself [16:38] bzr is a version control system [16:39] do you need to know the diff from others [16:39] what a vcs *is*? [16:39] etc [16:40] hope u wont fire me for that [16:41] arshad: no firing, just trying to understand what info you really want [16:42]