[00:01] igc: hai [00:09] morning all [00:09] hi lifeless [00:10] hi igc [00:10] hi poolie, jam [00:11] igc: have you used netbeans as a datasource for benching? [00:12] lifeless: no [00:12] igc: I ask, because one of the drizzle folk was bemoaning the lack of a bzr scm module [00:12] so I pulled the thing... 1.7GB, 90K files [00:12] 133K commits [00:13] lifeless: as in an addon for NetBeans? [00:13] yeah [00:13] their addons are all in tree [00:13] _pain_ [00:13] lifeless: yuk [00:14] lifeless: it was nice to see qbzr-eclipse 0.7 out overnight [00:14] and I'm pretty sure there's someone working on a C++ Builder/Delphi integration along those same lines [00:15] lifeless: http://bazaar-vcs.org/IDEIntegration/Guide [00:16] lifeless: I'm pretty sure nick put together the original qbzr-eclipse integration in around 2 days [00:17] lifeless: so it's typically easy to get *something* useful going [00:18] lifeless: my main reluctance with doing an integration myself is ongoing ownership - it's better if someone using a given IDE everyday owns it IMO [00:20] igc: I agree; I don't really like the different UI that qbzr-* gives though [00:20] igc: are you Ian Clatworthy? [00:21] roony: yes [00:21] ronny: ^ [00:21] igc: great, well, what do people do that do api-level integration instead of subprocess levle integration :P [00:22] ronny: I'm not sure I understand the question ... [00:23] ronny: you can always call into bzrlib and into qbzr itself if you want [00:23] * ronny is the author of anyvc, a vcs abstraction lib, i just import bzr instead of calling to it [00:23] though the qbzr API has no stability guarantees [00:25] ronny: the point behind using the qbzr applets is to same the engineering time required to design, develop and test 30-40 dialogs [00:25] igc: well, does it have version metadata, and some more convience tools for common ops than bzrlibs? [00:26] igc: im not sure if qbzr wil lbe that helpfull for me, as i need the dialogs for other vcs's, too [00:28] ronny: right. Down the track. I'd hope to see qbzr working in combination with bzr-svn, etc. to provide a common GUI over multiple VCSs but it sounds like you're solving a different problem [00:29] igc: yup, i'll probably have to support the svn integrations anyway at some point [00:33] fwiw the combination of qbzr and bzr-svn should already work [00:33] John Szakmeister did quite a bit of testing with it and reported bugs [00:40] igc: hg fastexport is kinda slow :( [00:41] lifeless: yep [00:42] lifeless: on packs, so it bzr-fast-export; 2a is a much happier place for bulk data export/import [00:42] s/it/is/ [00:43] yeah [00:43] I should hope so :P [00:48] igc, so i liked your wishlist blog postn [00:49] but i think we need to distinguish "things that will actually block 2.0" from "things we'd like to do" :-/ [00:49] because that list is pretty incompatible with hitting karmic [00:50] poolie: yep [00:51] 2.0 is kind of trying to be two different things [00:51] the release that makes 2a the stable format [00:51] and the "everything's great and finished" release [00:53] It's also trying to be the "Crap, we have to hit karmic" release... [00:54] poolie: no, it's not the later [00:54] poolie: 2.0 is trying to be 2.0 [00:55] poolie: that does mean a new format [00:55] poolie: it also means "now's a god time to take another look at Bazaar if you're not using it" [00:55] good [00:55] sure [00:56] i guess i'm glad you're raising these things but the week we're trying to freeze the code is a [00:56] well, maybe not a great time [00:57] :/ [00:57] poolie: that's not totally fair ... [00:57] I've been raising better packaging for weeks and weeks now on multiple email lists [00:57] that's true [00:58] -> phone [01:28] if I use bzr-svn to merge a svn branch onto the trunk, will svn grok the merge? [01:28] jelmer: ^ [01:29] i was talking with a guy last week at Agile2009 who use git-svn [01:29] on windows [01:29] he finds it painfully slow [01:29] and that was another pain point for him [01:29] i want him to have another try at bzr [01:29] he try it out last year [01:30] bbs fooding [01:46] hi jelmer [01:47] jelmer: I think qbzr is working over bzr-svn [01:47] jlemer: I wonder if we need some tweaks though, e.g. a gui way of doing a dpush" or whatever name we selected for that operation [01:48] jelmer: ^^^ === CardinalFang is now known as CardinalFangZzzz [02:11] jelmer: ping [02:27] bbiab [02:39] spiv: hi, late call? [02:42] poolie: sure [02:42] will call in 2m [03:00] Hmm, jam's mail server is bouncing mail. [03:44] anyone knows which command in !bzr shows just the changes from a given revision? [03:44] what is !bzr? [03:44] bob2, ops... typo [03:44] :D [03:45] The logical counterpart of ~bzr [03:45] ehehehe [03:46] bzr diff -c xxx [03:47] bob2, that was exactly what I was wanting [03:47] thanks a lot! [03:52] * rbelem leaving [03:56] * igc lunch === AfC1 is now known as AfC [04:50] is there a way to make bzr missing walk up a sequence of branches? [05:06] up? [05:08] LarstiQ: a status update:. After recompiling subvertpy, I was able to get things to commit properly to the svn repo! Thanks again for your help earlier today. [05:41] AfC: transitive relationships. the parent of the parent branch, etc [05:45] andrewks: so, to my knowledge, no, that's not built in. But it wouldn't be _that_ hard to [shell] script, especially if you assume that branches are sanely set-up, and that `bzr diff -r ancestor:` does what you want it to in each branch. Or you could parse `bzr info` output. etc [05:45] yes, I'm going with sane locations for now. This isn't something I have to do often [05:48] AFAIK it all chains fine, so things like "parent:parent::parent" would DTRT. [05:48] Also really screw up your brain trying to read, but hey, you can't have everything... [05:50] Or maybe it doesn't 'cuz my brain is screwed up. It's probably too late for anything I say to be worth listening to today... [06:00] fullermd: hm. Not so sure about that: `bzr status -r ancestor:ancestor:` just now didn't work [07:20] hi all [07:43] hi vila [07:43] hey ! [07:46] https://bugs.launchpad.net/bzr/+bug/422403 [07:46] Launchpad bug 422403 in bzr "bzr log -v -n 0 | less on drizzle takes ~ 3-4 secs before displaying anything in less" [Undecided,New] [07:46] hi vila [07:48] add --forward to that and we should be quite close to the slowest possible context [07:49] he runs this all the time [07:49] to see what he has pulled [07:49] I think Ian answer makes sense, drop -n0 [07:49] drill down only when needed [07:50] that's the only work around I can think of [07:50] spm: actually maybe we should talk here [07:50] poolie: heh. indeed. just reading now. [07:50] vila: well, it can be an open bug still [07:50] let's make sure it's deduped and clear: takes too long to start showing revisions for indented less [07:50] until we are able to calculate revnos lazily, that bug will remain open... lol, fully agree poolie :) [07:50] sure [07:51] poolie: err. I'm not sure I can do that - I think I fail on the "friendly sysadmin" part??? [07:51] saying it depends on the other bug is ok [07:51] damn [07:51] need 3 wise men too [07:51] [he didn't tell me he used -0 :P] [07:51] lifeless: they just love to trick us :-) [07:52] it might be worth drilling into why he's doing this [07:52] is it that he really wants to see all the history and -n0 is the best way [07:52] poolie: yeah, that looks fairly straight forward. shall I start to make it so? [07:53] well, i guess you'll still need incremental revnos [07:53] spm, yes, how about turning off pqm first [07:53] at least for that branch, or globally [07:53] and let's make an extra adhoc backup of it, then run check [07:53] globally for bzr, yes. backups is good. [07:55] poolie: we have incremental revnos if we display mainline revisions only :-) We start at the top and decrement, easy. [07:55] s/top/tip/ [07:57] right [07:59] poolie: lifeless: I can't help but feel I'm missing something really obvious here. the master location is (pqm config) /home/pqm/archives/thelove/bzr/2.0 but that's only a 44Kb directory. 1.18 etc are the same. ?? [08:00] spm, that's probably a bzr branch with no working tree [08:00] what does bzr info show you? [08:00] poolie: it is; would it really be that small tho? [08:00] spm: and a shared repo above it [08:01] right. yes. [08:01] shared repository: /home/pqm/archives/thelove/bzr [08:01] repository branch: . [08:02] spm: 44Kb now sounds even too much :) [08:02] spm: cd to /home/pqm/archives/thelove/bzr [08:02] spm: upgrade *that* [08:02] vila: heh. well a sum total of 570Mb is more the ballpark I was expecting. [08:02] spm: same as launchpad, shared repo. [08:02] ok [08:02] so tar up the whole thing before starting? [08:02] and then run check in there [08:03] oh also we should check what version of bzr you're using there [08:04] not sure, it will make a difference when run locally, but upgrading the test slaves, I noticed huge differences in performances between 1.17, 1.18 and 2.1dev, I think 2.0rc1 at least is needed here (or did spiv patch regarding IDS landed in bzr.dev only ?) [08:04] so tarball: ~/archives/thelove/bzr-backup-2.0.tar fwiw [08:05] we have bzr 1.17 locally; I can moderately easy create a special bzr of any version needed? [08:05] using 2.0rc1 would be good [08:05] or the ppa nightly [08:05] ppa's is hard. build from source/branch is easy [08:06] amusingly :-) [08:06] lp:bzr/2.0 then [08:06] hmm, wait [08:06] yes, that'd be good [08:07] vila: need 2.0 on launchpad before it will be fast :P [08:07] poolie: re conversion performance: this is what spiv and I meant by 'very slow without network deltas' [08:08] poolie: its not hanging, its doing millions of little round trips on the VFS [08:08] lifeless: it already makes a difference when pulling from lp [08:08] lifeless: it's not doing any network io [08:08] as observed by trace [08:08] poolie: oh, thats extremely odd [08:08] strace* [08:09] poolie: but didn't you have CPU consumed ? [08:09] did you try ctrl-\ and inspect? [08:09] yes, that's the bug i filed [08:09] ok [08:09] now i'm fixing bug 341535 :) [08:09] Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Medium,In progress] https://launchpad.net/bugs/341535 [08:09] looks like a server bug of some sort [08:09] hmm [08:10] I didn't comment on the bug, but I had symptoms pretty close to yours (poolie) except my pulls finished... [08:12] spm: so, lp:bzr/2.0 is already a bit more than 2.0rc1, nothing to be worried about I think, but if you keep notes on the upgrade it will be good to note the revno you used [08:13] vila: 'kk [08:14] btw. "Setting ssh/sftp usernames for launchpad.net." how do I stop bzr from doing that? it creates that )(*^)*(&^(%^&%$&*%^$*&%ing authentication.conf file and hence fails to connect. I assume by not using lp:bzr/blah syntax [08:15] err, how do you connect ? [08:15] you use bzr-pqm user right ? [08:15] on lp I mean [08:15] bzr branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 bzr-2.0 <== works; bzr branch lp:bzr/2.0 bzr-2.0 <== fails [08:15] Why is the existence of the authentication.conf a problem? Because it's putting in 'spm' rather than 'bzr-pqm'? [08:16] spiv: tbh, I don't precisely know, but using that lp:bzr breaks it totally. it's bzr-pqm, I'm sudo'd as the pqm user. [08:16] sudo doesn't matter, what is you $HOME ? [08:16] oh that's right - we have aliases "somewhere" that map users keys to branches or somesuch. [08:17] authentication.conf is such a map ! [08:17] .ssh/config [08:17] also [08:17] but looked at after :) [08:18] ISTR that the issue is around the *other* accesses that this uid has; all with diff keys [08:18] spm: what is your $HOME ? [08:18] /home/pqm [08:19] what is /home/pqm/.bazaar/authentication.conf content? [08:20] LOL, I never went to https://edge.launchpad.net/~bzr-pqm before :D [08:21] vila: [Launchpad] host = .launchpad.net ;; scheme = ssh ;; user = launchpad-pqm [08:22] so launchpad-pqm should be bzr-pqm ? Oooooooh, that's the problem ! It's used for launchpad and bzr right ? [08:23] vila: launchpad no, but other projects yes. [08:24] sorta. [08:24] spm: and they need that launchpad-pqm identity ? [08:24] heh. they have their own. like bzr-pqm :-) [08:24] The same PQM instance is used for multiple projects? [08:24] yeha. what spiv said. thanks andrew :-) [08:25] That seems strange to me, no wonder we're having trouble :) [08:26] haaa, I think I get it, the lp directory service is the one that create auth.conf, so that explains the difference [08:26] nice image for pqm :) [08:26] poolie: made me LOL yes :) [08:26] huh. default balleny doesn't have pyrex installed, just the bzr pqm chroot does. [08:27] vila, so on bugs like the pqm speed one, can we change the description/subject to something reflecting the general bug? [08:28] spm: strictly speaking the lp dir. service is wrong here, it shouldn't create an auth.conf file because... using different users to connect to the same host is not a case that auth.conf can handle (I think( [08:29] poolie: pqm speed bug ? # ? [08:29] sorry, i meant log speed [08:29] vila: fair enough [08:30] spm: the bad news is that the only work-around I can think of is 1) stop using lp: shortcuts, 2) always mention user@bazaar.launchpad.net in urls [08:31] Or set BZR_HOME differently for each pqm 'instance', as a substitute for having different system users. [08:31] vila: heh. 1, we'd kinda figured out, if not enunciated clearly. 2. ? [08:31] spiv: ahhh. that's easily doable I 'spect [08:32] spm: spiv idea is better :) [08:33] spm: same effect: the user is explicit so auth.conf is not injecting a bad one anymore [08:33] vila: spiv is more than just a teddy bear; you heard it here first. [08:33] dropping bear ? [08:33] vila: ah. right. [08:35] vila: so the upgrade/check. /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr revno /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0 ==> 4647 [08:38] seems about right [08:39] we should try check on it? [08:39] is running atm. just "/.../bzr check" yes? [08:40] err.. in /home/pqm/archives/thelove/bzr to be more precise [08:40] right [08:41] and did you tell pqm to stop processing mails? [08:41] thanks for doing it today btw, i know it's getting late [08:43] poolie: aye, processing bzr ones at any rate. is cool, I had to work later today anyway. [08:43] we can't 'bzr log' without showing any revnos at all ? Did we lose that or did I dream it ? [08:43] i don't recall having that [08:43] it might be useful [08:43] I thought --show-ids was doing that but no [08:49] poolie: I think you should create a 2.1 milestone, [08:49] good idea [08:50] creating 2.1 release branch may wait though [08:50] vila, it should be something different, like --no-revnos [08:50] poolie: I agree [08:50] vila, do you want me in particular to do it? [08:50] i don't mind, but don't you have access? [08:51] lifeless: i'm trying a conversion here and getting [08:51] oh no, it was just that I wanted to check with you first (you may have had (sp ?) a reason for not creating it) [08:51] bzr: ERROR: The file id "mpregen-20070411063203-5x9z7i73add0d6f6-1" is not present in the tree . [08:53] poolie: it was also mentioned in https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854 and really that's a new *series* that should be created :) [08:53] right, it should be both [08:53] though, um [08:53] :) [08:53] actually i'm not sure how this will interact and whether the milestone should be on trunk or on the 2.1 series [08:54] probably the second, for the final release [08:54] were you wanting to target something now? [08:54] no [08:54] but someone want, and in principle, since bzr.dev now says 2.1dev, 2.1 should exist [08:55] that's why I repeat the "create milestone" mantra several times in releasing.txt, because that's the one that is the most often forgotten [08:55] but no urgency, just something I wanted to get out of my mind and onto the RM shoulders :) [08:56] (that's the famous: "you can sleep now, that's not *your* problem anymore" joke :) [08:58] :) [08:58] poolie: bzr-gtk create milestones in the trunk series, I'm not sure that's better, but just have a look at https://edge.launchpad.net/bzr-gtk/+series [09:00] fyi: bzr check still running. just going afk for a bit; will be back in 10. [09:00] vila, they may not branch for releases? [09:02] vila, my point about the bug title is: don't mention "1233 revisions" or "on mysql" unless it really is specific to that case [09:02] indeed. I did the last two releases, but I just followed the existing practice. In retrospect, I'm almost sure it wasn't really a conscious decision, just a simplification that lp allowed [09:02] users always make them specific but i'm sure it's clearer if we make them as general as is appropriate [09:02] helps with removing dupes etc [09:02] i'll do a 2.1 series now [09:02] the little diagram is interesting [09:03] poolie: good point [09:04] yes, that's why I pointed you there [09:04] poolie: when did you last check your repo ;) [09:04] lifeless, "Handing over to a machine to do CI is just as expensive as handing to a colleague." -- Handing over to a machine is probably a little cheaper [09:04] it captures the release process amazingly [09:04] vila: the other thing forgotten is 'create NEWS headers' [09:04] lifeless: just now :-O [09:04] (advogato sucks for replies) [09:04] lifeless: I mentioned it in the cover letter [09:04] jml: for you, not for the machine :) [09:05] I thought you read it there first, but that's just more telepathy obviously :) [09:05] oh, no *create*, yes, I forgot that, I thought you were referring to NEWS header ordering with overlapping releases [09:06] but both are tied anyway [09:06] :P [09:07] lifeless: i'm just checking it again now in a clean local branch [09:07] lifeless, when you hand off to humans, you almost always have to transfer knowledge. that's less commonly true for machines. [09:07] poolie: also are you upgrading with the latest ? [09:07] although there's probably an argument-by-different-definition to be made there [09:07] yes, trunk as of today [09:07] i might use 2.0 instead though [09:08] jml: How about this: When you hand off to a human, you can stop worrying, but the act of handing costs more. When you hand off to a machine, you know its coming back to you if it fails, so there is some cognitive load. [09:08] jml: And I'm asserting that these, while different, are approximately the same [09:09] jml: what blog site did you end up using? [09:10] lifeless, I use blogger. [09:10] what would you like to see them improve? [09:10] lifeless, I think I'll use wordpress for my next project though. [09:10] hosted or self-run? [09:10] lifeless, ease of pasting code samples :) [09:11] and why wordpress? [09:11] lifeless, I host my own blogs currently, blogger sftps them to my site [09:11] interesting; and does your feedback too? [09:11] to your site, or from your site? [09:12] blogger uploads to my site [09:12] nice [09:12] I actually have no idea how comments work, but they do work. [09:12] lifeless, wordpress because it seems to have the biggest community and all the blogs I see that look good & use free software seem to use wordpress [09:13] lifeless: i just reproduced this failure on a fresh branch of bzr from lp into a fresh directory :/ [09:13] it's also quite flexible. [09:13] poolie: \o/ dogfooding [09:13] jml: and you'll self host again? [09:14] how do I get pqm-submit to not care about the fact that I lack a local copy of the branch I want to submit? [09:14] lifeless, probably. [09:14] though I understand that for wordpress that means more than it did/does for blogger [09:14] jml: patch it [09:14] jml: its on my 'do it the next time it annoys me' list. [09:15] jml: what are you submitting then ? pqm-submit is more or less supposed to ensures that *you* are submitting *this* [09:16] vila, I'm submitting a patch on someone else's behalf. [09:17] jml: irrelevant :) In principle you still need to "sign" *this*, where is *this* ? [09:17] vila: nah, thats recent [09:17] vila: pqm-submit is 'tell pqm what to do' [09:17] vila: there is no good reason to prevent clueful use being convenient. [09:18] lifeless: I know, hence my "in principle" and "more or less" [09:18] vila: I'm arguing the principle is unclear :) [09:18] like the bug on switch. boy that hurt :( [09:18] here's what I want [09:19] We agree :) I'm trying to avoid popularizing a hole I dislike in pqm-submit :-) [09:19] (as a hacker of Launchpad) [09:19] a fast test suite [09:19] a way of submitting an approved merge to land, conditional on tests passing [09:19] a great user experience [09:19] lifeless: :D [09:19] i'm posting a reproduction on bug 422423 [09:19] Launchpad bug 422423 in bzr "NoSuchId error upgrading to 2a" [Critical,Confirmed] https://launchpad.net/bugs/422423 [09:19] a way of submitting an approved merge to land [09:19] it's just a tarball from lp [09:19] lifeless, those too. [09:20] i have to go out with S now, but i'll come back and look at this [09:20] spm, we'd probably better not proceed until we get to the bottom of it [09:20] jml: please, its pretty obvious; take the code, opportunistically fix it. Use it and submit a merge. [09:20] jml: (like I did for removable :P) [09:20] lifeless, suree. [09:20] jml: by obvious I mean that the code is small and simple. [09:22] lifeless, yeah, I'll do it the next time I get a chance [09:22] but I don't have any more time to hack this evening [09:22] * igc dinner [09:22] and if I did, I really ought to use it to pack, not hack. [09:25] poolie: ok, at this stage the check actually failed. [09:26] interesting [09:26] so [09:26] we should probably reenable pqm, and not proceed further until we know what's causing this [09:26] https://pastebin.canonical.com/21673/ [09:26] oki [09:27] bzr pqm re-enabled [09:29] thanks [09:29] i'm going to look at it tomorrow, or at most later tonight [09:29] spm is that pastebin before it failed?? [09:29] it has no errors [09:30] found error:Internal check failed: revno does not match len(mainline) 1649 != 1674 [09:30] I'm not sure how serious an error that is? recommendations to RTFM will be ignored. :-) [09:34] that's a bit strange, and I can't see if it's for 0.8 or 1.8... 1.8 has 3766 revisions in the mainline anyway... [09:39] spm: ok, 0.8 has 1674 revisions so that's the one [09:41] spm: I'm pretty sure reconcile will fix that [11:05] I have 2 branches in the same directory, let's say branch1 and branch2, with a similar file structure. Can I copy branch1/lib/some_file.php to branch2/lib/some_file.php using bzr? [11:19] ping poolie [13:45] abentley: will you be doing a 2.0.0 release of bzrtools? [13:45] johnf: Yes. [13:46] jelmer: same question for bzr-svn :) [13:46] johnf: I'm going to release a bzr-svn matching bzr 2.0, probably bzr-svn 1.0 [13:46] johnf: not sure yet for bzr-git [13:57] has anybody seen james_w recently? === jam1 is now known as jam === jam is now known as jam1 === jam1 is now known as jam === kiko__ is now known as kiko === CardinalFangZzzz is now known as chad === chad is now known as CardinalFang [15:03] night all [15:22] HI there! [15:22] I just installed bzr! [15:23] Trying to merge my first lot of changes back to main branch - through tortoise bzr , i cant find a way to merge [16:13] is anyone else seeing launchpad be a bit slow to load today? === kiko is now known as kiko-fud === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch === garyvdm_ is now known as garyvdm === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno === gcerquant_ is now known as gcerquant === EdwinGrubbs is now known as Edwin-lunch === kiko-fud is now known as kiko === jkakar_ is now known as jkakar === Edwin-lunch is now known as EdwinGrubbs [19:50] how do you perminantly remove something from a branch [19:51] you can't [19:51] aww, i thought i remember reading something somewhere that you could [19:52] you can remove a revision from a *branch* by using "bzr uncommit" [19:52] uncommit only removes from the head it seems [20:08] Kobaz: You can do it, by branching it to a new branch, and deleting the old branch. This won't remove it from other branches that may have the revision. [20:08] k [20:09] so if you like, delete stuff, and then branch? [20:09] or do uncommits, and then branch? [20:09] Hi jelmer [20:11] jelmer: was going to ask if you knew of any code that uses ui.get_username, other than bzr-svn, but I see that bzrlib/config.py uses it. [20:14] do uncommits, and then branch [20:57] moin [21:00] jam: ping [21:00] morning lifeless [21:00] howzitgoing? [21:03] pretty good [21:03] jam: so, recompressing [21:05] I'm trying to evaluate real-world effect. but making branching from scratch significantly slower isn't a real gain, IMO [21:05] if it was only incremental, then maybe [21:06] Without this we will still fragment [21:06] sue to incremental pushes to common repos [21:06] s/sue/due/ [21:07]