[00:15] thewrath: did you install bzr using cygwin's setup.exe? [00:15] lifeless, yesterday, you suggested that there were bugs for 1.16.1 other than bug 365615 and bug 390563 [00:15] Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615 [00:15] Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563 [00:15] lifeless, can you please point me to them? [00:15] jml: did I? I thought I said I was flat out :P [00:15] jml: and I recall talking about 2.0 in terms of what bugs there were [00:16] anyhow, I'm not aware of other 1.16 worthy cherrypicks === mthaddon is now known as afk === afk is now known as mthaddon [00:16] once abentley's skip-dupes patch lands in trunk that might be worth putting in 1.16 too; though I thought lp devs ran off nightlies [00:19] lifeless, we do run off nightlies. === mthaddon is now known as afk [00:20] in which case there are no other patches for 1.16 that I know of [00:20] ok. [00:20] what about things to cherrypick to Launchpad? [00:21] mwhudson has them in hand [00:21] sweet. [00:21] thanks. [00:32] morning [00:33] hai [00:33] hi lifeless [00:49] jml, re your "branches that fix bugs" [00:49] there are some more cases like that in devnotes 3.0-ui document [00:49] http://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html [00:50] poolie, ahh thanks. [00:50] poolie, I'd been meaning to refresh myself on the devnotes branch but let it slip my mind. [00:51] np [00:51] i don't necessarily want that document to become a laundry list of every possible thing you could want to do with bzr [00:51] but these are at least a bit related [00:51] also airing them on the list may atract more thoughts [00:53] well this has a specific focus I guess [01:15] jml, could you send a short metronome mail re 1.17? [01:17] poolie: yep, it's already on my list for today [01:17] oh cool [01:17] maybe i should send one about 1.17 vs 2.0 [01:18] that's probably a good idea [01:21] my list for today is perhaps slightly too long, but I know only one way of making it shorter. [01:24] poolie: I'm also going to cut 1.16.1 today, if I can. [01:24] delete things? or do things? [01:24] i was planning to do both :) [01:24] do things. [01:32] igc: I'm working on iter-changes today [01:32] igc: now that the crisis with fetch is fixed [01:32] lifeless: cool [01:32] igc: I'd appreciate your holding off your other landing ;) [01:33] lifeless: I'm doing reviews and clearing the desks to work on bug 374735 [01:33] Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Triaged] https://launchpad.net/bugs/374735 [01:33] sure [01:34] hello igc, lifeless [01:34] hi poolie [01:34] i'm planning today to: send a coscup abstract, (re)send a blog acct to igc, write up a patch explaining the 2a format, do the minimal activity-tied-to-pb fix, order a new disk [01:34] hi poolie [01:35] talk to spiv === Toksyury1l is now known as Toksyuryel [01:35] and hopefully get other uifactory fixes done [01:35] they have a tangle-of-string quality - fixing each test makes for larger changes [01:36] all good, but it's not converging [01:36] so sometimes i take a step back and try something smaller [01:36] but still [01:48] thanks for the review igc [01:54] another unusual error from our systems: https://devpad.canonical.com/~matsubara/oops.cgi/2009-06-25/SMPM01 [01:55] http://paste.ubuntu.com/203878/ [01:55] it would be nice if that was openid [01:55] when mirroring http://bzr.malept.com/avant-window-navigator [01:55] yes. [01:55] didn't you file a bug on that 3 weeks ago? [01:56] I don't think so. [01:56] https://bugs.edge.launchpad.net/bzr/+bug/377453 ? [01:56] Ubuntu bug 377453 in bzr "Error from smart server: ScopeReplacer object '_KnitGraphIndex' was used incorrectly" [High,Confirmed] [01:57] oh good. [01:57] hmm, different but similar [01:57] add it to the same one I think [01:59] done. [02:00] so, iter_changes tests existing now [02:00] time to fix implementations [02:13] can anyone confirm: setup.py build_ext -i is putting the so files in bzrlib/bzrlib/ ? [02:14] * fullermd hasn't seen it... [02:16] * igc school visit & lunch - bbl [02:17] bug 392355 [02:17] Launchpad bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged] https://launchpad.net/bugs/392355 [02:17] lifeless: no [02:17] mwhudson: python version? bzrlib version? [02:17] mwhudson: are you on karmic? [02:17] lifeless: no [02:17] python2.6 jaunty 4477 [02:17] jml: you're on karmic aren't you... could you check for this (in 1.16 and-or bzr.dev) [02:18] 4479 sorry [02:18] I just did a fresh branch of lp:bzr and they're all in bzrlib/ where they belong. [02:19] fullermd: when you run setup.py build_ext -i ? [02:19] Yah. [02:19] Well, ./setup.py [...] [02:19] fullermd: so bzrlib/*.so, not bzrlib/bzrlib/*.so [02:19] Right. [02:19] ok [02:19] thats good data [02:19] It could well be setuptools [02:19] (py 2.6) [02:19] sorry distutils or something [02:20] (9:17:33 PM) thewrath: hey guys with bzr or svn any way to find the number of modified lines [02:20] (9:17:50 PM) thewrath: svn diff | grep "^+" | grep -v "^+++" | wc -l gives you added lines [02:20] (9:18:00 PM) thewrath: svn diff | grep "^-" | grep -v "^---" | wc -l is removed [02:20] (9:18:13 PM) thewrath: but i need modified lines and unmodified lines [02:20] what are you trying to calculate [02:21] lifeless, the bug refers to 'make build' -- I don't even have a build target in my copy of bzr. [02:21] jml: I fabricated. just 'make', or setup.py directly [02:22] i need to find the total number of added, removed, modified and unmodified lines from revision a to revision b [02:22] the first three are easy [02:22] the last one is much harder [02:22] 'modified' can be pretty tough to quantify... [02:22] I'm not aware of any simple way to do it [02:22] lifeless: how u calculate the modififed [02:23] thewrath: I'd use some of the existing python libraries to parse the diff and turn added and removed into modifications when they are adjacent [02:23] thewrath: be a couple of hours work top, at most. [02:23] thewrath: anyway, why do you want this? [02:23] igc, re the revert patch [02:23] lifeless: its for work [02:23] can you try to add a blackbox test? [02:24] I actually thought diff(1) had an arg to show the whole files, which would help with the last, but it doesn't seem to. [02:24] there's a slim nonzero chance it'll break [02:24] You could fake it by asking for 99999 lines of context, I guess. Would work on all those sub-100kLOC files. [02:25] lifeless, https://bugs.edge.launchpad.net/bzr/+bug/392355/comments/1 [02:25] Ubuntu bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged] [02:25] fullermd: we don'tsupport that argument, I don't think [02:25] Well, but we could use the external diff, instead of the internal one. [02:25] jml: so its broken for you too [02:26] yep. [02:26] lifeless: can i sent you a pm [02:26] thewrath: I guess === BasicPRO is now known as BasicOSX [03:02] lifeless, does this critical bug mean I should use a chroot to rollout 1.16.1? [03:02] I guess I could always experiment. [03:03] jml: the so's don't go in the tarball [03:03] jml: so no special actions required there [03:03] however johnf probably needs to know to build debs properly [03:04] and all the C files go to the correct place, I see. [03:24] just popping out to the chemist [03:24] brb [03:45] * spiv pops out for food === abentley1 is now known as abentley === abentley1 is now known as abentley [04:18] deep hack time [04:19] SMS or ring if you need me === r0bby is now known as r0bby|arr === r0bby|arr is now known as r0bby [04:30] lifeless: (realize you're away) fix for progress bar droppings pushed [04:31] yay hacks === abentley1 is now known as abentley [04:47] poolie: yay [04:47] poolie: do you need a review? [04:47] yes [04:47] is easy [04:48] i also need a lunch [04:48] is it 'if count < 1: return' ? or something like that? [04:48] close [05:22] * jml sends a metronome email [05:25] Oh, good, the RC is on my mother's birthday. Now I'll remember to call her. Just don't slip the date! [05:31] igc: may have found other latent commit bugs with this work :) [05:33] lifeless: I recall raising one or two when I was last looking in there [05:44] thanks lifeless [05:51] ok. time to cut 1.16.1. [05:51] it's going to look a _lot_ like the current launchpad branch of bzr :) [05:59] jml: yay releases! [06:04] lousy internet :( [06:04] glyph, Twisted should do time-based releases! [06:05] jml: you know what else [06:05] jml: Twisted should have a release manager [06:06] jml: and a hundred billion dollars. [06:06] glyph, and a pony [06:07] maybe I'll steal the RM job from radix [06:07] if only I were less of a bum. [06:10] jml: well, relatively speaking [06:11] :) [06:12] has skip-dupes landed in bzr.dev? [06:13] hmm. computer says no. [06:13] there's no bug associated with it either [06:13] its not needed for 1.16.1 anyhow [06:13] because 2a is not popular, and you're landing a separate fix that means skip-dupes isn't needed anyway. [06:14] (needed in terms of 1.16.1 as a server, or locally) [06:14] ok. [06:18] still love merge --uncommitted. [06:24] when doing a point release... [06:24] ? [06:24] should I change the introductory paragraphs? [06:24] I make use of it in nasty and evil ways on many occasions. [06:24] in the NEWS file, that is. [06:24] the whichwhat? [06:24] its a new release [06:24] it should get its own intro [06:25] OK. That's not how 1.14 & 1.15 were done, but it is how 1.13 was done. [06:31] can someone please look over the release announcement? [06:31] http://paste.ubuntu.com/203968/ [06:34] poolie, lifeless: ^ [06:42] new codename needed I think [06:42] and the top line should say 1.16.1 [06:42] this is a new release; 1.16 is the series [06:43] personally, I don't htink you should be moving the bug block [06:43] big block* [06:43] that was the 1.16 release [07:02] * jml tries to find prior art to copy from [07:02] use case for you [07:02] 'I am a debian user and I have 1.16 already' [07:02] they should see the new changes they are getting. [07:14] hi all [07:14] hai [07:14] * vila stares at the restart button (triggered by the ssl update) :-/ What the hell these days ! [07:15] back in a restart [07:19] re-hi [07:28] poolie: ping [07:39] I'm off. Back later to finish the bzr 1.16.1 release. [07:43] jml: excellent metronome mail ! [07:43] vila, thanks. [07:46] lifeless: still around for a quick chat ? [07:47] vila: sure [07:47] whats up? [07:47] jml: when you return, testresoureces has branches that need your personal touch === cprov-afk is now known as cprov [08:23] night all [08:24] hello vila! [08:24] jml, yes, really nice mail there [08:25] i mean the metronome one [08:25] jml, if you're still here, the release mail draft confuses me [08:26] it almost looks you you're marking all of the trunk changes as being in 1.16, which would either be inaccurate or a mistake [08:37] I got a centralized repo to which I was the only committer. someone has an --unchanged commit on it since a few hours. I try to push my work but I keep getting "branches have diverged" [08:37] bzr merge tells "nothing to do". bzr pull tells "no revisions to pull". bzr up tells "Tree is up to date" [08:37] what am I supposed to do? [08:38] Adys: You can either 'push --overwrite' or 'merge; commit; push' [08:38] merge doesnt work =/ [08:38] I dont know if its a bug [08:39] ill try push --overwrite [08:39] Adys: wait [08:39] Ok [08:40] 'push --overwrite' will ignore the --unchanged commit and make it hard to get back to, while 'merge; commit;push' will take into account [08:40] Adys: what do you want to do ? [08:40] vila, merge doesnt work [08:40] it tells "nothing to do" [08:41] Adys: It works then, doing nothing is sometimes the Right Thing :) [08:42] hm [08:42] hold on i screwed something up ... [08:42] Adys: What does 'bzr info' says ? Are you working with a standalone branch, a checkout ? [08:42] standalone [08:42] uh, is there some way to undo a pull? =P [08:43] Adys: 'pull --overwrite' [08:43] Yeah I just did that, it had an old location saved [08:44] think I lost some code.. not a big deal [08:45] Adys: committed or not ? [08:45] yes [08:45] committed but not pushed [08:45] then it's not lost [08:46] How do I get it back? [08:46] you have to find the revid you're interested in and pull it somewhere safe first (aka, not in your current branch) [08:47] okay [08:49] vila: I need to grab rev 525, but when I branch it it updates to rev 524 [08:49] use 'bzr heads --all' and see if you can find it back [08:51] found it, what do I do now? [08:51] HEAD: revision-id: adys@azura-20090626072855-ze3ykij2nuraihhe (dead) [08:55] Adys: bzr branch -rrevid:adys@azura-20090626072855-ze3ykij2nuraihhe [08:56] Adys: replace and by valid and appropriate values [08:56] Ah great stuff, thanks. :) [08:58] hello hello [08:59] poolie, had a chance to sanity check? [08:59] vila: got it all sorted, thanks a lot! [08:59] Adys: Always happy to help (TM) [08:59] ™ [08:59] gasp [08:59] unicode [08:59] gasp, customized keyboard layouts :D [09:04] bazaar-vcs.org appears to be down :( [09:04] jml, i don't think it is present... [09:04] still checking [09:04] jml, srsl? [09:04] srsly* [09:05] poolie, yes, srsly. [09:06] Indeed. Cool! Can't connect. [09:07] fixed [09:07] (thanks elmo) [09:08] That was quick. What was wrong? [09:08] buggered if I know :) [09:09] jml, it certainly looks like it's not in there [09:09] i wonder how the text got into news? [09:09] jml i guess launchpad got fixed? [09:09] which bit of launchpad? [09:10] apache upgrade didn't restart cleanly; sorry about that [09:10] peng: ^-- [09:10] Oh. [09:11] jml, the appserver outage? [09:11] poolie, yes. that got fixed [09:14] poolie, what's the number of the bug that appears in NEWS that isn't fixed? [09:15] bug 376478 [09:15] Launchpad bug 376478 in percona-xtrabackup "Specify Target Directory Name with innobackupex" [Undecided,New] https://launchpad.net/bugs/376478 [09:15] you cherrypicked trunk r4470 [09:15] which claims to fix that [09:15] ah [09:15] https://bugs.edge.launchpad.net/bzr/+bug/376748 [09:15] Ubuntu bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released] [09:15] it might just be lack of cherrypick tracking... [09:16] normally people tend to merge the bugfix branch into the release branch rather than cherrypicking [09:16] but it's a reasonable enough thing to do [09:18] Can I fake the timestamp on a bzr commit? [09:18] yes. [09:18] (without changing my system clock) [09:18] of course in this case you couldn't because it was based off too late a version of trunk [09:18] soren, yes [09:18] Cool. How? [09:19] Python! [09:19] (looking up the api) [09:19] I was afraid you'd say that. [09:19] Oh, well. [09:22] Hm... Doesn't look to hard at all. [09:22] (famous last words) [09:24] soren, yeah... I think I'd just hack something up based on cmd_commit(). [09:24] possibly even add an option to cmd_commit for the timestamp. [09:26] poolie, so where were we? [09:26] i'd be ok with an option to cmd_commit [09:27] jml, it's in, and it seems like a reasonable thing to put in [09:27] so i think we're good to go [09:28] rock'n'roll. [09:29] spiv, still around? how did you go today? [09:37] I have a question: I do bzr status and I get a lot of modified files, even though they haven't been touched. But they have an * at the end. What does that mean? [09:38] help form bzr hackers needed [09:38] see http://pastebin.com/m40991c66 [09:38] why I've got error? [09:39] jml: Oh. I was thinking of just calling bzrlib.commit.Commit.commit() from python with the right arguments. This is (hopefully) just a one-off thing. [09:40] jml: Oh, that is what you're suggesting as well. [09:40] soren, basically, yes. [09:40] * soren has not had sufficient coffee today. [09:41] soren, although tweaking the commit command is probably even less work, as long as you don't bother with user-friendly parsing & data validation. [09:41] which you won't, because it's a one off thing :) [09:41] True, true :) [09:45] Wyvern: The executable bit probably changed. [09:47] Indeed! Thanks. [10:05] jam: FYI, mail2.domainpeople.com yelled at me when I tried to send an email to you. (Nothing important, I just used Reply All on a mailing list post.) [10:06] is CommitBuilder.record_entry_contents() going to be removed before 2.0 ? === jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ [10:19] *mutter mutter* [10:20] conflicts are teh suck [11:07] How do I specify a base revision during a merge? [11:08] I'm trying to merge two trees that have no common ancestry (bzr-wise, but in the real world, they do), and "bzr merge" suggests that I can somehow do it anyway if I specify a base revision for the merge, but I don't see how to do that. [11:11] soren: "bzr merge -r0..-1" will allow you to merge unrelated (bzr-wise) trees [11:12] soren: because 0 is common to histories, in a sense. [11:13] Yeah, I was hoping that would be the case (0 being everyone's grandparent). [11:13] haha.. [11:13] spiv: YEs, that seems to do the trick. Lovely. Thanks! === mrevell is now known as mrevell-lunch === Xavura is now known as Xavura|busy === mrevell-lunch is now known as mrevell === nevans1 is now known as nevans [14:44] abentley: [14:44] awilkins: [14:44] abentley: How easy would "parallel" support be in bzr-pipeline? [14:45] awilkins: Not terribly hard, but if the parallels ever met, that would cause criss-cross merges. [14:47] abentley: I posted to the list about supporting something similar in loom ; the idea of having a web of patch branches that all converge on a single "work" branch, with UI assistance for committing the correct hunks to the appropriate branch [14:47] Like Mercurial pbranches (only they don't have that UI support) [14:47] awilkins: If by converge, you mean A -> B -> C, A ->D -> C, that would be very, very bad. [14:48] abentley: Because each branch would be receiving the same merges from the base branch? [14:50] awilkins: Well, let me think about this. [14:50] For reference : http://arrenbrecht.ch/mercurial/pbranch/ [14:51] awilkins: You get criss-cross when you merge in an inconsistent order, and thereby repeat the merge of revision X with revision Y in two places. [14:51] awilkins: It may be that a pipeline can prevent that, but I'd have to think about it. [14:54] abentley: I have this mental picture of a commit dialog in qbzr where the patch is on the left and there is a radiobutton column on the right for each patch branch and you select which hunk goes where. [14:55] awilkins: I've never been a fan of selective commit, but I can envision adding it to the uncommitted changes of that pipe. [14:56] abentley: Does each pipe have a working tree? [14:56] awilkins: No, each pipe has a shelf. [14:57] abentley: That sounds like the implementation I had in mind ; shelve the changes and switch-unshelve-commit for each branch [14:58] abentley: I just don't have the time to actually write it though [14:58] awilkins: I'm suggesting that the user would still commit the changes, rather than having it happen automagically. [15:01] abentley: I can see that working as long as you're not allowed to commit to a branch that depends on branches with shelved changes [15:02] awilkins: I think that restriction would not be workable. [15:03] abentley: How do you cope with the scenario when you want to commit C, and B has changes in it's shelf ; the changes are presumably in the working tree of C also, and you've just committed them? [15:03] abentley: how can I tell if a given installation of bzr is built with the C extensions? [15:03] kfogel: Presence of .pyd files [15:04] awilkins: It would be unusual for the changes to be in the working tree of C also. [15:04] awilkins: thank you. where would they be? (some python path on my system?) [15:04] abentley: I thought A -> B -> C ... doesn't that imply that the changes from B are in C and C may even be dependant on them [15:05] kfogel: They should be in the bzrlib folder [15:05] awilkins: thanks [15:05] kfogel: "lib" on Win32 bzr.exe, %PYTHON%/lib/site-packages/bzrlib for win32/python [15:05] awilkins: No, it doesn't imply that. When you want that to be true, you run the "pump" command. That merges from A->B->C, but it doesn't do anything with uncommitted changes. [15:06] abentley: I'll have a play with bzr-pipeline for a bit and think some more [15:06] abentley: It sounds like I'm not totally grokking the way it work [15:08] abentley: Is there a good source of documentation besides the help? I've only found the launchpad page (after seeing it mentioned o the mailing list) [15:08] awilkins: The way it works is, you're hacking on something in A, then you realize you need to fix B. You switch-pipe B, which automatically stores the uncommitted changes in A. You fix B and commit. You switch-pipe back to A, which restores your changes. You finish hacking in A. You pump, which applies the changes in A to B, and the changes in B to C. [15:10] awilkins: "bzr help pipelines" is the main documentation. There's also a comparison with looms in pipeline-and-loom.txt in the source tree. [15:10] awilkins or abentley: if I have done a long-running 'bzr upgrade --2a' to get a tree to 2a format, and I *think* it completed (but for various reasons am not sure), is there some command I can run to verify, other than 'bzr info -v' ? [15:10] abentley: That help topic doesn't seem to be in the lp:bzr-pipeline trunk [15:10] awilkins: Sorry, "bzr help pipeline" [15:11] kfogel: On the same topic, I've been running --2a conversions and getting segfaults on windows where it just fails silently, so I'm no help here [15:11] awilkins: ugh. no useful trace? [15:11] Peng: I believe my mail host no longer allows direct emails from people, you have to go through official ISPs [15:11] kfogel: bzr info -v won't tell you whether it's well-formed. You would need to run "bzr check" for that. (Which takes a verry long time) [15:12] kfogel: Just a minidump and an offset in the groupcompress extension [15:12] abentley: 'bzr check' time comparable to the original 'bzr upgrade' time? [15:12] kfogel: I'd make a trivial branch and upgrade it to 2a to see what the successful log output looks like [15:12] (because that was almost 4 days) [15:12] kfogel: worse. [15:12] abentley: holy cow [15:14] abentley: Ok, it still sounds compatible with my intentions as long as the criss-cross merge is dealt with [15:15] abentley: Because you would actually be working in C, you know how the merged output should look because it's what you actually wrote, so does that make it easier? [15:16] awilkins: I don't know what you mean by "you would actually be working in C". [15:16] abentley: You have pipes A > B | D > C [15:17] So when you pump, changes in A are merged to B and D and then C [15:17] So you end up with two merge revisions being merged to C and they are a crisscross merge [15:18] If you are editing in C and your "chunk selective commit" has directed some changes to go to A, some to B and D (and none to C because it's just a convenient tip to amalgamate patches) [15:18] A > B, D > C does not lead to a criss-cross merge. [15:18] awilkins: Why would changes from B be merged into D? [15:19] abentley: Not from B to D [15:19] That would be a linear pipeline of A > B > D > C [15:19] A to B and D [15:19] B to C, D, to C [15:19] awilkins: So you really men A > B, A > D > C? [15:20] abentley: And B > C also [15:20] Including an additional revision of changes to B and/or D [15:21] awilkins: As long as the parallel lines don't merge from one another, I'm not sure that leads to a criss-cross. But I still need to think about that. [15:22] awilkins: In any case, if you pump from A, you're not necessarily "working in C". That would only happy if conflicts were encountered merging into C. [15:23] abentley: I'm thinking ; edit with the lightweight checkout aimed at "C" ; commit chunks to A, pump [15:24] abentley: Because you're editing in a checkout of C, you know how the end state of the tree should look, so you either don't have conflicts or you know exactly how to resolve them before you start the merge [15:24] I'm not sure you don;t have conflicts 100% of the time [15:24] awilkins: If you're in C and you pump, that will do nothing, because you pump from the current pipe to the following pipes. [15:24] awilkins: If you're in C, you can't commit chunks to A. [15:25]