[00:03] if I cancel a reconcile in the middle and start it back again, will it "resume" it? I've got a ~1gb repo, and it's been 4hs+ already === mw|brb is now known as mw [00:18] beuno: no, it won't really resume. [00:19] aaaaaw... [00:19] it's going to be painful to upgrade all my branches... [00:19] beuno: any knits that have already been rewritten won't need to be rewritten again, so it'll be fractionally quicker, but most of the time is spent calculating whether or not it needs to do that. [00:19] beuno: what version of bzr? [00:19] spiv, 1.0rc1 [00:20] Hmm, that's as good as it gets atm :( [00:20] (You should still upgrade to rc3 though.) [00:20] Peng, right, it's just the latest .deb I found for feisty [00:21] There should be an rc3 deb later today. [00:22] how come bzr puts files named actual_file_name.~1~ in my working tree? [00:22] That's from 'revert' [00:22] ahh [00:22] will try again with rc3 then [00:22] I find them useful; since you can them vimdiff it back into the real file [00:23] jml: see also "bzr help revert" ;) [00:23] beuno: yeah, rc3 won't be any quicker for reconcile I think, but we still fixed a few bugs :) [00:24] spiv: well, I had to be told it was from 'revert' before I could look up the help. [00:24] jml: I winked for a reason [00:24] jml: And you mean you don't memorise the help text of a command before running it? ;) [00:25] spiv, thanks anyway :D [00:27] There's some work from jam that should land in bzr.dev soon that might speed up reconcile a bit as a side-effect. [00:28] great, if packs are going to be default, having reconcile take 10hs on a core 2 duo is going to be a pain [00:32] I have ~100 branches at this point, plus the ones from each user to upgrade [00:32] and many are >1gb [01:36] New bug: #175764 in bzr "Improve bug tracker integration documentation" [Medium,In progress] https://launchpad.net/bugs/175764 [01:51] New bug: #175771 in bzr-eclipse ""Widget is disposed" error" [Undecided,New] https://launchpad.net/bugs/175771 [01:54] Ok, I can do "bzr log -r bzr+http://localhost/code/foo" now, even though the server maps /code to a completely different path locally. (And even with a shared repo at /code) [01:55] So bug 124089 will soon be fixed in bzr.dev. Finally. [01:55] Launchpad bug 124089 in bzr "wsgi smart server chrooting does not manage additional paths" [High,In progress] https://launchpad.net/bugs/124089 [02:12] spiv: Any thoughts on ParentsProvider.get_parent_map? [02:14] abentley: I haven't thought much about it [02:14] abentley: FWIW I think get_parent_map is better than get_parents. [02:14] abentley: Although I like how the ParentsProvider API at the moment is a single method. [02:15] It makes the contract dead simple to describe and implement. [02:15] spiv: so change it all over - still a single method ;). e.g. a base class that implements get_parents in terms of get_parent_map which is abstract. [02:15] My concern is about what happens when parents can't be found for a revision. [02:15] lifeless: right, that's where I was heading :) [02:15] That's rare enough that I think people won't consider it or design for it. [02:15] lifeless: or just do without get_parents entirely, perhaps... [02:15] abentley: that's handled in john's proposal by having no entry for that revision [02:16] lifeless: (like I say, I haven't thought much about it) [02:16] lifeless: Right. Which is a silent failure. [02:16] I think having no entry in the returned map is fine. [02:16] I don't think it's particularly surprising. [02:16] So people will be oblivious that it happened. [02:16] so there are two sides; producer and consumer [02:17] on the producer side it's obvious whne it happens, you have to catch an exception. [02:17] on the consumer side, the current api you have to zip your input to the output. [02:17] abentley: I'd be happy with key:None to represent missing keys [02:17] I'm not arguing for my current API. [02:17] I'm not sure it's a "failure", exactly. [02:18] abentley: I don't think it's *needed*, but it will make foo.iteritems() behave badly if the consumer isn't ready to handle ghosts [02:18] lifeless: using "zip" on two sequences of a different length is a silent failure, though... [02:18] spiv: the current api returns len(inputs) always [02:18] I'm just trying to design the best API for getting dicts of parents. [02:18] spiv: and in fact the current api supports [foo, foo, foo] [02:19] abentley: sure; this is my 2c. We can either aim for KeyError, or for a key that is some illegal value. [02:19] abentley: and I don't object to either; or prefer either. I do prefer a dict as a return value though, because IO constraints mean that we really can't lookup in a specific order easily and efficiently anyhow. [02:19] lifeless: right, I'm just thinking out loud about potential risks in possible APIs. [02:20] I will say that revid:None is *slightly* harder to implement down at the GraphIndex lever. [02:20] KeyError from get_parent_map or from using the returned dict? [02:20] *level* [02:20] abentley: from the returned dict [02:21] (having a key with value None is slightly harder to implement because you have to track more closely what keys were missing in the graph index logic, so you don't replace a valid entry with None when delegating to a concrete index) [02:21] anyhow, either is sufficiently nicer than a list that I'll leave it up to you to decide :)( [02:21] s/(// [02:22] * spiv -> lunch [02:55] I'm writing a simple plugin, to get a feel for Bazaar. 'bzr touch FILE [FILE ...]' will touch and 'bzr add' the files in the list. [02:55] I want to do this with TDD so I'm looking at tests in bzrlib. Should I be using bzrlib.tests.TestCaseInTempDir and then creating branches and such to test the functionality of the plugin? [02:56] TestCaseWithTransport [02:56] Ah, thanks. [02:56] or possibly ExternalBase; if you are only writing a command ExternalBase is probably what you want [02:57] look at bzrlib.tests.blackbox [02:57] Cool, thanks. [03:26] poolie: patch for better bug tracker doc send to the ML now [03:27] * igc lunch [03:28] hey guys. looks like there's a strange thinko in CommitBuilder.finish_inventory [03:28] http://rafb.net/p/VPYYzg59.html [03:29] AssertionError doesn't take 'stacklevel' as a keyword argument ;) [03:40] I have a question on smart server operation. [03:41] If the server is running in read-only mode does it still have to create a lock file or is there some way to run it with a user that is unable to write to the repository? [03:56] read only operations do not take out disk locks [03:56] for branches and or repositories [03:58] lifeless: Ah. Thanks, I think I misdiagnosed my problem. [03:58] Looks like I'm running into bug #129030 [03:58] Launchpad bug 129030 in bzr "Bzr inetd smart server requires write access on the user's home directory" [High,Confirmed] https://launchpad.net/bugs/129030 [04:17] hm, the index in the doc.b.o site seems to be broken [04:19] poolie: which url? it's working for me I think [04:20] maybe my browser is just grossly confused, this is very strange [04:22] igc, what do you see at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html [04:23] It's preaching at me about annotate... [04:23] poolie: I see a bad UG generated by an out-of-date bzr.dev [04:24] ok [04:24] i'll log in to escudero and check it out [04:24] the bzr.dev doc was last generated on the 7th [04:24] btw are you able to log in to escudero now? [04:24] I'm pretty sure I can [04:24] wow, what is it with my cron job there? :-/ [04:24] if you look in latest instead of bzr.dev, you get good docs [04:35] btw i was just asking about escudero to check the IS job was done [04:35] you don't have to login now === i386__ is now known as i386 [05:24] poolie: mbp added as an owner for bzr in pypi now [05:24] when you say the bad user guide is caused by an out of date bzr.dev [05:25] do you mean there used to be a bug that caused this but you fixed it?? [05:34] oh, i think i realized what it is: there are not enough makefile dependencies, so the docs did not always rebulid [05:35] poolie: yes, there was a bug in the Makefile and I fixed it [05:36] poolie: in bzr.dev, 3097 introduced the bug and 3098 fixed it [05:36] good for you :) [05:37] i made it always clean the directory first [05:37] arguably we should actually check out to a new directory [05:37] then it'll be even less likely to get wedged... [05:37] I checked the rc3 build last night and you correctly took across both [05:38] ok, that looks good now [05:38] thanks for checking [05:38] well I was panicking a little that the whole uG would be broken for everyone so I *had* to check [05:39] just knowing how to annotate doesn't quite do it :-) [05:41] poolie, jml: can someone review my bug tracker doc patch? I'll like to get it through soon so we don't miss it [05:41] i'll do that next [05:41] igc: ok [05:41] igc: but I don't count as a reviewer :) [05:44] jml: I'd like your input on the Bazaar-with-Launchpad tutorial as well, though I'm not so concerned about whether that makes it into 1.0 or not - no rush on it [05:46] igc: you misspell "Launchpad" in the line above the "Making corrections" heading in the user guide [05:46] (grep for "Lauchpad") [05:46] yikes :-( [05:47] fixed [05:47] igc: apart from that I very much approve of the changes. [05:47] jml: thanks [05:49] igc: for reviewing your bzr with LP tutorial, what's the easiest way for me to get it and generate it into something a bit more readable? [05:49] igc: (rather than blue monotyped text with '+' at the start of each line) [05:49] jml: hmm, one moment [05:52] jml: http://people.ubuntu.com/~ianc/doc/en/tutorials/using_bazaar_with_lp.html [05:53] thanks [05:57] igc: I'm doing reviews all of tomorrow, I'll use my spare time to review that doc. [05:57] (it looks good enough that it's worth spending a fair bit of time on) [06:07] pre-commit hooks are not implemented yet (if ever) in bzr, is that right? (i m using 0.92.0)) [06:18] hacklberry: I think there are [06:18] hacklberry: but I don't know where or how [06:18] poolie, spiv: pre-commit hooks? [06:31] hacklberry: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks [06:32] hacklberry: also, http://doc.bazaar-vcs.org/latest/en/user-reference/hooks.html [06:34] thanks, i m going to read it [06:34] hacklberry: but it may depend on what you mean by "pre-commit" hook. What we have today is something individual users can set up, but maybe you're looking for a hook that always runs before a change can be made to a particular central repository/branch? [06:37] well i know this may sound a bit braindamaged, but i m trying to update a version number on my little C project, I need "keyword expansion ($Revision$)" or to register a hook that would run on every ci (something like: bzr version-info | sed -n '/^revno: $.*$/s//\1/p') [06:43] You're not the first person to want keyword expansion :) [06:44] We'd like to support it directly, but it's pretty low on the todo list at the moment. [06:53] hacklberry: (http://bazaar-vcs.org/KeywordExpansion is a brief wiki page with a few of our thoughts on the topic and a link to some mailing list discussion) [06:55] spiv: thanks, i read that [07:49] night all === doko_ is now known as doko [09:39] morning :) [11:11] jelmer: how do I branch svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/amarok/ ? [11:14] it just says "not a valid Subversion branch path" [11:15] but I don't want the whole KDE repository [11:25] Hi everyone [11:26] I'm getting bug 153749 on my system. bzr status gives MemoryError. Anyone know how I can create a new clean branch including my uncommitted changes? [11:26] Launchpad bug 153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New] https://launchpad.net/bugs/153749 [11:34] must be my lucky day [11:35] mtaylor: Hi, I think I'm having a similar problem to what you discussed on this channel before. Its about the MemoryErrors... [11:36] alwyn: oh good [11:36] alwyn: I think the usual trick is to make a new branch, then copy the dirstate file over. You'll have to re-add any added files, but... [11:36] alwyn: that's what I had to do [11:36] alwyn: actually - I was able to branch from my b0rked branch [11:36] I think [11:36] ok, so make new branch, copy dirstate file to new branch and manually copy all changed files... [11:37] Should be able to. branch doesn't need to fiddle with the WT, so a b0rked up dirstate file wouldn't affect it. [11:37] I could branch, but it doesn't have the uncommited data of course [11:37] Nono, other way around. [11:37] Copy the new branch's dirstate file into your main branch. [11:37] oh.... [11:37] let me try that [11:37] Then all your changes are still in place; it's just got a clean slate to compare them against, instead of a cranked up one. [11:38] and then just had to reapply outstanding patches [11:38] dumb question, where do I get the dirstate file? [11:38] .bzr/branch/dirstate, I thin. [11:38] k [11:39] is it not .bzr/checkout/dirstate ? [11:39] Somewhere in .bzr/branch/ at any rate. [11:39] Oh. Dur. That's what I mean. [11:39] * fullermd pours another cup of coffee. [11:39] looks like .bzr/checkokut/dirstate [11:39] sorry, could just have done a find [11:40] ok, thanks a million! Do you lose any information by doing this? history etc? [11:41] The only think you should lose would be info about files you might have 'add'd since the last commit. [11:42] ok, thats fine [11:42] btw. I also used the eclipse bzr plugin, maybe it has something to do with it... [11:49] alwyn: I have had the problem without the eclipse bzr plugin [11:52] hello there [11:52] https://edge.launchpad.net/bzr-doc-russian [11:53] is this a reasonable project? [11:55] New bug: #175839 in bzr "`python setup.py bdist_rpm` fails" [Undecided,New] https://launchpad.net/bugs/175839 [12:05] Any idea when the whole translation process ( https://blueprints.launchpad.net/bzr/+spec/i18n ) will be started? [12:45] kiko: it is a genuine desire from Alexander Belchenko (bialix) [12:49] jam, and is having the project the right way to address it? I'm fine with keeping it, just wanted to validte. [12:49] what alternative would you propose? [12:50] I think it is mostly focused on translating the tutorials, etc. [12:50] I suppose we could move some of that into core bzr, but certainly the rest of us aren't qualified [12:50] to evaluate Russian documentation [12:52] no, I also think it's fine. it's just that if it's just a translation project it's better addressed somehow else, but this is the case where it's actual original content [12:53] sure, if it was just doing i18n for bzr core, then it would be done through Translations/Rosetta === kiko is now known as kiko-fud [13:16] Riddell: try removing ~/.bazaar/subversion.conf === cprov-away is now known as cprov [13:20] jelmer: that seems to help, thanks [13:21] although it might take a while to branch all 747585 revisions [13:30] Riddell: yep, my svn-cache sqlite database for the KDE SVN is ~2GB :) [13:30] (I needed it for a project with about 400 revisions) [13:36] luks: was that made with bzr-svn ? [13:42] Riddell: it won't branch them all, will just fetch revision metadata [13:42] Riddell: but the memory leak in the python subversion bindings may cause it to use a lot of memory [13:43] bug 54253 [13:43] Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] https://launchpad.net/bugs/54253 [13:43] jelmer: do the subversion folks know about the memory leak? === kiko-fud is now known as kiko === kiko is now known as kiko-afk === cprov is now known as cprov-lunch [14:55] New bug: #175886 in bzr "dumb http servers make packs perform very badly" [High,Confirmed] https://launchpad.net/bugs/175886 === cprov-lunch is now known as cprov [15:51] Hello all, does somebody try to make the mantis bug tracker integration with bzr ? === mw is now known as mw|mtg === mw|mtg is now known as mw [17:41] +Depends: ${python:Depends}, bzr (>= 0.92~rc1), bzr (<< 0.93~), patch [17:41] ^-- from http://bazaar-vcs.org/releases/debs/edgy/bzrtools_1.0.0-0bazaar1.diff.gz [17:41] makes the resulting binaries a little less than useful.. [17:42] I thought lifeless used sid packages as a start. [17:43] elmo: anyway you could temporarily install sid's, if you're anxious ;) [19:20] anyone using tortoisebzr? [19:21] * X0d_of_N0d hates windows and how much it sucks....... [19:23] nm... I figured it out [20:23] does the new pack format compress the repo? the branches I've converted up to know don't get smaller [20:28] beuno: you get far less files for now, more compression will come later [20:31] vila, sounds about what's happening then, thanks :D [20:47] beuno: be sure to remove the .bzr.backup though :) [20:47] beuno: or be doing du on .bzr only :) [20:48] lifeless, yeap yeap, removing .bzr.backup every time [20:48] just had the idea in my head packs compressed data [20:48] (and the pack commands actually says it does) [20:48] s/commands/command [20:48] so I just wanted to make sure I wasn't missing something [20:49] now, I just have to get a benchmark in place to compare kints <> packs performance, and find a way to reconcile those 1gb+ repos without them taking ~10hs [20:50] 100+ branches of all kinds of shapes and sizes are waiting to be upgraded and compared :D [21:00] beuno: future editions will approximately 1/2 the current storage size [21:00] beuno: and packs do compress data; so do knits :) [21:01] lifeless, sounds promising. And, on the "already compressing bit", you know, you spoil us, so we tend to give some things for granted :p [21:01] any ideas on the reconcile bit? [21:02] 10hs for 1gb branch doesn't seem like a fair tradeoff [21:02] beuno: where you reconciling it in knit or pack form? [21:02] beuno: is it 1gb because of iso's, or just many many files and many many commits ? [21:02] lifeless, knit, so I can upgrade to pack [21:03] lifeless, big files mainly (~50mb) [21:03] I don't think it has more than 100 commits [21:03] beuno: try this (in a copy) - upgrade, reconcile. [21:03] it may be a tad faster [21:03] also make sure you have the C extensions. [21:04] I installed from .deb, so I assume that should be taken care of, right? [21:04] yes [21:04] (trying right now, didn't know I could reconcile after upgrade, thought it was a pre-requisite) [21:06] beuno: it should be yes. [21:07] beuno: it used to be a pre-req, until we got a native reconcile for packs (reconcile is right down low-level, it is hard to reuse across formats) [21:07] so, if it's not a prerequisite, what happens if you don't reconcile after upgrading? [21:08] lifeless: also, NEWS.Debian recommends `bzr reconcile && bzr upgrade`. should I change that in anyway for 1.0, or maybe retroactively edit for 1.1? [21:08] when you push it may error === cprov is now known as cprov-away [21:08] ok [21:08] or when you branch [21:08] thats if the 'check for missing parents' patch has gone in,I haven't been following recently. [21:08] oh, right :) [21:09] if that patch hasn't landed, then it will silently discard your data [21:10] * beuno is upgrading [21:14] 'evening dato, lifeless [21:16] hi jelmer [21:16] hey jelmer [21:16] upgrades, reconciling [21:16] s/upgrades/upgraded [21:16] (seems a trillion times faster) [21:17] yeap, took < 1 minute [21:17] vs ~10 hours estimated [21:17] you rock lifeless :D [21:18] that should be documented somewhere [21:18] * beuno runs out for a while [21:19] lifeless: I don't seem able to find the patch in the list [21:19] if the speedup is as great as beuno says, we should really change NEWS.Debian === cfbolz_ is now known as cfbolz [21:41] dato: pqm@pqm.ubuntu.com-20071201001053-zi6k6s2817c1p97s [21:43] morning all [21:44] lifeless: thanks a lot. since it is in 1.0, I'll recommend upgrade & reconcile instead of reconcile & upgrade [23:11] I've checked out some code from a remote location, changed a few things, and commited, but how do I send my changes back to said original location? [23:11] toed: 'bzr push' [23:12] toed: or 'bzr push ' [23:12] it says 'ERROR: No push location known or specified.', but it does have the url when I do bzr info (under the heading related branches, parent branch) [23:13] toed: if you actually used "bzr checkout", then the changes should've been automatically pushed back when you committed. Is that what you did? [23:13] I'm not entirely certain if it was, it's been a while [23:15] toed: copy & paste the output of 'bzr info' [23:15] http://rafb.net/p/fkmlyu84.html [23:19] When one user does a remote sftp commit of the project, other users cannot remotely checkout the project (or update) via sftp - it gives an error 13 permission denied. I can solve the problem by doing a chgrp -hR bzr ProjectDir (bzr being a group that all are members of). The error is usually in a file in the knits directory being owned by user with group user (default group for Ubuntu is the user's group). Is this normal? [23:20] toed: try "bzr push " [23:24] seb_kuzminsky: alright, thnaks [23:33] toed: good! also, try "bzr push --remember " and it will remember, then you can just say "bzr push" in the future [23:33] perfect [23:48] bombcar: there is a bug open on this about openssh's sftpo server msking out setgid [23:49] I found that one (50568) and I'm trying the workarounds.