[00:01] morning [00:02] morning igc [00:23] lifeless: you're going to make the bzr.1.5 branch today, right? [00:31] http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/ === mw is now known as mw|out [02:32] found it .. http://svn.blastwave.org/trac [02:33] oops [03:40] * igc food [04:07] Hi everyone, how do I commit only a single file so that bzr send will generate a patch for only 1 file [04:08] bzr commit FILENAME [04:08] bzr: ERROR: Selected-file commit of merges is not supported yet: files Do.Addins/src/Do.Universe/ApplicationItem.c [04:08] lamalex: Yup, this was where I was about to suggest ;) [04:08] this smeans you have done a merge, but not committed the result [04:10] so solution? [04:10] commit [04:10] :P [04:10] The shelf plugin can be your friend here. [04:10] do the commit [04:10] if the branch you are merging is your upstream send won't include changes from the upstream in the sent content anyway [04:12] thanks guys [04:13] oh jeeze! So I did a commit on just the one file after, and bzr send still generated a patch for /all/ changed files [04:17] any idea how to only generate the patch for the 1 file? [04:21] "bzr diff" will give you a diff for one file [04:21] but if you want "bzr send" to give you a bundle for one file, then the bundled revisions need to have changed just the one file [04:21] (relative to the submission branch) [04:23] so I'm SOL for bzr send, and should just diff it [04:23] and advantage of using bzr diff over gnu diff? [04:23] well, you can always prepare the change in a new branch [04:23] ignore my previous question [04:31] lamalex: bzr send -r x..y will probably do what you want [04:31] lamalex: it sounds like you want to send in one commit, not all of your work [04:31] yeah [04:31] lamalex: this is the usual confusion that I have seen [04:31] I've had the problem a few times :P [04:31] I always forget how to do it [04:31] wrote it down this time [04:32] lamalex: the name for doing this, irrespective of transport (branch/bundle/patch) is 'cherrypicking' [04:33] thanks [04:42] lifeless: still no luck, I'll just do a diff [04:43] lamalex: What's wrong with `bzr diff path/to/file`? [04:44] I was under the impression that bundles were better [04:44] nevermind; didn't read enough scrollback. [04:44] :) [04:47] lamalex: you probably have more than just one file changed; or are nto using the correct arguments - the list had a good discussion about bzr send just this week [04:47] I'll check it out, thanks for your help [04:47] I'm happy to debug futher if you like; remember though that send's finest granularity is a single commit [04:49] I have to go to bed soon, I have a sociology final in the morning [04:50] go then ! [04:51] :) I've still got 9 hours! [04:52] well, I guess 6:30 of sleep, but that's plenty. Thanks for the help. [05:10] curious, for a bzr-svn branch, is there way to effectively convert that into a standalone bzr branch- specifically, converting it to a knit repository? [05:13] bzr-svn branches are native bzr branches [05:13] bzr info will tell yo the current format [05:19] lifeless: branched from the svn branch to a "Standalone tree (format: rich-root)" [05:20] from there, trying to branch from the standalone into a shared repository (pack-0.92), but getting no love; error msg is essentially "knit pack repository is not compatible with knit repository" [05:22] so... something there isn't right. :) [05:22] (attempts to upgrade the svn branch fail also) [05:23] You can't go from a rich-root format (rich-root, rich-root-pack) to a non-rich-root format like pack-0.92. [05:24] If you want to upgrade to packs, "bzr upgrade --rich-root-pack". [05:24] bingo [05:24] Peng: that's working for the svn branch; from there, probably will fly for pulling it into my shared repo [05:25] what is a 'rich root pack' anyways? just a new format, or [05:26] ferringb: rich-root-pack is like pack-0.92, only it has rich roots, meaning it stores slightly more meta data. [05:26] ferringb: rich-root is like dirstate-tags, only it has rich roots. [05:33] ferringb: as peng says, rich-root stores more data; you can't go back to a plain repo from there [05:33] ferringb: we will very shortly (probably 1.6 I think) be making rich root our default format [05:33] abentley: around ? [05:34] lifeless: Hi. [05:34] any chance of a brief skype call? [05:34] Sure. I'm just finishing up something with thumper. [05:35] 5 minutes? [05:36] Sure. [05:42] I couldn't hear you. [06:28] k, thats my work day done; later all [06:28] thanks abentley [06:28] lifeless: np [06:34] the "if self.new_inventory_root is None" branch in CommitBuilder.finish_inventory() (bzrlib/repository.py) looks broken [06:34] AssertionError doesn't take a "stacklevel" keyword argument [07:02] I'm running bzr 1.4 under cygwin. Every time I try to do a checkout it spits back bzr: ERROR: [Errno 0] Error [07:05] any ideas? [07:06] docgnome: You could pastebin the traceback and .bzr.log section. But I dunno how much the developers care about supporting Cygwin. === abadger1991 is now known as abadger1999 [09:04] Hi there, I don't understand one thing of bzr: is it possible to manage more than one branch in the same local repository? [09:04] or should I always copy the current directory to a new one? [09:06] night all - have a good weekend === mrevell is now known as mrevell-lunch [12:56] hi [12:56] anyone has any ideas why i could be getting "bzr: ERROR: exceptions.AssertionError: 2412 != 2413" ? [12:56] when trying to commit [12:57] "assert len(history) == revno, '%d != %d' % (len(history), revno)" to be more accurate [13:11] ignas: Your revnos are a little off. There's info on either the mailing list or bug tracker, if you can find it. [13:12] is it fixable? [13:12] ignas: Yes, but I don't remember the details. [13:16] emm i don't think the fix is in hardy though :/ === mrevell-lunch is now known as mrevell [13:27] the "production ready" part of bzr is sometimes giving me doubts... === jw2328_ is now known as james_w [14:23] bzr check is stuck in [ ] checking versionedfile 0/12726 for like 30 minutes [14:23] should i be worried? === korpios_ is now known as korpios === korpios___ is now known as korpios [15:33] vila: your patches are going to the wrong mailing list [15:34] huh ? [15:34] vila: you are sending to "bazaar-commits@" not "bazaar@" [15:34] aaargh [15:34] your merge requests [15:34] thanks for the heads-up :) [15:35] hmmm, on another project I took the habit to use 'bzr send', get bitten there :) [15:35] 'bzr send' with no params I meant [15:35] vila: well, send should do the right thing, but you have to set your 'mail_to' [15:36] as opposed to you "post_commit_to" [15:38] only post_commit_to seems to be defined... [15:41] hehe, no, submit_to was defined (with a wrong value), and it's really submit_to, not mail_to [15:42] spiv: are you still around? [15:42] vila: anything you want to try to sneak into the 1.5rc1 release today? [15:43] --starting-with ftw :) [15:43] bug fixes can wait next week isn't it ? [15:43] jam: not really ;) [15:43] jam: I think my big patch should miss 1.5 [15:43] spiv: k, I was checking in [15:43] I would have liked to have it [15:43] but it seemed a bit large for a last-day approval [15:44] anything else in the queue? [15:44] jam: happy releasing! [15:44] * spiv -> sleep [15:44] spiv: good night [15:44] igc: ping, for great justice, and things you want in 1.5rc1 [15:44] poolie: I know you're not here, but just in case [15:44] lifeless: Anything you need me to merge for 1.5rc1? [15:45] jam: thanks for the weekly report, I think it's a good thing to have. [15:45] james_w: well, thank statik as it was his idea, but I agree that it is a good one [15:45] statik: thanks! [15:45] vila: this is 1.5rc1, so not really [15:45] vila: we forgot todo a feature freeze bugfix release [15:46] james_w: glad you liked it! [15:46] vila: martin is wanting to get back on schedule, rather than having them all keep slipping [15:46] hi jam [15:46] igc: you know, I'm always shocked to see you guys awake and online at this time [15:46] me too :-) [15:46] jam: igc is an unstoppable code machine, he only closes his eyes to make everyone else feel normal [15:47] :) [15:47] statik: just finished watching a movie actually ... [15:47] jam: good, I'm always bad at sync with the releases schedule anyway :) My remark still stands, I'd be happy to have --starting-with (really only the doc tweak requested by martin needs review), the bug fixes I'm issuing today are not urgent, if you don't have the time to handle them, no worries [15:47] and checking on the Out Of Memory bug that has me intrigued [15:48] igc: the change you made in fast-import is because it isn't double-buffering [15:48] Maybe also the lines variable isn't getting GC correctly [15:48] but doing line.append().... ''.join() has to allocate 2x memory [15:48] now, line += '' has to re-allocate as well [15:49] but IIRC, CPython is able to re-use the memory (using realloc instead of a new malloc/free) [15:49] but that is a "don't expect this to always work" feature of CPython [15:50] igc: you're coding while watching a movie ! Wow, I'm impressed :) [15:50] StringIO is arguably more likely to use memory better than += [15:50] vila: nah - movie over 30 minutes ago [15:50] igc: Though I'm mostly guessing, anyway anything pressing for 1.5rc1? [15:50] and spiv talks while sleeping, those australian guys.... [15:50] I can take a look at your doc patches [15:50] Probably even better is probably not combining string objects at all. [15:50] while we *can* bring them in later, I'd really like to respect the spirit of a "release candidate" [15:52] jam: np. I'd really like the plugins+integration doc patch in if it's ok [15:52] igc: reviewing now [15:52] the other one is getting closer ... [15:52] I'll see if it's worth resending it tonight (or not) [15:59] igc: does the "part2_intro.txt" belong in the "A brief tour" chapter? [15:59] jam: yes [15:59] It seems like you are starting a whole new chapter/book/etc and that paragraph is "above" that section [15:59] jam: if we split the chapters into parts, that would be true [16:00] we don't have partsa so it's at the start of the first chapter in that part [16:00] in the current guide, similar text intros "Best practices" fwiw [16:01] igc: overall bb:approve [16:01] igc: can you get it sent in now, so it is queued up for me? [16:01] jam: cool, thanks [16:01] sure [16:03] jam: I sent 3 patches, you catch up on the second one (but the third was already send), I re-send the three to the right address [16:04] I saw a couple of them come in, reviewing now [16:04] jam: thks [16:15] hmm, if I have a checkout from a remote bzr shared repository, and run bzr reconcile in the checkout [16:16] will that fix - my local checkout, the revisions from that branch in the remote repository, the whole remote repository? [16:19] hi all [16:19] hi [16:20] vila: reviews are in [16:21] jam: thks, what about --starting-with then ;-) [16:21] what should i do to convert my dir-with-subtree repository to a non subtree one? the only format i can convert without errors is pack-0.92-subtree [16:21] vila: can I get a --starting-without ? [16:21] jam: are you the same person who worked on https://bugs.launchpad.net/bzr/+bug/177855 ? [16:21] Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix committed] [16:22] ignas: I am, though today is release day, so I might not have a lot of time [16:22] ignas: "reconcile" fixes the local repository [16:22] jam: how do i fix the remote one then? [16:23] ignas: bzr reconcile sftp://url/to/repository [16:23] though I might recommend [16:23] ssh host [16:23] bzr reconcile /repository [16:23] jam: If there is a joke, I miss it 8-/ [16:23] i think the fix is not in ubuntu yet [16:23] or is it? [16:23] vila: you added --starting-with, I'm asking for -without [16:23] ignas: bug #177855 is not in ubuntu yet [16:23] Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix committed] https://launchpad.net/bugs/177855 [16:23] well, the fix [16:24] what will that means ? [16:24] ignas: I think it is in bzr.dev, and if so, it will be in 1.5rc1 which I am releasing today [16:24] if it's not then I would have to get a bzr checkout working on the remote server somehow, then run it there and take care so it would not mess up permissions on the central repository ... [16:24] jam: i see [16:24] vila: I have no idea, it is just the "opposite" of whatever you were trying to do [16:24] jam: thanks for fixing it [16:25] jam: ha ! A joke then ;-) Sorry, a bit slow today [16:25] vila: well, it wasn't a very good joke, either [16:28] A good joke needs puns, and dancing sheep. [16:29] vila: could you make it --starting-without-dancing-sheep then? [16:29] Yeah. They're better when they don't come in 'till the second act. [16:31] vila: so you didn't do the 'auto-prefix' right? [16:32] no, I think defining aliases is my prefered solution, we could add an auto-prefix for 'bzrlib.' later, I' always very cautious when it comes to UI tweaks a-priori ;-) [16:33] vila: I don't think you can do it with an alias, just because it won't stack [16:33] but yeah, I'm okay with bringing this in first [16:33] as I think it is something we can add later [16:33] I was also thinking something like [16:33] bzr selftest -s B.T.aoeuaoeu [16:33] and have B.T always expand to bzrlib.tests [16:33] and maybe B.P to bzrlib.plugins, etc [16:34] but that is for discussion [16:34] certainly not for your review right now [16:34] jam: exactly, you just came up with someting better than a raw bzrlib. , let's get more people playing a bit and I'm sure a better scheme will emerge [16:35] another idea was to find a way to enable some completion mechanisms for shell users [16:37] vila: autocomplete seems hard to do, since you would need to load the tests to figure out how to complete them [16:37] though I guess if you had bzrlib.tests/plugins/etc autocomplete it might be a start [16:38] jam: *I* will settle for something updated one a day... [16:38] s/one/once/ [16:38] vila: ahh, but how do you handle that I have 20 different branches with different tests available? [16:38] B.T works fine for me :) [16:39] I don't have tab completion for bzr turned on yet anyway [16:41] jam: I just ignore the differences between the 20 branches, that why I said '*I*'ll settle for a good enough solution', but the truth is that, as an emacs user, I already have some completion available ;-) [16:42] and my experience is that in most of the cases I will use the option for some test that has failed and for which the ID is one copy/paste away... [16:44] jam: "Zen" User Guide patch updated and sent to the list [16:45] vila: I would tend to run "--starts-with bzrlib.tests.test_module_I_am_working_on" [16:45] jam: I'm off to sleep so please merge it if you think it's now worthy of being approved. [16:45] night all [16:45] igc: well, robert and I seem to be debating [16:45] so I'll look at it [16:45] but won't guarantee anything [16:45] I'm pretty loose about merging docs, though [16:45] something better than nothing, and all [16:47] jam: sure. What I meant was, if you think robert would no longer think it was confusing [16:47] igc: I'll try to channel my inner lifeless [16:47] vila: do you have your patches sent to the PQM ? [16:47] I don't see them showing up [16:47] and I have to wait for them to get in before I can finish working on 1.5rc1 [16:52] jam: Is bug 211661 still likely to be handled for 1.5? [16:52] Launchpad bug 211661 in bzr "bzr.dev smart client fails on log" [Critical,Confirmed] https://launchpad.net/bugs/211661 [16:55] jam: hold on a sec, I'm working on sending them [16:55] fullermd: it works for me [16:56] fullermd: You can still see it failing? [16:56] Yah. Logging my local bzr.dev over bzr+ssh://localhost/ still dies every time. [16:57] (with system-wide 1.4 or local bzr.dev, any combo client/server) [16:57] fullermd: it works with "--short" [16:57] that was my problem [16:57] --long fails [16:57] ugh [16:57] Hm. [16:57] Well, --short fails too, in a different way. [16:57] fullermd: can you confirm on your side? [16:58] ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked [16:58] fullermd: do you have a weird plugin installed? [16:58] bzrtools, gtk, heads, cvsps. [16:58] (well, and lp of course) [16:58] fullermd: try '--no-plugins' and '--no-aliases' [16:58] fullermd: ahh, you know what, my public bzr.dev repo is knits [16:58] which don't give that error [16:59] % env BZR_REMOTE_PATH="dbzr --no-plugins --no-aliases" dbzr --no-plugins --no-aliases log --short bzr+ssh://localhost/home/fullermd/src/bzr/bzr.dev/ [16:59] Password: [16:59] bzr: ERROR: bzrlib.errors.ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked [16:59] fullermd: unfortunately, I don't know if anyone would be around to review a patch for 1.5rc1 [16:59] but maybe a 1.5rc2 or something [16:59] I'll check into it for a bit [17:00] Oh, well. It's been around a month or so; a few days won't hurt more. [17:00] Just making sure it's at least on a list somewhere :) [17:00] fullermd: confirmed both ways [17:01] The ObjectNotLocked [17:01] and the ValueError [17:02] Well, as long as you're safe from being bored, my work here is done ;> [17:02] fullermd: I seem to be missing the patch in my bzr.dev [17:02] weird [17:02] fullermd: what do you see in log.py line 526 [17:03] I think there might be something wrong with the merge back into bzr.dev [17:03] because of how we handled the transaction cache stuff [17:03] graph.iter_ancestry(mainline_revs) if value is not None)) [17:03] basically, we wanted to pull most of the 1.4 branch back in, but not that patch [17:03] fullermd: yeah, that should be 'mainline_revs[1:]' [17:03] according to my patch [17:04] I have that in 515 [17:04] (on) [17:04] fullermd: you need it in *both* [17:04] 515 is --short [17:04] 526 is --long [17:04] Ah, but that sets revision_ids, which is used.... [17:04] fullermd: and then returns right away [17:04] ... ah, IC. [17:05] fullermd: so does the bzr 1.4 client work for you? [17:05] One sec, testing that sub. Server is spinning, but hasn't output anything yet. === mw|out is now known as mw [17:06] Mmph. Passing a minute of CPU time with no output yet... I guess it's working, but wow that needs some work... [17:07] fullermd: hmm.. I don't see it in 1.4 either [17:07] fullermd: you can do "bzr log --long -r ..10" [17:07] so it doesn't have to do the whole thing [17:07] 2 minutes... [17:07] Now I just gotta wait it out and see how long it takes to say anything... [17:08] fullermd: ok, this is weird [17:08] I see the patch show up in 3360.1.7 [17:09] but the final merge 3363 doesn't have it [17:10] fullermd: ahhhhhh..... different code paths [17:10] there is one at 526 [17:10] and another one at 467 [17:10] OK, up to 4.5 minutes of CPU time... the client-side python process is finally starting to eat some CPU, but still no output :| [17:10] The fix that made it in only fixed 467 [17:11] 'k, screw it. 6 minutes of CPU burned with no output is Too Damn Long. [17:11] * fullermd kills it. [17:13] --limit 10 passed a minute before I killed it... [17:15] fullermd: it is important to log the first revision [17:15] --limit 10 might not [17:16] On bzr.dev it won't :p [17:16] fullermd: which is why I recommend -r ..10 [17:16] Grabbing ..10 worked, and fairly fast. But there weren't any merges that early in the history, so... [17:16] just to log the first 10 [17:17] Now I'm prepping another bug report about the time issue... [17:17] fullermd: ok, in my patch I clean up all implementations to refuse to handle None [17:17] and I can see that we are still doing the wrong thing here [17:17] fullermd: if the object isn't locked at the right point [17:17] that could certainly effect performance [17:18] log --limit 10 locally runs in about 9 seconds. I'm over 2 minutes of CPU time on the server doing it over bzr+ssh://localhost/ now. So, there's sure something beating it down. [17:18] (not that 9 seconds is busting any records, but in comparison...) [17:21] fullermd: that is --long format, right? [17:22] Yah, I don't have any aliases affecting 'log'. [17:22] 'time bzr log --limit 10' is 1.3s here [17:22] well, that is --short [17:22] --no-aliases is 2.5s, though [17:22] You probably have a somewhat faster machine than I. [17:23] fullermd: can you do "grep -a len .bzr/repository/pack-names" [17:23] just curious [17:24] 8 [17:24] fullermd: not terrible, then [17:24] I've had it up closer to 20 [17:24] --short --limit 10 runs on 0.6. [17:24] vila: any chance you would feel comfortable reviewing by bug fix for 211661 ? [17:24] (in) [17:25] --line is essentially indistinguishable. --long runs 8.5-9. [17:28] jam: I don't think so, I still have to be more familiar with the smart server :-/ And gf is has already thrown a priority interrupt currently masked while I finish sending submissions to pqm... [17:28] s/is// [17:29] vila: it isn't really smart server code [17:29] it is log.py code [17:29] the fix is pretty trivial [17:29] but I understand about priority interrupts [17:30] vila: and your second submission won't work [17:30] you have it set as "bzr+ssh:///" [17:31] vila: Merge bzr+ssh://bazaar.launchpad.net/~vila/bzr/199440-auth-ssh-user-no-pass http://bazaar-vcs.org/bzr/bzr.dev [17:31] vila: however, I'll submit something for you [17:32] jam: rats, I usually do a single submission using the same branch :-/ [17:32] Filed bug 228740 for log speed. [17:32] Launchpad bug 228740 in bzr "log over smart server is *SLOW*" [Undecided,New] https://launchpad.net/bugs/228740 [17:32] Sad. 8 seconds vs. 7.5 minutes. [17:33] vila: the other advantage of me submitting it [17:33] is that if it fails [17:33] I can resubmit, etc [17:33] while you go sleep [17:33] or GF time, whatever [17:33] Locking sounds like a good candidate source for the problem. [17:34] ok, that'be better, I will then tweak 183705 as per your review and let you submit then, I'm a bit worried about NEWS conflicts while doing several submissions like that [17:35] vila: just send me something I can submit [17:35] I'll try to work out NEWS [17:36] fullermd: even weirder is that show_log() calls lock_read() and then hands off to _show_log [17:36] so everything should be locked [17:39] ok, weird [17:39] branch.is_locked() == True, branch.repository.is_locked() == False [17:41] jam: fix for 183705 mergeable from http://bazaar.launchpad.net/~vila/bzr/183705-auth-doc-unclear [17:41] vila: thanks [17:42] vila: I'm glad you have the bandwidth/latency to push stuff up to lp.net [17:43] That surely helps a lot... [17:44] vila: submitted [17:44] vila: as an aside, I prefer if you use "#BUGNUM" rather than just "NUM" [17:45] just because it makes it possible to grep for bug numbers [17:45] damn it, I wrote bug NUM ? Endless typos today :-/ [17:45] though the numbers are big enough now that it is pretty unlikely to have a false positive if you are looking for a specific bug [17:45] '(vila) Fix 199440 by taking allowing no password in a section' [17:45] vila: and then I, of course, just copied your message and did the same [17:46] It was corrupted by being transfered over hhtps. [17:46] grr, sure, same here :-/ [17:46] hehe, typed hhtp yesterday but caught it before it was too late ;) [17:46] vila: have a great weekend, by the way [17:48] gf re-raising interrupt, thanks jam, can you also submit --starting-with from http://bazaar.launchpad.net/~vila/bzr/faster-selftest/ ? [17:48] It may be a loom, but that's the last thread so it should be easy to find the relevant patch [17:49] thanks a lot for your work on 1.5rc1, all the reviews, being a good guy, have a nice week-end too, say hi to your son ;-) [17:50] vila: of course, that means I need to install looms here :) [18:00] vila: checking out "lp:~vila/bzr/faster-selftest" gives me a non-loom branch which is already merged into bzr.dev [18:07] jam: first priority handled, 5 minutes freed, you don't have looms installed ? [18:09] hmmm, I thought that branch was a checkout, it wasn't, pushing right now [18:13] ok, lp:~vila/bzr/faster-selftest should be good to merge now [18:14] jam: sorry for the mess :) [18:14] on to interrupt #2 now, this one will take longer :) [18:15] vila: nothing in NEWS? [18:33] jam: regarding --starting-with ? It should in TESTSING section [18:33] bzr diff -r ancestor:../../bzr.dev NEWS [18:33] is empty [18:33] gee, It should be in TESTING section [18:34] vila: you might have put it in another doc [18:34] ancestor on a loom branch (or son of a loom), I'm not sure it does what you think it does... [18:37] or may be push from a loom branch doesn't do what I thought it should be doing... [18:37] >-/ [18:41] Ok, I forgot the 'bzr record' before pushing, re-pushing a bunch of revisions [18:43] jam: the correct revno is 3345 [18:44] vila: when I branched from you, the local one is *not* loom [18:45] the remote one is not either (I think) but anyway, the current tip on that branch should now be at 3345 and ok for you to branch even without loom [18:45] vila: 3345: merge bzr.dev, fixing simple conflicts [18:45] vila: and the change is in NEWS [18:45]