[00:09] jml, hm, that doesn't seem to exist [00:09] hush, I'm being excellent. [00:09] http://paste.ubuntu.com/353202/ === bob2_ is now known as bob2 === bob2 is now known as Guest58725 [00:10] poolie, :( [00:11] poolie, I can't find it on Launchpad. Maybe I made it all up. [00:11] I distinctly remember blogging about it. [00:11] i remember you telling me [00:11] Array['hosted', 'mirrored', NULL, 'remote'])[Branch.branch_type] ? Surely proper SQL style would involve a table join ;) === Guest58725 is now known as bob2 [00:17] spiv thanks for flagging the issue with 2.0 in https://code.edge.launchpad.net/~jameinel/bzr/2.0.4-unregister-mem-trans/+merge/16980 [00:17] but i think you should actually have bounced it [00:19] poolie: hmm, ok [00:20] to me the benefit is nonzero but small [00:20] do you agree? [00:20] poolie: I think either way will be fine, really. In absolute terms the risks and rewards for 2.0 are both very low. [00:21] the worst that's likely to happen is test suite breakage i suppose [00:21] I don't feel strongly, so I went with trusting jam's judgement. [00:21] it's possible there will be some gc-related effect [00:21] well, that is a good default [00:21] :) [00:21] If you feel more strongly than me, please add a review ;) [00:21] i did [00:21] i'm just wondering if we should either discuss or clarify the 2.0 guidelines [00:22] Yeah. [00:22] * poolie looks [00:22] It's the sort of thing I'd be more relaxed about at the start of 2.0's life, I think. [00:23] i think for the stable branch [00:23] having low risk and low reward is not enough [00:23] it needs to have a high reward [00:23] because it's not just the risk, but also that a larger diff is harder to push through an SRU [00:24] I think as time goes on the rewards for doing things to a stable branch tends to go down (less and less users, and the users that it has are happy or they would have jumped to the next branch), but the risks don't really drop in the same way. [00:24] true [00:24] But also it does help us to keep the delta between stable and trunk minimal. [00:24] if john really wanted to do it in 2.0 i wouldn't necessarily veto it [00:24] but i would want at least a specific rationale for putting it in [00:24] that's good too [00:25] hm [00:25] though [00:25] the thing where the delta is most going to matter, i think, is api changes that will limit your ability to merge patches across [00:25] but of course they're also harder to put into the stable branch [00:25] i suppose one could do additive-only api changes [00:26] and then do the deprecation/removal of the old api, if any, in trunk [00:26] Yeah. Although reducing superficial conflicts from e.g. changing "MemoryTransport" to "memory.MemoryTransport" is nice too... that's not a big deal if there's just one, but multiple overlapping superficial conflicts can be a significant hassle to fix. [00:27] true [00:39] spiv, how about something like http://pastebin.ubuntu.com/353217/ [00:42] poolie: +1 [00:54] back [00:58] Hi. Is there any particular (dis)advantage to bzr-managing a local dev box + a remote svr using bzr's sftp upload/checkout capabilities, versus mounting the remote server locally via sshfs (fuse over ssh)? [01:00] bendj: better to use bzr+ssh/sftp [01:06] thanks jml! [01:07] lifeless: Why 'better'? Are there specific features capabilities that are available with one approach, but not the other? sshfs mounts, in general, are much more handily managed locally ... [01:08] sshfs mounts present a very odd picture of the latencies involved [01:08] and don't really act like local resources - for instance file locks won't work. [01:08] bzr+ssh urls will perform /much/ faster [01:09] igc, np. it was fun to get my sql ninja on. [01:10] igc, I just wish that turning an SQL query into a Launchpad page was less work. [01:11] jml: :-) [01:14] lifeless: Huh, I was pretty convinced that file locks over ssfs ARE supported. or do you mean bzr's file locking, in particular? really surprised to hear bzr+ssh is "much faster" ... i mount all over the web via sshfs, and have never really seen performance issues. then again, admittedly i have NOT benchmarked. hmm. worth investigating & learning more, sounds like ... [01:36] james_w: hello [01:36] james_w: how stable do you regard the BaseRecipeBranch api in bzr-builder to be? [01:38] mwhudson: hi [01:38] it can be as stable as you like :-) [01:38] I can offer guaranteed API stability if that's all you are looking for [01:39] but that may mean new APIs for new things, so it depends on why you are interested I guess [01:39] james_w: i'm writing code that translates RecipeBranch &c objects into database objects and back [01:40] if new stuff appears in bzr-builder, this code will have to change [01:40] no way around that in any case [01:40] yeah [01:41] it sounds like API stability isn't the issue as such [01:41] no, i guess not [01:41] data structure stability [01:41] is holding off landing things until LP is ready a better solution? [01:42] we are going to want to make some data structure changes, but they will probably come with recipe format changes, which may give us some flexibility [01:43] hi mwhudson, james_w [01:44] hi jelmer [01:44] james_w: i wouldn't wait on lp for stuff really [01:44] james_w: i can always refuse to have anything to do with formats > 0.2 [01:44] which is probably a good idea in any case [01:45] jelmer: how's your flight looking? [01:46] mwhudson: that's what formats are there for :-) [01:46] james_w: indeed [01:46] once I see some of your work next week then I'll have a better grasp on what your needs are, which should help [01:46] I'm not out to break LP though, so I'll try and make sure that changes that I make are accommodating to you [01:46] thanks [01:47] i guess all i'd like to avoid, or at least know about, are pending fundamental refactorings in how recipes are represented [01:47] that's easy enough to do [01:48] nothing pending in that part currently, except talk of inheritance [01:48] james_w: recipe inheritance you mean? [01:49] yeah [01:50] ok [01:50] well, i'll deal with that when it happens [01:50] at the least, it will be a format bump, right? [01:50] yeah [01:50] but now, I must sleep [01:51] mwhudson: when do you arrive in Wellington? [01:51] or are you there already now? [01:51] james_w: probably only monday morning, or maybe sunday night [01:51] james_w: sleep well! [01:55] ok, I'll see you then [01:55] have a good day [02:00] james_w: I'm flying tomorrow at 8 in the evening. What about you? [02:00] james_w: g'night [02:00] * jelmer gets some sleep as well [02:00] jelmer: 9pm for me, fingers crossed [02:01] night [02:01] g'night! [02:37] hee [02:40] where's the bug? http://pastebin.ubuntu.com/353256/ [02:40] i guess it's in find_branches [02:42] heh ** 2 [02:42] * mwhudson finds https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/15137 [02:45] hey #bzr, I would like to uncommit a merge, but restore the subcommits that were merged. is there an easy way to do this? [02:47] chromakode: i'm not sure i understand [02:47] chromakode: what commands did you run and what would you like to have done? [02:47] mwhudson, unfortunately, someone on my team pulled from trunk, merged their changes, and pushed back to trunk, without proper review [02:48] note that if you just run "bzr uncommit" you'll get into a situation with pending merges [02:48] oh, really! [02:48] chromakode: ah, that old fun [02:48] I didn't know that [02:48] before the merge, there were 3 commits by a reviewer -- they're now wrapped up in the merge [02:48] append_revisions_only = True ftw [02:48] so, I didn't know that factoid... perhaps I can figure it out with that new knowledge [02:48] what/where is that? [02:49] in the .bzr/branch/branch.conf file [02:49] let me see if it's documented somewhere [02:49] thank you! [02:50] chromakode: hm, i found this https://lists.ubuntu.com/archives/bazaar/2008q3/046797.html [02:51] chromakode: and "bzr help configuration" has some stuff [02:51] but first, you need to recover from the mess [02:51] reading :) [02:51] yes. so, now I have 3 commits on my merge queue [02:51] how do I unmerge them? [02:52] note: there's also a commit on head *before* the merge that also needs to go [02:52] the log looks like: [02:52] * bad merge [02:52] * bad commit [02:52] I want: [02:52] 3 x * old commit from merge [02:53] i think something like this [02:53] bzr log --show-ids -l 4 and copy the revid of "bad commit" somewhere [02:53] got it [02:54] then bzr log --include-merges and somewhere near the top you should see the old commits that you want back on the mainline [02:54] yep. [02:54] that'll have a revno like 60.1.3 [02:55] bzr pull --overwrite -r $revno . [02:55] aha! [02:55] will bring that bad to tip [02:55] then i think you can bzr merge -r revid:$bad_commit_revid . [02:55] yes! [02:55] and commit that properly [02:56] s/bad/back/ [02:59] I think that single pull --overwrite did the trick! [03:00] well, it will have obliterated the changes your teammate made [03:00] but looking back, perhaps that's what you wanted [03:03] hi [03:04] if I do a merge that changes a whole heap of files, and then I accidentally edit some files before committing, is there a good way of finding out changes I made that weren't part of the merge? [03:05] jml: do the merge in another copy of the branch, then diff -r branch: [03:06] mwhudson, that's a good idea. [03:06] jml: or perhaps better, do the merge in another copy of the branch, commit it, and then pull from there into the version you made changes in [03:06] mwhudson, ooh, I like that. [03:06] you risk conflicts i guess, but they're probably ones you should know about [03:08] right === mwhudson_ is now known as mwhudson === mwhudson_ is now known as mwhudson [03:21] mwhudson, back -- yes, that's exactly what I wanted [03:21] mwhudson, they pushed it to their own branch before I obliterated them [03:21] thanks very much for the help mwhudson. you really saved me a lot of time. :) [03:22] chromakode: cool, np [03:45] * mwhudson wonders if bzr.dev r4943 will break launchpad === abentley1 is now known as abentley [03:47] Wow. [03:47] probably [03:49] Looks like bzr+http and Loggerhead don't use it, so I should be okay. [03:55] * igc lunch === oubiwann_ is now known as oubiwann [03:57] Yeah, they're ok. [04:02] igc, nice work on the imports! [04:49] spiv: I really want to fix the exception handling in def _run_pre_change_branch_tip_hooks(self, new_revno, new_revid): [04:49] spiv: are you still attached to it? [04:49] spiv: by fix, I mean delete. [04:49] lifeless: lemme look again [04:49] spiv: please do - and compare to '_run_post_change_branch_tip_hooks' right above it. [04:50] lifeless: so the main thing I guess I care about is that TipChangeRejected is still passed through in such a way that a server-side hook can cleanly transmit it to the client. [04:50] lifeless: and I doubt you'll break that [04:51] lifeless: so sure [04:51] spiv: thats a matter of raising that exception :) [04:51] spiv: more than anything else, AFAICT. [04:51] Right. And there are tests about functionality too. [04:51] So if you *do* break it somehow, you'll know :) === Adys_ is now known as Adys [04:52] well, PQM will. But yes :) [04:53] I think I'm still mildly in favour of having some sort of distinction between core code and plugins in cases like this so that we can better report errors (and attribute them to the right software), but not enough to cling to keeping this inconsistent with the rest of bzr. [04:54] spiv: I think we can do that without any formal distinction [04:54] stack introspection for instance, will be better done *without* rethrowing. [04:55] poolie: np [04:55] Don't expect me to consider stack introspection to be cleaner than anything ;) [04:56] spiv: I think we'd need that to get solid results always, anyway. [04:56] igc, i'm going to do the two small bugs i opened against bzr-website [04:56] poolie: I saw the gdesklets one. What's the other? [04:56] mention gnu [04:57] poolie: cool. could you also change Contribute/Plugins to ... [04:57] the new guide ... [04:58] http://doc.bazaar.canonical.com/plugins/en/plugin-development.html [04:59] is this in the wiki? [05:02] poolie: the current link points into the Wiki: http://bazaar-vcs.org/WritingPlugins [05:02] poolie: which just redirects to the new guide [05:03] poolie: I just want to cut out the extra click [05:03] poolie: the tutorial is part of the Plugins Guide now [05:04] ok [05:04] you're talking about the link in the web page footer? [05:04] i can do that [05:04] yup [05:23] ok, it's fixed in trunk but there's a permissions breakage causing it not to update on the live site === abentley1 is now known as abentley [05:31] spiv: I think we need to use introspection because there are many ways a plugin could taint an action [05:31] spiv: hooks are one special case, but not necessarily even the most common source of user experienced errors. [05:31] Sure. [05:32] spiv: https://code.edge.launchpad.net/~lifeless/bzr/hooks/+merge/17005 [05:32] my yak for the day [05:35] spiv: thanks [05:36] No worries. [05:39] are automirror's internals ~= to my sketch ? [05:39] spiv: because I bet its a post push hook, not a pre [05:40] lifeless: oh, post tip change, yeah. I didn't realise your code used pre. [05:41] no worries ;) [05:42] :) [05:42] damn I am tempted to mis quote you two out of context. all that smiles and no worries; all we need is a "she'll be right mate!"... [05:43] spm: or a "no wuckas"? [05:43] spiv: ok, I admit they're very low, but I do have *some* standards [05:47] spm: Good on ya mate [05:47] /ignore lifeless [05:48] hah [05:48] * spm wipes the tears of laughter from his eyes and tries to recall wtf he was doing.... [05:49] yay [05:49] * poolie closes bugs [05:54] igc, do i recall correctly that some measurements last year found bzr doing better than git over a dumb http server [05:55] poolie: in bzr 1.x, yes [05:55] poolie: I think we may have gone backwards over dumb http in 2.x but I'm not sure [06:03] web site is updating again now [06:29] spiv, hi, still around? [06:29] poolie: yep [06:30] in that bug 504102, the problem seems to be that the remotebzrdirformat in the registry is getting its network_name set [06:30] Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102 [06:30] this seems wrong [06:30] would i be right in thinking it should only be set when you're talking about the format of some specific bzrdir? [06:31] Which registry? The bzrlib.bzrdir.format_registry? [06:32] hm, apparently BzrDirFormat._known_formats [06:32] But yes, that's my understanding too. [06:32] i'm not sure how that meshes with the format registry [06:33] The per_bzrdir load_tests explicitly adds remote bzrdirs to the list of scenarios. [06:33] So I'm not sure that the registry is involved. [06:33] ah [06:33] A remotebzrdirformat instance from that load_tests might still be inappropriately shared or mutated, though. [06:33] so it's not the registry, but rather the single instance of that format in the scenario list [06:34] i think all those tests will get a copy of the format [06:34] we could give them a format_class instead [06:34] Possibly the solution is simply to specify the default network_name at load_tests time? [06:34] hm [06:35] if the format object can be mutated (implicitly by calling other things on it) [06:35] Yeah we assumed formats were immutable [06:35] then it seems like asking for trouble for multiple tests to share an instance of it [06:35] I think copying the Remote format in each scenario would make sense here. [06:35] mm [06:35] alternatively we could make them actually immutable again [06:35] that may be harder [06:36] poolie: Remote formats are proxies though, so its hard. [06:36] mmm [06:36] (let's go shopping) [06:36] couple of other random thoughts: [06:36] hm [06:36] - its possibly a bug, a test that should dup the format and writes to it: easy answer: fix that one test. [06:36] they can only actually know this if they're connected to a particular instance of a bzdir [06:37] - generally we get a RemoteFormat* via factory methods, so there isn't a reason for production code to be altering the scenario format object. [06:37] lifeless: using the format to initialize a branch implicitly mutates it [06:37] poolie: oh MEEP [06:37] mm [06:37] poolie: I consider that a bug [06:37] sorry for introducing it [06:38] it looks ugly to me at least [06:38] easier to reason about these things if they're immutable [06:38] Perhaps initialising a branch should give that branch a copy of the remote bzrdir format? [06:38] immutable I think is hard here, but altering the parameter format should be unnecessary and can cause bugs. [06:39] What lifeless just said :) [06:45] More generally immutable objects in python don't seem to work well: python is not geared for such idioms, with the notable exception of strings (and there too we run into performance and space issues) [06:46] mm [06:47] so we may be able to just remove the sideeffect of setting the name when it's created [06:47] if nothing relies on that we should be ok [06:47] We'll want the format the branch uses to have the name set if we know it [06:47] lifeless: this is the kind of thing i mean about the tension between the Format and the class of the instance [06:47] probably its passing in a format it should duplicate [06:48] poolie: well, RemoteFormat is a proxy object anyway; I don't see that this adds to that tension [06:49] well [06:49] it's kind of half a proxy object [06:49] obviously it can be a proxy for an actual remote bzrdir [06:49] it can also be exist in the abstract without one [06:49] poolie: I've recently in another project had cause to do format markers on disk again, and I used the split style we do in bzr again - I find it really easy and clear to work with - it made two separate hierarchies with separate concerns. [06:49] to me that is a reflection of the tension [06:50] well [06:50] we have this bug [06:50] poolie: RemoteRepository can't exist in abstract; Remote*Format can - but then so can BzrDirMeta1Format [06:50] it has state and can be parameterised. [06:51] i think the bugs we see here show that the code is not clear about what the object represents [06:51] doing that (BzrDirMeta1Format parameterisation) in the class would be really unpleasant, I think - it would make what shouldn't be global, global state) [06:51] poolie: Have a good weekend :) [06:52] poolie: [I'm still sick, can't really make a good case for or against anything atm, and this isn't a shallow discussion.] [06:52] yeah, thanks [06:52] no [06:52] don't worry, i'm not going to pull it out now [06:53] poolie: which method is mutating the format do you know? initialise_on_transport? [06:53] poolie: oh I know :) You'd have to replace all the things that work well at the moment with something cleaner, to pull it out :) [06:53] _initialize_on_transport_ex_rpc [06:53] poolie: huh [06:53] poolie: that method already goes to the trouble to make a new RemoteBzrDirFormat object [06:54] poolie: so really it should be mutating that, not self, I think [06:54] sometimes a bug is just a bug [06:54] spiv: ack [06:54] line ~3263 [06:54] that's what i changed [06:55] spiv: ah, I see. I was stupid. [06:55] lifeless: it happens :) [06:55] spiv: it uses its own state to make the rpc call. It shouldn't. [06:55] lifeless: right [06:55] right [06:56] it's used as both the archetype of the thing you want to create (in which case it can be partly populated) [06:56] and the actual value of a thing, in which case it should be fully populated [06:56] there's not necessarily anything wrong with this... [06:56] http://pastebin.com/f5b89a4ba [06:56] but, with object aliasing etc, it seems a bit dangerous [06:56] should fix i t [06:57] yes, thanks, i did that 20 minutes ago [06:57] poolie: cool [06:57] i'm waiting to see if it passes [06:58] btw, what's the difference between known_formats and format_registry? [06:59] offhand: known_formats == svn, hg, bzr, git, cvs [06:59] format_registry == bzrmeta1 format logic [07:00] nope thats wrong [07:01] it's something like that but i'm not sure if it really needs to be in a not-quite-a-registry [07:01] I think known_formats is perhaps just what we had before format_registry [07:01] i think the format_registry is the registry of pre-baked combinations [07:01] yes [07:01] as opposed to the list of BzrDirFormats [07:01] that bit I'm sure of [07:02] there is a commment explaining something about it [07:02] it might be a thing to remove / turn into a separate object, but I'd need to page it in, look at what it has in it properly. [07:02] nm [07:02] was just wondering [07:02] i think this is passing so while it runs i will poke at tribunal [07:02] have a good weekend [07:02] Another WAG - it will have BzrMetaDirFormat1, BzrDirFormat4, BzrDirFormat5 etc [07:03] i can see the different things that are registered [07:03] i guess i wondered if it really matters [07:03] poolie: the comment it has is about performance probing for stuff. No idea if thats still relevant. [07:12] igc: I hope you don't land that --bind change - I really didn't see consensus on the list. [07:20] oh, ugh. I just replied to a 5 year old mail. [07:20] * lifeless blushes [07:21] https://code.edge.launchpad.net/~mbp/bzr/504102-test-isolation/+merge/17006 is the patch, still running i think [07:22] poolie: approved already :) [07:23] yoy [07:23] yay* [07:25] jml: ping [07:25] jml: I'd like to make your weekend hacking nicer; to that end care to approve my two testresources merges? ;) [07:25] you know what I'd love. [07:26] implicit per-product PPA's. [07:26] yes [07:26] would be great [07:26] with product relationships permitted to get product->product dependent PPA's. [07:26] i'd like a view of all bugs tagged hottest100 across all projects [07:26] e.g. ppa:bzr/releases would depend on bzr-git/releases, if bzr-git was a relationship [07:26] hi all [07:27] hi vila [07:27] I think that would be awesome. [07:27] i was just thinking of you in bug 504640 [07:27] Launchpad bug 504640 in bzr "selftest hang in test_bzrdir.TestHTTPRedirections_readonly.test_loop" [Low,Confirmed] https://launchpad.net/bugs/504640 [07:27] lifeless: if by 'depend' you mean 'virtually include' that would be even cooler perhaps [07:28] * vila curses vbox for crashing again :-( [07:29] poolie: sounds a lot like the issues I encountered while debugging the leaking tests, say 90% [07:29] but it's not really important [07:30] poolie: was it a full test run or a partial one ? --parallel involved or not ? (Not that it really matters, but it's always good to know a bit about the context) [07:31] oh [07:31] full, nonparallel, with -f [07:33] poolie: I do [07:40] shouldn't 'bazaar-ng' have been a clue? :-) [07:43] poolie: figured they had an old list ref [07:46] greetings... what's the best way to safely backup a (live) Bazaar repository? === jamesh_ is now known as jamesh [07:54] eLowar: Using Bazaar itself would probably be best, except for the possibility of corruption. [07:55] eLowar: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html [07:55] Oh. [07:56] Peng: I know, actual documentation addressing things users care about, weird huh? ;) [07:58] Trying to take all the fun out of figuring out solutions, huh? [08:03] Peng: not sure, give me a sec to find the docs on that topic ;) [08:19] thanks a bunch [08:21] spiv: Maybe there's a blueprint! [08:22] oh and sorry for running off like this ;) I'm at work and we were trying to find this documentation, so I can't stay and chat right now :) [08:22] cheerio [08:22] eLowar: that's ok, glad we could help :) [08:32] * igc dinner [08:32] poolie: so, about leaking tests, another way to look at it is to realize that the hang you encountered is one aspect of it. The irony is that the more bugs I fix in this area, the more likely it becomes to trigger hangs. That means all the related bugs should be fixed or we shouldn't touch it at all (and hope we keep being lucky to avoid it on pqm) :-/ [08:34] poolie: I was close to fixing them all (famous last words) when I realized that while running full test runs without --parallel (which change the context enough to change the overall behaviour in various ways ...) [08:43] vila: that while [...] what ? [08:44] that, while [08:52] vila: I still can't parse it [08:52] vila: In english, the that that you have before the while implies a clause to which the that will bind [08:53] . [08:54] When I stopped working on that, I had the full test passing with --parallel=fork (and 8 threads) [08:54] From there I wanted to run witout --parallel=fork to get data on how tests were still leaking (the report doesn't work with --parallel) [08:54] The runs hang [08:55] that (while ...) [08:55] ok [08:55] so what report? we could do it in --parallel probably [08:56] yeah, that seems to be our best protection so far [09:13] Hello all [09:36] hello all [09:51] lifeless: ghaa, I totally misread you remark, so the report that failed is the one about the leaking tests which presumably is lost into the test reporting (search for leak in tests/__init__.py, that's the first occurrence) [09:55] "Treeless" when creating a branch means that you don't get the working copy, doesn't it? [09:55] yes [09:58] hi vila [09:58] hey bialix [09:59]