[00:34] jelmer, any progress? [01:10] zzz... [01:10] jelmer, well, will be around another hour or so still i think [01:24] just saw the update [01:24] awesome [01:37] is it possible to do what i want here: [01:37] bzr diff ../milestone-proposed -r 1184 [01:37] that command works [01:37] what do you want it to do? [01:37] well, yes. it exits 0 [01:38] i want to know what the differences between this dir and the branch at tip ../milestone-proposed at revision 1184 [01:38] s/tip /tip and / [01:38] err... [01:38] this dir at tip and revision 1184 of ../milestone-proposed [01:42] poolie, ^ [01:43] bzr diff -r 1184:../milestone-proposed [01:43] if by 'this dir' you mean '.' [01:44] thank you sir. [01:45] is there a way to say "tip" in the above ? [01:46] i guess '-1' works. [01:46] but that always seems so counter-intuitive to me [01:46] i like git's "HEAD" alias [01:46] smoser: do you mean rev 1184 of 'this dir' or of milestone-proposed? [01:47] milestone-proposed [01:47] poolie's answer was what i wanted. [01:47] Oh, right. [01:47] smoser, if you want to diff . to the tip of milestone proposed [01:48] bzr diff -r ../milestone-proposed [01:52] jelmer, catch you tomorrow probalby... === CapnRobby is now known as robbyoconnor [06:19] under what circumstances does the submit branch get set by bzr? [06:19] the waht [06:21] submit_location, :submit, I'm not sure exactly what to call it; it's used as the default target for bzr send, among other things [06:21] hmm [06:21] ive notused that feature so i'm not sure [06:21] is it in bzr.conf or the user config file? [06:22] it's stored in .bzr/branch/branch.conf along with push_location, parent_location etc. (although the global locations.conf can override that) [06:22] I don't use it much either, but somehow my "trunk" branch keeps on getting some random local branch set as the submit branch [06:22] what is it set to by default? [06:22] nothing [06:23] unfortunately every time I notice it, it's been too long since I actually did anything with the branch it's referring to, so I can never figure out what it is I'm doing that causes it to be set [06:23] oh hang on [06:23] one of the other developers will probably know better [06:23] I think I just figured it out (this always happens as soon as I decide to ask on IRC about something) [06:24] i know right =P [06:24] bzr merge sets the submit branch if it's not already set; that seems... weird [06:27] idnar: use --no-remember [06:28] yeah, but how will I ever remember to do that? :P [06:28] I suppose it makes sense for "downstream" merges [06:29] it's just that I mostly only do "upstream" merges, so it seems backwards to me [06:31] yeah, that's the problem with default values, sometimes you can't satisfy everybody :-} [06:31] is there some way to make --no-remember the default for bzr merge? [06:32] perhaps I should just not care about it, I don't think I ever run any command on my "trunk" branch that uses the submit branch, so it doesn't really matter if it gets set to something [06:32] well, having a submit_branch set [06:33] idnar: "bzr alias merge='merge --no-remember'" [06:33] idnar: yup, that's what I do (don't care), in rare cases I have to 'bzr config --remove submit_branch' or force a different value, but still, in most of the cases, --remember is what I want [06:34] vila: I guess we have different workflows or something [06:34] * vila nods [06:34] 90% of the time when I run bzr merge, it's to land a branch on trunk [06:35] idnar: just set a submit_branch for trunk and it will be kept [06:35] how do you set a submit branch [06:35] vila: trunks typically don't have a submit branch, though? [06:35] edit the config file? [06:35] yeah, but what would I set it to? I suppose I could make it the same as the push location [06:36] spiv, randi: indeed, but I use the remote branch i.e. the push_location [06:36] (I mean you could set it a dummy location like /dev/null, but that's obviously a hack) [06:36] using the push_location also is the Right Thing for diff -rsubmit: [06:37] vila: sure, a copy of trunk might have a semantically sensible push_location [06:38] hmm, I keep forgetting about bzr lp-submit [06:38] vila: I don't think it makes good sense to say it has a submit_branch though. It's a sink for submissions, not a source. [06:39] yeah, ideally if I run some command that uses the submit branch, it would just give me an error about there being no submit branch, instead of doing something meaningless [06:39] not that it's a big deal, more of a semantic nit [06:40] (A setting that happens to produce ok behaviour in the tool does not automatically equal a setting that makes sense to humans) [06:41] hmm, that reminds me, there's a bzr merge --preview; but is there a way to do it from "the other side", like bzr send --preview or something? [06:42] (I'm not sure if bzr send would be the right command for that, just trying to explain what I mean wrt direction) [06:45] idnar: instead of 'bzr merge --preview FOO', 'bzr merge -d FOO --preview .", perhaps [06:46] hmm, that only works with local FOO [06:46] Otherwise you could probably use -rancestor: or something like that [06:47] idnar: hmm, I thought that might be the case :/ [06:47] idnar: that's probably a relatively easy to fix limitation [06:47] (and it probably already has a bug report...) [06:47] heh [06:47] well, not really important, I was just pondering if I could actually eliminate bzr merge from my workflow almost completely ;) [06:49] Tarmac eliminates the need to actually land the branch on trunk myself; but I still need a way to preview the merge result for code reviews, when Launchpad's preview isn't sufficient [06:49] spiv: I've yet to encounter a case where using such a submit_branch cause problems [06:50] (not that there's any particular need to eliminate bzr merge from my workflow, it was just an interesting thought) [06:50] err [06:50] s//I've never encounter/ [06:53] and hi all ! [06:55] spiv: and to be honest I have to "trunks": a mirror of upstream and an integration one. The later is where I merge various other branches before submitting to pqm. [06:55] vila: I'm not saying bzr will misbehave, I'm saying that it doesn't make sense to a human reader of that value. [06:56] The later has a push_location which is *not* lp:bzr, in fact public_branch and push_location are my lp corresponding branch and the *submit_branch* is lp:bzr, all locations make perfect sense there (parent_location is lp:bzr) [06:58] vila: sure, in your workflow for working with lp:bzr (which involves PQM, etc) that's fine [06:58] vila: there are common workflows where having a submit_branch set doesn't match reality, even if it is technically harmless [06:59] * vila nods [07:02] It also works for the plugins I maintain where I have: parent_location=lp:plugin, push_location=lp:plugin and submit_branch=lp:plugin where my "trunk" branch in this case is really the authoritative branch and the integration one [07:02] When I say "works" I mean: having a submit_branch is enough to avoid merge setting it to an inappropriate value [07:03] But don't you agree that ideally in that case it wouldn't be set at all? [07:05] The answer to "where are changes made on this branch submitted to by default?" is "they aren't!" [07:05] well, no :) *I* use it with diff -rsubmit: to check what I will push [07:06] Wouldn't diff -rpush: would make more sense for that? [07:06] (and be shorter to type!) [07:06] Or missing :push, perhaps. [07:06] could be, but diff -rsubmit: is faster because it's bound to H-z m (2 keystrokes) whereas diff -rpush: is not :-D [07:07] * spiv raises an eyebrow [07:08] spiv: but yes, I agree that for authoritative trunks, there is no places from where you want to merge, they are potentially different for every merge [07:08] hi vila, diff [07:09] s//spiv [07:09] lol [07:09] poolie: _o/ [07:10] * spiv waves [07:54] Riddell, hi [07:54] jelmer, vila, riddell, jam, chat in 5m? [07:54] hola [07:54] * vila nods [07:55] already doing the audio configuration dance [07:55] :) [07:56] :) [07:59] hi poolie, I'm in [08:30] vila: I have to go work with my wife for a little bit, but it would be nice to hear your thoughts on the select() issue. [08:31] Riddell: is there more work to be done on the packaging guide for UDD? [08:32] hi jam [08:32] is there any discussion about it other than the mp? [08:32] i was going to say specifically for EINTR [08:32] jam: sure, roughly: let's make it simple in production (no loop), pay a bit in the test suite while filing a bug about easier ways to get servers running in their own process (there are ways to get *one* process shared between tests) [08:32] jelmer: I don't think so (there's more work to be done on it for traditional packaging) [08:32] poolie: I think it has mostly been on the mp or on the bug. Though I guess there has been a fair amount last week between vila and I on IRC [08:32] you should almost always just restart the syscall, perhaps just checking any other preconditions like "was i interrupted" or "has the timeout expired" [08:33] poolie: right. which points me at vila: we need a loop to handle EINTR, we may as well keep the loop [08:33] poolie: I went to the bug yesterday to mention the error handle only to find you an spiv already saying the same thing [08:33] jam: only for tests no ? [08:33] vila: EINTR we need to handle in production [08:33] keep the loop and use it for what? [08:34] otherwise if someone resizes the terminal during 'bzr serve' it could cause weird interactions. [08:34] right [08:34] poolie: to handle EINTR, we nede to catch the exception and restart select() [08:34] resizing the terminal in production ? [08:34] so we need a loop [08:34] vila: "bzr serve" on my terminal, and then resize it [08:34] triggers signals [08:34] which the application might ignore [08:34] we've had bugs in the past [08:34] where it caused EINTR that we didn't handle, and bzr crashed [08:35] i'll reply abotu that [08:35] I *think* we fixed them by no longer listening to SIGWIN* or whatever [08:35] yep, we don't want that [08:35] correct [08:35] but, eintr should still be handled [08:35] sounds out of scope for the bug you're after no ? [08:35] but it is something that, in general, we should have a loop to handle EINTR for cases where we get a signal [08:35] which is unrelated to this select [08:35] vila: getting *any* signal causes all blocking calls to return [08:35] with EINTR [08:35] read/select/etc [08:36] yeah, not the bug you're fixing right now [08:36] vila: we would be *introducing* a new bug if I don't handle EINTR [08:36] ? [08:36] vila: specifically, with the code I'm writing, if I don't handle EINTR, I will disconnect clients if the process gets a signal [08:37] (the way the code is written today) [08:37] vila: as a "for example", say we have a signal that you can use to tell bzr to do a memory dump. We don't want clients to get disconnected while trying to get a memory dump of the running server process. [08:38] and you want to take care of that for every call to select/recv/send ? [08:38] vila: we already should be taking care of it, and don't [08:38] we do in some places [08:38] which is why the osutils wrappers exist [08:38] vila: "osutils.read_bytes_from_socket" has EINTR handling [08:39] as does osutils.send_all [08:39] And a fairly obvious "osutils.until_no_eintr" [08:40] how about having the main thread takes care of signals and put the real server in its own thread so we get the same model for PipeServer and TCPServer instead of tracking every call that happens in the call stack then (but I didn't mention that to in your bug scope...) [08:41] jam, done [08:44] poolie: thanks for the review. I did fix the rs/xs stuff but forgot to push the latest, though you still found a couple bugs I didn't fix [08:48] poolie: actually, because you noticed I wasn't terminating the loop on 'xs', that might be why I was seeing bugs even when passing errfds. [08:48] Specifically, the first call would get 'you have an error here', and return it into xs [08:48] but then I wouldn't stop the loop [08:48] right [08:48] and then the rest of the calls wouldn't say anything [08:49] that could very well cause it to hang if the near end of the socket closes [08:49] though... [08:49] i would have kind of expected select might just error out entirely [08:49] oh, on the other topic of running the server out of process [08:49] poolie: I would think I would have kept getting xs returned, though, so even if we loop until timeout, it would still end up with xs [08:49] it does seem like it would fix some persistent kinds of bugs where tests misbehave or are not realistic [08:49] The issue was that I was never seeing "xs". [08:49] Anyway, I'll poke at it. [08:50] also, there is the 'testresources' library which might help with having an external server that runs across multiple tests [08:50] obviously we would not want to stop and start it on every test [08:52] yup, lp:bzr-local-test-server is a variation around this idea where you explicitly start/stop real servers and inject the running ones into the test suite [09:22] i'll send out the standup notes [10:05] do plugins in bzrlib/plugins/ have unit tests? [10:10] Riddell: yes, usually in the tests directory in the plugin [10:10] jelmer: oh aye, and do they get run with the normal test suite? [10:26] Riddell: yes, even when you do BZR_PLUGIN_PATH=-site, they are the so-called 'core' plugins === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan [12:23] jelmer, hey :-) [12:24] hi Noldorin [12:24] Noldorin: do you *ever* sleep? [12:24] haha [12:24] no, i'm always online to pester you ;-) [12:25] i often go to bed very late and wake up around midday [12:25] you're in Europe? [12:25] London, yep [12:27] netherlands for you i presume [12:27] yep [12:28] want to visit some day :-) [12:28] jelmer, any luck with the issue anyway? [12:28] Noldorin: I added a test case for it yesterday [12:29] ok cool [12:29] Noldorin: I'm hacking on it in my spare time though, working on other stuff at the moment. [12:29] yes i saw [12:29] okay [12:29] other core bzr stuff eh? [12:31] yep [12:45] james_w: ping [12:45] hi vila [12:45] jelmer, playing more with the script reveals that moving a directory -or- renaming a directory works fine, but doing *both* at once screws it up [12:45] jam, hi? [12:45] james_w: hey ! That was quick :) [12:46] james_w: If you know how to make tea, can you have a look at https://code.launchpad.net/~vila/udd/795321-make-tea/+merge/76058 and give feedback ? [12:46] vila, yeah, it's in my inbox [12:46] along with 100 other things :-) [12:46] I'll look today [12:46] james_w: awesome ! [12:46] I read your cover letter and I think I like your approach [12:47] I certainly agree that the circuit breaker pattern isn't quite the right fit [12:47] james_w: we expect more lp downtimes so probably more failure storms and I suspect the should_retry have rotten (I'm sure you added transient failures for lp in the past but sigs have probably changed since them) [12:48] james_w: yeah, not a perfect fit, but it helps making the actual code smaller [12:49] (and can be tested independently *today* [12:50] jelmer, that shoudl really narrow it down :-) hopefully you can work on the issue today? [12:54] Noldorin: no idea, working on more things than just this... [12:54] okay [12:55] jelmer, we all have our own priorities i guess :-P this is obviously high for me [12:55] but much less high for the bzr time [12:58] jelmer, is bzr-git still the best solution for mirroring LP branches on GitHub? [13:10] Noldorin: yep [13:17] How can I check that a copy of a branch is correct without overwriting the existing branch? I'm trying to recover from serious file corruption caused by Dropbox, and I want to check that they restored things correctly. But when I run bzr in the restored directory, I get this error: No working tree exists for . When I symlink it to the original location, I get the same error, showing the target path, [13:17] not the symlink path. [13:21] mwhudson: did any of your anonymous ssh stuff land? I'm running into problems with "bzr branch lp:bzr-rewrite" giving me a "bzr+ssh://" URL, even though the build machine has not called "launchpad-login" [13:21] (I don't have an ssh key there, etc.) [13:28] jelmer: Help? It looks like 'bzr-rewrite' lost its development focus branch. [13:28] https://launchpad.net/bzr-rewrite/trunk [13:29] doesn't have a branch link. [13:29] How can I check that a copy of a branch is correct without overwriting the existing branch? I'm trying to recover from serious file corruption caused by Dropbox, and I want to check that they restored things correctly. But when I run bzr in the restored directory, I get this error: No working tree exists for . When I symlink it to the original location, I get the same error, showing the target path, [13:29] not the symlink path. [13:30] mssever: if you are running "bzr status" that doesn't apply to a repository/branch that doesn't have a working tree. [13:30] You could try "bzr log" or some other command. [13:32] bzr log says Not a branch location is a repository [13:32] jam: See ^^ [13:32] jam: And, it is supposed to be an exact copy of a working tree. Does this mean that it isn't an exact copy? [13:33] mssever: ls .bzr ? [13:34] jam: The .bzr directory is there, but I don't know if it has the right contents. [13:34] Dropbox Updated part of the tree with an old version, and deleted some files [13:35] mssever: sure, I'm asking for the output to help discovering what is going on. [13:35] for example, if there is a ".bzr/branch" or ".bzr/checkout" directories. [13:35] Oh, OK. Here goes: [13:35] ls .bzr: [13:35] branch/ branch-format branch-lock/ checkout/ README repository/ [13:38] jam: I'll set one, thanks for the hint [13:38] jelmer: well, I failed to build the windows installers [13:38] Not sure what changed [13:38] jam: fixed [13:38] jam: I converted my branch mirrors to code imports [13:39] ok [13:39] are there any others that would be affected? [13:40] jelmer: and, of course, you've now broken my test case for fixing the related mis-communication in bzr :) [13:43] jam: Did you notice my last reply? I forgot to mention your nick... [13:44] jam: I'm checking the other branches now [13:45] jam: sorry! I can re-unlink it if necessary :) [13:54] jam, any idea when the Windows build of 2.5b1 will be available? :-) [14:14] helos. new to bazaar. looking for a solution to this situation: we have a software project that has public and private source parts. we want both in one repo with user access control to allow some people whole r/w access and others only write access to the public parts. is such a setup feasible with bzr? [14:17] jam is ignoring me :-( [14:33] Noldorin_: he is probably building them, that doesn't count as ignoring you :) [14:34] vila, i was mainly teasing...but yes, i hope so anyway! :-) [14:34] iorec: bzr doesn't support different access patterns inside a given branch, you need to define separate branches [14:34] jelmer: by the way, should you upload 2.5b1 to debian ? [14:37] vila: so i could have a single repository with public and private branches? [14:38] iorec: see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief so use the same meanings for the same words :) [14:39] iorec: a repository is just a bag of revisions, a branch is a pointer to an entry point in a graph of revisions (directed and acyclic, so-called DAG) [14:40] you can use the same repository for unrelated branches, but in your case that will make it harder to separate who can write from who cannot [14:42] jelmer, i see a comment in the bzr-git code saying "renames not supported:...? [14:42] if you keep unrelated branches separate, it will be easier to define the access with scripts like contrib/bzr_access and the like [14:43] hello all [14:44] I've just installed bzr v2.4.1 from PPA [14:44] I'm wondering how to use branch.fetch_tags [14:44] Noldorin_: that's for roundtripping [14:44] should it be set in .bzr/branch/branch.conf or ? [14:44] jelmer, how do you mean? [14:44] bazaar.conf ? [14:45] cerf: it should be set for the source branch, so either in the source branches' branch.conf, bazaar.conf or an entry in locations.conf [14:45] Noldorin_: "regular" push [14:45] Noldorin_: not dpush [14:45] jelmer, oh ok [14:45] so i can ignore that huh? [14:45] Noldorin_: git doesn't do renames [14:45] got it [14:45] ooh. another reason not to like git ha! [14:46] vila: the thing is that we want people with full access to be able to checkout one revision of the main branch and have everything they need (public and private parts) and others with public access only checkout the same revision but only get the public parts. [14:46] jelmer, i thought bzr cannot do "push" at all to git though? [14:47] jelmer: I'm looking at https://code.launchpad.net/~jelmer/bzrtools/unused-imports/+merge/73265 what's the best way to run the test suite of bzrtools? [14:47] Noldorin_: it can [14:47] Riddell: BZR_PLUGINS_AT=bzrtools@`pwd` bzr selftest -s bp.bzrtools [14:47] jelmer, but dpush is preferable for some reasons.../ [14:47] ? [14:48] Noldorin_: it's experimental, not enabled by default [14:48] okay sure [14:48] makes sense [14:48] vila: yeah, I should upload to experimental I guess.. [14:48] jelmer, since i am so eager with this, maybe you could point me to the bit of code that handles bzr moves/renames in dpush? :-) [14:49] iorec: bzr tracks whole trees so having people use different trees won't work out of the box, there are some parts of your needs that can be addressed with views, others may work with nested trees (not implemented yet), but overall, there is no way to get what describe directly [14:49] jelmer: thanks I'll try it [14:49] iorec: s/what describe/what you describe/ [14:49] hope this can help for bug https://bugs.launchpad.net/bzr/+bug/843684 [14:50] Ubuntu bug 806348 in Launchpad itself "duplicate for #843684 BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] [14:57] vila: thanks. it seems so strange that ours is obviously a special case setup since none of the popular revision control systems seem to support such a setup. so it seems to me we'll have to manually handle 2 repos and always say rev XY of repo A is the one that fits rev ZW of repo B. [14:59] iorec: well, once you start using distributed VCS, access rights... are less relevant, to start, either you publish or you don't, if you publish, you don't blindly accept submissions, they are generally checked before being accepted and at that point, the checkers generally have write access [15:00] so bad, that didn't help [15:01] still get 'missing chk node(s) for id_to_entry maps ' [15:01] iorec: keeping two related projects in sync is what nested trees are about, but the progress is slow on that front as we focus on other subjects (with our limited resources ;) [15:01] in bug report https://bugs.launchpad.net/udd/+bug/806348 [15:01] Ubuntu bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] [15:02] jameinel talked about a quick regression avoidance with https://bugs.launchpad.net/bzr/+bug/771184 [15:02] Ubuntu bug 771184 in Bazaar "option to disable/enable fetching of all tags" [Critical,Fix released] [15:02] how to use it ? [15:03] I've put 'fetch_tags = True' in the bazaar.conf file of my source branch, but still got a crash [15:04] I've also tried 'branch.fetch_tags = True" with no luck [15:04] Noldorin_: there is no such thing, as git doesn't store renames [15:05] cerf: are you sure you're actually hitting *that* bug? [15:07] vila: yes, i am still new to distributed vcs and hoping i haven't fully understood its potentials yet.. [15:07] I'm not sure, my original bug report (843684) was considered as a duplicate of 806348 [15:07] is it really a duplicate ? [15:08] jelmer, well, put it this way...where in the code do you "handle" bzr renames...translate them to git? [15:09] For bug 806384, John A Meinel suggested a "quick regression avoidance" actually bug 771184 [15:09] Launchpad bug 806384 in Nikki and the Robots "Allow dynamic block coloring" [Undecided,New] https://launchpad.net/bugs/806384 [15:09] Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [Critical,Fix released] https://launchpad.net/bugs/771184 [15:09] iorec: there is a bunch to read at http://doc.bazaar.canonical.com/ not sure what is the most relevant for you, but asking questions here or on the mailing list is welcome (answers depend on available time though ;) [15:10] mssever: Sorry, I had to step away for a sec. If you have ".bzr/branch" but it says "not a branch", then something is particularly broken. [15:10] so this where I am, I'm stuck at trying to do do simple merge between two branches [15:10] I don't really have the time to debug it at this point. You can try to create another branch in a different location, and see how they differ. [15:10] vila: ya thanks i'm already reading... [15:11] Noldorin_: I don't specifically know when 2.5b1-1 will be available. I started working on it this afternoon, but ran into problems with plugins no longer being available. (jelmer changed some things, and accidentally broke the linking). [15:11] That looks to be fixed, but as I'm past the end-of-day here, it won't be worked on until tomorrow at the earliest. [15:12] Noldorin_: renames aren't "handled", but _revision_to_objects (IIRC) is where generating the git objects happens. [15:12] jelmer, okay got it [15:12] ta [15:14] vila, jelmer, Riddell: Have a good night. I'll see you guys around tomorrow [15:14] jam: _o/ [15:14] ciao [15:14] jelmer, i see no such function...which file might you know [15:14] ? [15:21] jelmer, never mind i see [15:24] jelmer, oh interesting...i just noticed the tracelog suggests bzr-git is doing a *pull* when i run dpush :O [15:26] Noldorin_: it is, it pulls the changes pushed into git back into your local branch [15:26] jelmer, that's interesting, didn't know. why does it need to do that? [15:27] Noldorin_: as you're aware, dpush changes the source branch [15:27] indeed [15:27] Noldorin_: this is how [15:27] right [15:27] it's just *why* it needs to pull back into local branch that i'm wondering :-) [15:28] Noldorin_: otherwise you have a diverging source and target branch [15:28] okay.. [15:28] jelmer, does the pull-back actually affect a) the content of the branch b) the revision data c) some other metadata? [15:29] Noldorin_: it discard the existing branch [15:29] obh [15:29] Noldorin_: but you've used dpush, so you should've seen what it does? [15:30] jelmer, so i lose all bzr metadata in the local branch too? [15:30] Noldorin_: yes, unless you use --no-rebase (which prevents that pull) [15:30] Noldorin_: if you don't rebase you can't pull from the git repository [15:30] ahh [15:30] got it [15:31] jelmer, well no-rebase is fine for me for now :-) [15:31] jelmer, eventually when you get proper push support working i can change over...i guess you are gradually working on that [15:35] Riddell: why are you reviewing bzrtools merges? [15:36] abentley: because I'm patch pilot and I've run out of bzr patches to review so I'm doing all bazaar [15:37] and these patches have been sitting around for over three weeks, clearly the bzrtools maintainer is slacking :) [15:37] Riddell: bzrtools isn't a Canonical project, and I'm not asking for the patch pilot's reviews. [15:38] Riddell: I'm slacking, sure. But I already know how I feel about those patches. [15:41] abentley: could you set a state on those kinds of mps so people know not to be helpful? [15:42] mgz: That wouldn't be slacking. [15:42] :) [15:55] jelmer, what's interropostiroy? === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] [16:12] jelmer, even closer in finding what it is, if you're curious :-) [16:14] when you try to access non-existent items, the error messags are not very informative btw [16:14] non-existent files/dirs that is [16:51] jelmer, okay, so i have identified exactly what the problem is :-) === zyga is now known as zyga-afk === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno [17:33] Noldorin_: apparently I lied, bzr 2.5b1-1 has been uploaded. :) === zyga-afk is now known as zyga [17:45] jam, just saw it, that's excellent. thank you :-) [17:45] jam, any indications how stable it's proving btw? [17:49] Noldorin_: I don't know about the installer, but I use bzr.dev daily [17:49] jam, ok that's reassuring [17:53] jam, i understand it supports collocated branches. but does that mean individual local branches can be pushed to a remote collocated branch? [17:53] using some special URL syntax [17:54] Noldorin_: you'll need to check with Jelmer, but I think you still need the 'bzr-colo' plugin to enable collocated branches. [17:54] ah right [17:54] It does have the new syntax (http://url/to/repo/path,branch=X) [17:54] jam, awesome. i hope that works with git branches too! [17:57] Noldorin_: i'm pretty sure that was the inspiration. I don't think bzr-git is bundled yet. [17:57] I think Jelmer has a patch, that I'll bring in for the next beta [17:57] so bzr-2.5b2-1 will probably have bzr-git support [18:13] jam, yeah so i heard. but i have no prob installing it as a plugin for now [18:14] jam, just pestering jelmer to fix this bug now that i've very narrowly identified it :-) [18:14] with dpush to git === Ursinha is now known as Ursinha-lunch === med_out is now known as medberry [19:10] jelmer, ping? [19:50] Noldorin_: hi [19:59] hi jelmer [19:59] get my updates? [20:05]