[00:00] beuno: i should say that it's not just performance we'd be looking for with genshi, but also memory usage [00:00] beuno: if you change the limit for 'fancy' diffs up to say 10000 and view a big diff and watch loggerhead's memory usage in top you'll get a fright :) [00:01] right, I tend to see memory as a part of performance, but, of course, you're not in my head. [00:01] cool, I'll create a branch with a big diff and use that [00:01] that helps :) [00:02] I'd also like to do something about setup.py sooner than later, so we don't break people's computers to install loggerhead [00:02] beuno: well, you were ambiguous enough for me to want to check [00:02] mwhudson, the more explicit, the better, so thanks for clearing that up [00:03] beuno: when we first identified the problem with big diffs the irc transcript went like this: [00:03] right, i have the branch set up, let the machine crushing begin! [00:03] *** mwh has quit (remote closed the connection) [00:03] lol [00:03] *** mwh has joined the channel [00:03] * mwh didn't expect that to work so well [00:04] the OOM killer got involved and killed x [00:04] lol [00:04] * beuno starts setting up a test enviroment in a different PC [00:04] beuno: another bit of advice: [00:04] don't use firefox to test the url, use curl or something instead :) [00:06] ah, makes a lot of sense [00:06] If I could dare one more question: Is cvsps-import still the most preferred way of importing CVS to Bazaar (one-way, one-time should be all I need, but for a lot of projects, again with mixed case and Windows line endings)? [00:06] two memory hoggers at once won't help [00:06] dlee: yes [00:07] I even have one project that ues vendor branches :P (Tailor doesn't handle those too well) [00:07] dlee: another sane option aiui is to use cvs2svn's 'fastexport' stream and bzr-fastimport [00:07] Ah thanks! I looked at that but missed how to get it all put together. [00:08] looked at fastexport I mean [00:08] ok, well, mwhudson, jam, many thanks for all the input/patience, I'll get back to coding for a while [00:08] mwhudson, I'll move _strip_NULL_ghosts into loggerhead so we're on the safe side for now [00:09] beuno: thanks [00:12] mwhudson, just to recap, for the new theme for files, it's generally OK as-is, or is there something you want changed before we move on? [00:12] beuno: it's ok with me, we should probably give some other people a chance to respond :) [00:13] mwhudson, heh, yeah, probably. *Some* work has been done on the diff view already, so I hope to get that out soon too. [00:14] great [00:21] awilkins, related to the eclipse cache, the XMLRPC should solve the need for one. I know Verterok had played around with it, but it's a heap of work, so I'm not sure when that will land. [00:25] spiv: ping [00:29] now, I think I know what it is doing, but pushing to bzr+ssh it is sitting at Copying signature texts 4/5 for ages, could this be doing a repack (locally) [00:30] thumper: check the ~/.bzr.log [00:30] thumper: as it happens, I have a branch I made yesterday that does the autopack server-side. [00:30] spiv: nothing in there [00:31] spiv: since the last success anyway [00:31] thumper: use [00:31] "bzr -Dhpss ..." [00:31] in future, and then the .bzr.log will tell you much more. [00:31] spiv: should I kill my push or not? [00:31] I'm fairly sure that an autopack does get logged, though. [00:31] hmm.. [00:31] So it's probably "normal" operation. [00:32] I suspect it's too late to kill the push and redo the identical push. [00:32] You could try it, though. [00:34] ??? [00:34] it said created new branch [00:34] when the branch was already ther [00:34] e [00:36] The branch probably wasn't already there. [00:36] If you had a -Dhpss log, we could confirm this :) [00:50] beuno: Why would the XMLRPC solve the need to cache? [00:51] beuno: Does it implement a server which itself caches? [00:55] Bah, anyway, it's late, beddy-byes time, gnight [00:55] awilkins, for starters, you stop paying the cost of starting bzr everytime. And, eventually, if needed, you will be able to cache, yes [00:55] beuno: I've already mitigated the cost of starting bzr somewhat by integrating the "service" plugin into bzr-eclipse [00:56] beuno: But on my target working tree of 3700 files the performance still leaves a lot to be desired. [00:56] awilkins, right, well, I don't know any specifics, but I suppose you can cache with the XMLRPC, and avoid re-writing it within eclipse [00:57] The problem is mostly uncached log hits for decorators [00:57] but Verterok is the man to talk to [00:57] Yes, I correspond with him. [00:59] awilkins, anyway, just though I'd comment. I'll let you sleep already, g'night :) [00:59] The performance of "log" on a single file for bzr is not what it is for SVN/CVS [00:59] Gnight chaps, until tomorrows first coffee..... [01:17] * igc medical appointment - bbl [01:18] How do I cause bzr to forget an improperly set submit branch as listed in bzr info? [01:18] I don't think there is a UI to 'forget'. You can overwrite with a --remember. [01:19] Only way to forget is just whack it out of the branch.conf manually. [01:22] Thanks. [01:23] code scanner just came back from the dead! [01:24] indeed [01:24] it's lying in some cases though :/ [01:24] ? [01:25] it says a branch was modified "50 minutes ago", when it clearly hasn't [01:25] it's still catching up on a pretty huge backlog [01:25] oh right, it probably sets the modified time to NOW when the scanner runs [01:25] we don't usually expect that to be several days after the change... [01:25] ah, that doesn't seem like the right thing to do at all :) === samurai_ is now known as samiam [01:51] lifeless: ping === mw is now known as mw|out [02:17] mwhudson, my firsts tests with genshi don't show a big improvement over kid :( [02:17] beuno: bah! [02:18] Big improvement in what? Performance? [02:18] mwhudson, in fact, kid takes less time [02:20] beuno: and RAM? [02:21] mwhudson, looking for a good way to test it, but looking at top, it seems about the same or more even [02:21] oh well [02:22] it was a nice idea [02:22] beuno: can you push your code? [02:22] I'm testing this with annotate, as it was the simplest template to test it with [02:23] mwhudson, sure, let me clean up, and I'll push it to LP [02:23] I just converted the annotate template, so it's all mixed up between kid and genshi [02:23] jam: still here? [02:23] heh [02:23] that's fine [02:23] i'm not sure item_keys_introduced_by really helps loggerhead [02:24] we want to know which fileids changes between two mainline revisions [02:26] mwhudson, do you have a good way to test memory usage? [02:26] (I can google around, but might be good to be using the same tools) [02:27] you can find all the fileids changed by all revisions introduced between two given revisions, but that's not really correct [02:27] beuno: i don't have any sophisticated tests, no :/ [02:27] beuno: i do know that builtins.py is the largest file in bzr.dev :) [02:31] mwhudson, I went for NEWS, which takes 13-16 seconds to annotate [02:31] ok [02:31] I think http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of-python-applications might be good, or one other page I can't think of. [02:31] anway, I'll take a few more minutes to convert all templates to Genshi, and push [02:31] so you can go crazy on it :) [02:32] Peng, thanks, I'll take a look at that [02:34] igc, ping? [02:47] spiv: will leave soon [02:48] poolie: ok [02:49] mmm, graph.py is getting pretty deep [02:56] gar, revision numbers are pain [02:58] mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/loggerhead.genshi [02:58] I'm off for dinner [02:59] only annotate was converted [02:59] beuno: enkpy your dinner [02:59] jo [02:59] I ran into a few quirks with the kid<>genshi conversion on the other templates, so I'll just leave it alone unless you find it's actually useful [03:00] I'll be back in a couple of hours, and thanks :) [03:06] hm [03:06] my turbogears isn't finding my genshi [03:07] oh look https://bugs.edge.launchpad.net/ubuntu/+source/genshi/+bug/226285 [03:07] Launchpad bug 226285 in genshi "Due to packaging changes, Genshi no longer works with TurboGears" [Unknown,Fix committed] [03:09] mwhudson: I'm back for a bit [03:09] what's up? [03:09] ah, fileids... [03:09] yeah, I can see the problem [03:09] jam: it's not really any faster anyway, on launchpad [03:09] versus doing a diff? [03:09] yeah [03:09] poolie: pong [03:10] hmm... a bit surprising, but you did the test [03:10] jam: let me pastebin the code [03:11] mostly because the item_keys_introduced code can work on the deltas directly [03:11] jam: http://pastebin.ubuntu.com/15215/ [03:11] without going up to full texts [03:12] well, r2r = b.get_revision_id_to_revno_map() is going to dominate your time [03:12] vs http://pastebin.ubuntu.com/15216/ [03:12] jam: oops [03:12] i tested without that line [03:12] (and indeed it's pretty slow, get_revision_id_to_revno_map takes ~5 seconds) [03:13] but the fileids_from... takes ~1 second [03:13] what about the find_unique_ancestors line? [03:13] eh, not long, a few tenths [03:14] yay [03:14] that's been my work for the last while [03:14] not even that [03:14] 0.003 [03:14] which is pretty neat :) [03:15] though if it is a simple graph, that isn't saying a huge amount [03:15] but I'm glad it is fast [03:15] it is a way forward [03:16] running this between the last 100 mainline revs of launchpad has one revision where it takes 3.5 seconds [03:17] and a couple where it's 0.7 or so [03:17] yeah, those are the ones I'd like to work on [03:17] shortcuts cause some problems [03:17] because you have to search that far on the other side [03:17] which gets you into revs with lots of ancestors, etc [03:17] ah dammit, what's the package name for R again? [03:18] r-base-core [03:18] :) [03:18] one of the problems with extra simple names [03:19] how do you google for R ? [03:19] indeed [03:19] With great difficulty :) [03:19] command-not-found to the rescue here [03:21] the other problem with R is that i always forget how to use it [03:23] Is R used in bzr? [03:24] no [03:26] jam: heh, log(time-to-run g.find_unique_ancestors(last, [last_but_one])) is ~normally distributed when run over the 1000 most recent mainline revisions of launchpad [03:27] interesting, what is the mean and stddev? [03:28] KnitCorrupt raises a stack trace [03:28] It probably shouldn't? [03:31] jam: the mean is about -4 [03:32] negative 4? [03:32] spiv: so it's like this. [03:33] spiv: I pushed up a branch into a shared repo, someone tried to branch it standalone and then they got a massive KnitCorrupt traceback [03:33] jam: the mean of the non-log data is 0.03 [03:33] spiv: I'm following the instructions on the traceback now (bzr check, bzr reconcile) [03:33] though this is for 6000 revs now, [03:34] spiv: but it seems a bit buggy that Bazaar should show a traceback here. [03:34] jml: Hmm. So you think it should just give the KnitCorrupt error without a traceback? [03:34] spiv: yes. [03:34] 0.05 for the first 1000 [03:35] Well, that's easy to fix (it's just a flag on the KnitCorrupt class). [03:35] 3.5 for the worst case though [03:35] jml: I'll talk it over with poolie when he gets here. [03:35] jml: out of interest, what's the full traceback in this case? [03:35] spiv: cool. thanks. [03:36] I'm a bit hesistant about suppressing the traceback there, because KnitCorrupt almost always so far is a bzr bug. [03:37] And showing the traceback makes it more likely that we get the traceback in the bug report. [03:38] jam: the 3.5 second case is for a moderately but not ridiculously complicated merge [03:38] But possibly we should just be making sure we have enough context in the text of the KnitCorrupt message rather than relying on the traceback. [03:38] jam: want more details? [03:38] mwhudson: there are ones in bzr.dev, too [03:38] generally the problem is that it is long enough to cause the *other* side of the search to wander a lot [03:40] jam: heh, the worst case in bzr.dev seems to be "pack repositories!" [03:45] jam: 'number of revisions introduced' seems only very loosly correlated with running time [04:34] ok. [04:34] so, now when I run "reconcile" on the repo that was causing the KnitCorrupt error, I also get a KnitCorrupt error [04:34] Can I do anything about this? [04:34] (it's a little worrying) [04:37] Bwahaha. [04:37] I just finally counted how many requests it took bzr.dev to branch that one branch. 765! [04:55] Peng: over http? [04:56] is this a pack branch? if so that's a bit bad [04:56] igc, ping? [04:56] poolie: No, knits. [04:56] hi poolie [04:56] Peng: you should really upgrade it... [04:56] poolie: I was checking how much it had improved since 1.3. About -600%, I think? [04:57] knits have? [04:57] Pulling with no changes has. [04:57] 1.3 accesses the repo, but bzr.dev doesn't, I think. [04:57] ok [04:58] that's kind of interesting, but we really want people to move from that format [04:58] Yeah. [04:58] in fact in this release we should add a warning about it [04:58] Also, bzr+http is quite good. [04:58] igc, could you call me at andrew's house when convenient? [04:58] sure [04:59] how's now poolie? [04:59] now would be great [05:01] I haven't upgraded because upstream still hasn't. [05:30] re bug 234748, so is bzr.dev eating old revisions? [05:30] Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Confirmed] https://launchpad.net/bugs/234748 [05:32] given a file is it possible to print out the weave? [05:37] Peng: yes, bzr:// and friends should make pulling knits approximately as good as pulling packs. [05:38] Peng: bzr.dev isn't damaging old revisions as far as I know. i.e. I don't think this is a dataloss issue. [05:39] Peng: My guess is it's just being a little more pedantic with the metadata, and then not gracefully coping when it sees this inconsistency. [05:39] * igc pick up kids [05:39] uniscript: can you explain more what you mean? [05:40] I'm trying to debug a merge problem so want to look at the weaves [05:40] so given a file test.txt is there a command that prints the weave for test.txt in my branch? [05:41] uniscript: i think 'bzr weave-plan-merge' will do it [05:41] uniscript: note that we don't actually store texts in weaves anymore for performance... [05:41] AIUI the weave itself is not really relevant, just the shape of the graph. [05:42] the bzr weave-* take a weave file [05:42] well, that will show you the line-by-line annotations of the merge [05:42] oh i see [05:42] are you giving any options to the merge command to choose an algorithm? [05:42] OK. well conceptually to dumb users like me you are :) [05:42] --weave [05:43] uniscript: --lca is almost always better or at least as good as --weave, btw [05:43] for criss-cross merging? [05:43] (possibly s/almost// in current versions) [05:43] Yep. [05:43] OK thanks, I'll try that [05:45] uniscript: it would be nice to expose some debugging info to help in cases like this [05:46] bye... [05:50] spiv: Ok. Not being a data loss issue is good. [06:27] Peng: yeah definitely not, a bug in check i think [06:28] poolie: Good. :) [06:32] Wasn't check's performance improved a while ago? [06:33] mwhudson, did you get a chance to verify Genshi's performance? I'm not sure if I should try and see if we can tweak that, or go down a different path... [06:34] beuno: no, sorry :/ [06:34] mwhudson, no worries. I'm going to look into it a bit further and make sure we're not improving in any way [06:35] beuno: cool [06:35] maybe the bottleneck is in turbogears? [06:35] i'm about to stop work for today, so talk to you tomorrow! [06:36] right, almost 3am, I'm getting used to that :) [06:37] thanks, and cya tomorrow [06:37] night === doko_ is now known as doko [07:42] 234378 should be fixed now... [07:46] jml, re that bug, you said you could reproduce it just branching out of your repository? [07:46] i can't, even with the unfixed version [07:46] poolie: what URL are you using? [07:47] i was branching my bzr trunk to /tmp/ [07:48] poolie: oh. maybe try branching from my repo? [07:53] jml, where is that? [07:54] poolie: devpad. [08:01] jml: which branch? Were you branching over bzr+ssh? [08:01] jml: I can't reproduce by branching locally on devpad from your repo to /tmp [08:01] jml: I tried both your bzr.dev branch and your most recently touched branch. [08:01] spiv: bzr+ssh. [08:01] spiv: stacking-policy [08:02] "most recently touched" :) [08:04] spiv: oh. well. [08:04] spiv: which version of bzr were you using? [08:04] spiv: and was it into a standalone branch? [08:05] jml: I get a different KnitCorrupt over bzr+ssh... [08:05] Which tells you to run check and/or reconcile. [08:05] spiv: right. [08:05] spiv: then if you run check and/or reconcile... [08:05] jml: ok, I didn't realise it was two different KnitCorrupts. [08:05] spiv: mea culpa [08:09] it is a kind of vague error that sounds like it's specific [08:09] um [08:09] i should stop complaining and just send a patch to change it [08:35] * igc dinner [08:37] would someone please care to update bzr-svn in the PPA for hardy? [09:06] is there a document anywhere explaining how to use bazaar with git? [09:07] dunno, but bzr-fastimport is a good conversion tool [09:08] * gour recommends tailort [09:08] *tailor [09:09] i must be mistaken because i heard someone say that there was some capability for bazaar to speak directly to git repos [09:09] eg. use them natively [09:10] gambler: maybe https://launchpad.net/bzr-git [09:10] it looks somewhat dead? [09:24] bzr-git is still in its formative stages, I think, so isn't really a priority for whoever was working on it (jam, I think). [09:25] I think we'll all eventually end up with a common VCS backend API, and a small selection of cliens. [09:25] And different implementations of the backend depending on requiremenbts [09:26] And the ability to type may atrpohy as we use our mind control interfaces [09:26] * awilkins goes to fetch coffee to improve his synapse lag [09:27] instead of a wetwire, how about an electronic vagina that I can control with my penis? [09:28] * vila wonders how this relate to git, but English is not his native language... [09:29] vila: #bzr [09:31] no pun intended [09:32] gambler: the wetwire bits ? [09:32] gambler: sry, then :) [09:33] lol gold [09:55] one question...i defined alias: checkout=checkout --lightweight and bzr help checkout says: 'bzr checkout' is an alias for 'bzr checkout --lightweight'. otoh, 'co' is alias for 'checkout', so i'd expect that invoking: bzr co would does: bzr checkout --lightweight, but it doesn't :-/ [09:55] is it a bug or a feature? [10:01] gour: not sure, I have seen that behaviour before, but I used it as a feature. [10:06] are there any plans to 'fix' --lca to mark delete + change as a conflict? [10:06] james_w: hmm, i'd expect that user's alias is last in effect, i.e. 'co' should expand to 'checkout' and then *my* checkout should expand to defined alias [10:07] * gour will submit a bug report [10:18] using mail-client = emacsclient does not invoke Gnus. anyone using Gnus with 'bzr send' ? [10:19] uniscript: is there a bug report filed for that? I'm not familiar with the problem you mention. [10:19] * gour would like to use gpg-sign when sending bundles around [10:20] see the developer notes on the lca merge algorithm where it states that currently lca silently does delete+change->change with no conflict report as does --weave [10:20] and that this needs to be fixed to conform to --merge3 [10:20] and I would agree with that :) [10:21] ah, I hadn't seen that. [10:34] so I guess there are no plans then? [10:39] hmm, problems with 'bzr send' and emacs...invoking bzr send gives http://rafb.net/p/ZXRhFV94.html [10:39] any hint? [10:39] uniscript: no idea I'm afraid [10:40] OK I'll raise a bug [10:40] gour: that looks like an emacs problem, is it? [10:41] or an emacs error rather, not necessarily its fault [10:42] james_w: well, emacs is invoked and i can fill out the To/From...but i'd like Gnus to be invoked and wonder about the error(s) [10:42] I'm not familiar with emacs, sorry. [10:43] ok, i'm asking in #emacs [14:03] given a .git repo with several branches, is there a trivial bzr import process for that? [14:03] of course, in my fantasy land, I'd wind up with one bzr directory in which I could switch between all the diff views. [14:04] and would be able to bzr push changes back to the git repo [14:04] and fetch and/or merge from said git repo [14:07] not yet [14:07] there is one way git -> bzr import [14:07] i don't know the state of bzr-git... but that will allow what you speak of one day.. === jelmer is now known as jelmer__ === jelmer__ is now known as jelmer [15:08] heh, solved my 'bzr send' & Gnus problem...the solution was to set mail-user-agent in emacs. fortunately, i also got nice reply on the ml. nice to have such info in the docs === weigon_ is now known as weigon [15:22] someone was today explaining me how he likes that with git he can create several branches in one working dir and switch between them by checkout-ing them. i replied that bzr can do almost the same buy using e.g. treeless shared repo and doing lightweight checkout & switch in some working repo [15:23] his remark was that he does not like one directory per branch, but i do not see logic what would be advantage of sticking many branches in one folder except more hassle when one wants to access them remotely. anyone can shed some light if there is some? [15:25] gour: the 1 folder per branch works better with IDE and various external tools [15:26] on the other hand the git model work better when you want to checkout all the branches of a repository at the same time [15:26] asabil: well, having 1 tree works better when building is expensive, say, C. [15:26] I tend to prefer the bzr model myself [15:27] but branches don't suffer from the same problem [15:28] hmm, what do you mean ? [15:28] which problem ? [15:29] asabil: is it easy with git to fetch just one branch? [15:29] asabil: if you have a project where a full build takes in the tens of minutes, you really want to reuse your intermediate objects [15:29] yeah, but that's a build system issue [15:30] not a revision control issue [15:30] asabil: also, things like Eclipes don't deal too well with suddenly having to look somewhere else for the code. [15:30] asabil: it is an important use case for `bzr switch` [15:30] hi [15:30] asabil: it's git's native way of working [15:31] LarstiQ: people can still use out of tree build [15:31] * gour likes bzr switch mechanism [15:31] I never used bzr switch myself [15:32] but I do see your point [15:32] asabil: it's handy being in one working dir and just switching between the branches you're working on [15:32] Having the repo be the functional unit makes it much easier to do multi-branch syncs. [15:33] Can only fake up parts of that capability with bzr. [15:33] fullermd: with shared repos? [15:33] gour: cd ../foo-branch works [15:33] Shared repos don't change anything. === jamesh_ is now known as jamesh [15:34] asabil: i mean using --ligthweight checkouts and --no-trees repo, then you can stay in one folder [15:35] gour: personally I prefer seeing 1 branch == 1 folder [15:35] i do not see big advantage of git's model, especially considering its complexity over bzr [15:35] I used to like the git model (when using monotone), it is just a matter of habit [15:35] asabil: me too, but in shared repo without working-trees [15:36] asabil: how is monotone these days? i looked at it in the past, but didn't like database dep [15:36] I sure wouldn't want to be stuck with one tree for all my branches; it's almost necessary to see multiple branches side by side. [15:36] gour: didn't use it for 2 years now [15:36] But I wouldn't dream of pretending it doesn't come with drawbacks. [15:36] :-) [15:36] fullermd: I agree [15:36] I use it very occasionally. It's always fighting an impedance mismatch. [15:37] Ex: How, using bzr, do I get a local copy of all your branches, keep them up to date, and automatically get new branches when you create them? [15:37] Oh, that's right; I DON'T! [15:37] the only drawback about 1 branch/folder that I see, is the lack of ability to pull/merge multiple branches [15:37] (multi-pull sort of solves it, but ...) [15:39] Part of that is "nobody's written it", but writing it is some nontrivial amount of work with dir-per-branch architecture. With the repo being the primary functional unit, it comes for free. [15:41] asabil: multi-pull is not quite interesting here [15:42] jelmer: So, this thing where the revision-id changes when you change branching-schemes.. is it not possible to use a different ID generator that is consistent regardless of branching scheme? [15:42] multi-pull saves doing a `for i in *; do ....` construct. I use it mostly for ~/.bazaar/plugins/. It's handy. [15:42] (I realise this would break all existing code, blech) [15:42] awilkins: this is bug 130372 [15:43] Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 [15:43] Groovy ; what would you use instead ; SHA of the changeset? Something like that? [15:47] Incidentally, that patch I sent you was applied against the current tip of the 0.4 branch, I'm not so sure it's fixed (maybe it's another instance of the same thing?) [15:50] Unless you've just not pushed for a week :-) [15:53] Good morning. I have a question that I wasn't able to clearly find an answer for. I'm just getting started using Bazaar (all VCS for that matter) and I'm confused about how to merge two branches together on different machines. [15:54] * awilkins notices a new push [15:54] awilkins: what bzr-svn branch are you using? [15:54] nnutter: start in the branch you are merging TO, and do a "bzr merge " [15:54] jelmer: 0,4 [15:55] awilkins, we won't be making the branching scheme part of the revid anymore [15:55] I've just noticed you pushed this morning sometime [15:55] I didn't do any bzr-svn stuff this morning [15:55] jelmer: There was a push 7 hours ago according to LP [15:55] * awilkins refreshes cache [15:56]