[01:40] can i do partial commits ? [01:40] of a file [02:13] methods: i think there is a plugin, bzr-interactive, that lets you do that [02:13] * mwhudson afk for a spell [06:38] hi. i am trying to find documentation on bzr-git but there is not much. how would you check out http://drupalcode.org/project/drupal.git/log/refs/heads/6.x this branch? [06:46] nevermind [09:18] 'morning [09:36] mgz: are you here? [09:36] hi all [09:36] morning bialix. [09:37] * fullermd waves at bialix. [09:37] * bialix waves at fullermd :-D [09:37] morning mgz [09:38] mgz: can you refresh my memory about standalone bzr.exe: if it don't want to start because of missing msvcrxx.dll then one needs to install redist package from microsoft, right? [09:38] yes, though we still need to work out exactly what circumstances that happens in so we can fix it properly [09:39] so far, we've had a bug report from someone on win2000, and one from someone on server 200..8? [09:39] I have something similar on XP machine [09:39] this is unhappy, xp should really work. [09:39] what redist package I need? for which VS? 2005 or 2008? [09:40] that's not on my own computer< I'm trying to help other man [09:42] python 2.6 builds against 2008... I'd need to look up the exact minor version of the dll it needs. [09:42] just uninstalled my all-in-one bzr copy annoyingly [09:43] on the microsoft site there are simple redist and sp1 [09:44] I suspect I need plain one [09:46] that's what I remember. [09:46] (the normal one, not sp1) [09:47] ok, I'll try that === bialix_ is now known as bialix === Ursinha is now known as Ursinha-afk [09:59] bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 111] Connection refused === bialix_ is now known as bialix [10:02] garr, I keep trying to do things only to find out maxb has already done them in the last 15m [10:03] The obvious solution is to sneakily reset his clock... [10:03] I was considering getting up 20 minutes earlier, but I guess that works too :) [10:06] :-) [10:07] I'm not entirely sure getting up has anything to do with it, considering I'm still in bed [10:13] LOL [10:13] * bialix waves ta vila [10:14] * vila waves to all :D [10:18] hi all [10:22] Moggûh John :) [10:23] jelmer: huh, it always sounds more like "Morgen", but hey, I'm still trying to figure out the pronounciation of Dutch words. [10:23] Waalre ==> valgre [10:23] etc. [10:23] nexuiz-data still running on jubany... no significant output in logs/nexuiz-data either... weird [10:23] vila: from how long? [10:24] since 2011-03-01 20:23 utc [10:24] anyone have a feeling about how far back I should port 437003 [10:24] bug 437003 [10:24] Launchpad bug 437003 in Bazaar "Failure to autopack because of 'missing inventories'" [Critical,Confirmed] https://launchpad.net/bugs/437003 [10:24] I was thinking 2.2, but I'm open to suggestion [10:25] spiv's fix was backported to 2.0 no ? [10:25] jam: It varies, this is the Hague dialect === hunger_ is now known as hunger [10:25] jam: is there significant problems if you target 2.0 ? [10:25] it would be nice to get it into 2.0 [10:25] s/is/are/ [10:27] vila: my whole world crashes [10:27] unfortunately [10:27] but I'll see what I can do :) [10:27] jam: I think the main issue is that people keep running into it (I think there was yet another report since yesterday), so if we can target 2.0, we are better prepared to deploy it for all users involved (modulo poolie being able to SRU 2.3/2.2/2.1/2.0 ...) [10:27] jam: huh ? :D [10:27] I'm not 100% sure how stable the code in this area has been since 2.0, it was quite a while ago... [10:28] vila: just being silly. I can probably do 2.0 just fine [10:28] :) [10:28] since we aren't SRUing back that far by default, it didn't seem important [10:28] but I can do it [10:28] I still hope we will be able to SRU 2.0 once we sort out the other ones [10:29] what still has 2.0 that is under SRU, though? [10:29] hardy? [10:29] jam: but if you want to start with 2.2, you could still look at backporting if needed [10:30] jam: hardy is 1.3, but lucid is 2.1 [10:30] karmic is 2.0.. so we may never SRU there... [10:35] I can't see why we would backport anything further back than 2.1, at this point [10:35] maxb: because we rock! [10:36] mostly because that is where the bug started, and we may as well fix it there, rather than backporting [10:37] well, if it doesn't incur any extra effort, good [10:37] See, if you'd just gotten jelmer to do it instead, maxb would have had it done 15 minutes ago :p [10:37] but, if we don't know of any extant distribution that would make use of it, there may be no point (unless it's essentially free to start fixing in 2.0) [10:38] maxb: at *this* point, it looks essentially free [10:38] we can always land and not release [10:38] or skip landing [10:38] etc [10:39] vila: care to discuss the fix. I have 2 options [10:40] 1) See that we have the inventories in another pack file and stop there [10:40] 2) Go ahead and pull those inventories, which will also require pulling in the associated chk bytes pages [10:40] I like the idea of having things all together when reasonable. [10:40] But it does feel a bit like chasing the rabbit down the hloe [10:40] hole [10:41] note that we *don't* pull in the associated texts [10:41] see line 452 of groupcompress_repo.py [10:41] # XXX: We don't walk the chk map to determine referenced (file_id, [10:41] I don't know enough about the details, but I share the feeling that things should stay together [10:45] jam: if the bug (as it seems) is really confined to autopack (a reproducing test would be nice) then (1) seems to be the way to go no ? [10:45] jam: or does it also occur in weird stacked scenarios ? [10:45] vila: it is the minimally invasive form, yes [10:45] vila: it seems to be *caused* by stacking [10:46] but not in the "weird stacking scenarios" sense. [10:46] I ~see [10:46] In normal fetches, we always send the inventory with the revision, so there would be no reason for them not to be in the same pack file [10:46] but with stacking, we may send inventories for revisions we don't send [10:46] also, the suspend/resume features end up creating multiple pack files for one logical pack [10:46] sorry logical fetch [10:48] is it a case where some constraints should be relaxed while the logical fetch is processed or do we end up we several pack files ? [10:48] vila: we end up with several pack files. [10:48] suspend writes it to disk [10:49] in the uploads dir [10:49] resume marks it for final inclusion in the 'packs' directory [10:49] and they get repacked before inclusion in the 'packs' directory as one pack file ? [10:49] vila: no [10:49] they just get renamed into place [10:49] often the first push is huge [10:49] and the second is small [10:54] hmm [10:55] jam: I don't quite get how we end up with missing inventories when we "may send inventories for revisions we don't send"... [10:56] and what do you call revisions in this context === vila is now known as vila-afk-lunch [10:57] vila-afk-lunch: still there? [10:57] ping me when you get back [10:57] jam: I will [11:00] is there a way to change the pull location of a branch you have pushed to LP so bzr pull will just get it from LP without having to specify the location? [11:01] jdobrien: bzr pull --remember ? [11:01] jam? how will that changed the pull location [11:01] jdobrien: bzr pull --remember lp:the-new-place [11:01] ahh [11:02] jam thanks! [11:04] jam I was looking everywhere but there :) [11:04] jdobrien: happy to help [11:06] would "bzr config push_location lp:the-new-place" also work nowadays? [11:07] jelmer: I think you need at least an "=" in there [11:07] it also would end up using 'lp:' each time, and not the expanded url [11:07] not sure what else [11:07] would differ [11:09] jam: ah, right [11:09] so yes, *but* :) [11:39] id=4, tests=34971, failures=2363, skips=3794 [11:39] getting close to that 35k mark :) [11:46] http://samba.org/~jelmer/bzr-alltests.html [11:49] jelmer: that is running against all plugins, or what? [11:49] jam: Against a lot of the plugins: bisect builddeb builder bzrtools cia cvs dbus email explorer fastimport git grep gtk hg keywords loggerhead loom mtn pipeline pqm qbzr search service svn upload webdav xmloutput [11:50] jelmer: mtn? I didn't think the models would be close enough to actually be supported. [11:51] jam: the mtn module is as trivial as the bzr-cvs plugin [11:51] ie it just installs a Prober and tells you "please try mtn fast-export and bzr fast-import" if you try to open [11:52] interesting [11:52] hah === vila-afk-lunch is now known as vila [12:01] jam: back [12:02] (11:55:42 AM) vila: jam: I don't quite get how we end up with missing inventories when we "may send inventories for revisions we don't send"... [12:02] we'll start from there [12:02] Example, Revisions A, B, C, D [12:02] A B C are in the base repository [12:02] D is in the target repository [12:03] "stacked" [12:03] if D is in the stacked repo, then so is the inventory for C [12:03] Say we push this somewhere else that only has A B [12:03] jam: because it's the parent ? [12:03] vila: right [12:03] A => B => C => D [12:04] If we push to somewhere that has A B [12:04] then we will send D rev+inv, C inv. Then suspend, then resume and send C rev [12:04] At which point D + C's inventory are in one pack file, but we may do an autopack just involving C's rev pack [12:04] vila: https://code.launchpad.net/~jameinel/bzr/repack-missing-inventories-437003/+merge/52544 [12:05] If you want a semi-hackish way of triggering the condition [12:05] also, vila, did we decide to copy NEWs entries when doing stable updates to multiple releases? [12:06] I'm always unsure about the state of that [12:06] we stopped duplicating NEWS entries [12:06] since we may or may not do releases in sync anymore, I was thinking to copy the entries [12:06] Notably, 2.0.7 may never see the light of day [12:06] the RM should ensure that any release includes fixes from lower series [12:07] I *didn't* like it when I was releasing 3 branches simultaneously every month [12:07] that is, the fixes known when releasing [12:07] but I'm pretty sure we've backed off on that [12:07] yup [12:07] what I do (as RM these days) is ensuring that lower series have been properly merged up [12:08] there is one merge that is a bit trickier (can't remember if it's 2.1 or 2.2) where you had to make sure you don't include irrelevant news entries [12:17] jam: "The test also isn't a permutation test. It might apply vs most Pack based repositories, but I can't guarantee it." [12:18] jam: how hard would it be to dig a bit more there ? [12:18] vila: harder than I feel is warranted [12:18] vila: especially for a backported fix [12:18] jam: which means 0.92 can still exhibit the bug ? [12:19] I could possibly be convinced otherwise for newer releases [12:19] vila: you mean format 0.92? Uses very different logic [12:19] Oh ! Right [12:19] doesnt try to match Inventories to Revisions [12:19] I'd be fine with a permutation tests for 2.4 only [12:19] hmm [12:20] so you mean only 2a is really affected then ? [12:20] vila: by that specific bug? yes [12:20] jam: great [12:20] at least, I think so [12:20] already approved [12:20] its the only one that really matters, anyway :) [12:21] the bigger question is what happens when 3a comes out [12:21] but since that is indefinitely postponed... [12:21] which means we need some way to express that a test apply to a set of formats [12:22] jam: if you could put these tests in a dedicated class with a comment explaining the issue that would be awesome to start with [12:22] well, they already are :) [12:22] vila: any other comments you want to take back? [12:22] :) [12:22] self.fail() seems sufficient to say "this should never happen" [12:23] yeah, could be [12:23] yeah, got a bit scared by the size of the test at first [12:24] understandably [12:24] I tried to make sure the bulk of things were in "make" helpers [12:24] so you could clearly see it was complex because of setup [12:24] not because of assertions [12:24] I think for such bugs you can't avoid having a complicated setup [12:24] yup [12:24] and I made sure to re-use those helpers for some extra testing [12:24] like real-missing inventories, etc [12:25] yup, may be my "nice tdd there" didn't express enough congratulations :) [12:25] but it's a nice piece you put there [12:26] well, some of it was TAD, but I did make sure to trigger the failure before fixing it. [12:26] A == After ? [12:26] D == before then :D [12:33] Test After Development. I did the first test TDD, I did the "but make sure it still fails when it must" afterwards. [12:34] especially for bugs, I tend to do close to TDD [12:34] since I have something I want to reproduce [12:34] for dev work, it varies, because I don't always know what I'm looking for right away [12:34] yeah, the usual argument ;) [12:34] and I've had a lot of trouble trying to work out performance related fixes and testing [12:35] I don't really buy it because I successfully TDDed on several exploratory works, it means more test refactoring but also gives me more confidence about test coverage [13:17] jelmer: reagrding bug #713240 [13:17] Bug 713240 on http://launchpad.net/bugs/713240 is private [13:18] O_o [13:18] I can't access that page [13:18] ah, neither can ubot5 :) [13:18] jelmer: regarding bug #731240 [13:18] Launchpad bug 731240 in Bazaar Hg Plugin "opening over http in dumb mode fails in selftest" [Medium,Triaged] https://launchpad.net/bugs/731240 [13:19] that's better (first typo after more than a work day and a half... something weird is going on ;) [13:19] jelmer: our HTTP test server supports range requests, not sure what is going on here [13:22] hmm, that's odd indeed [13:24] jelmer: and which test is failing ? I can't reproduce locally with bzr-hg trunk and -s bt.per_branch.test_branch [13:25] jelmer: ha, lazy loading and --start-with interfering ? [13:26] I guess so [13:26] It should be bzrlib.tests.per_branch.test_branch.TestBranch.test_open_containing [13:27] * vila scratches head, even 'bzr selftest bzrlib.tests.per_branch.test_branch' (aka without -s) [13:28] hmm, *really* installing the plugin may help [13:28] indeed [13:32] you mean bzrlib.tests.per_branch.test_branch.ChrootedTests.test_open_containing ? [13:34] Ah, yes [14:08] wtf, BzrBranchFormat4 can be used in a metadir? [14:31] jelmer: bug #731240 is a bug in the bzr HTTP test server ;) [14:31] Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,In progress] https://launchpad.net/bugs/731240 [14:32] vila: ooh, nice catch :) [14:33] painful to track down and quite surprising, but as I commented in the bug report, it's still valid [14:37] well, painful... because I didn't know the bzr-hg and hg internals to be honest [14:38] ah [14:38] jam: do you know if it's intentional that BranchFormat4 also works in meta dirs? [14:40] well, s/works/can be initialized/ === Chex_ is now known as Chex [14:54] jelmer: hehe, look at this (http_server.py line 149): # FIXME: RFC2616 says end is optional and default to file_size [14:55] *He* knew it ! [14:58] jelmer: there was a meta-dir version before knits, IIRC [14:58] so yes, it was intentional [14:58] I'm pretty sure there was a *very* short lived Weave metadir [15:00] jam: it doesn't have a get_format_string() implementation though [15:00] jam: so it's write-only [15:00] odd [15:01] That would be repository Weave anyway [15:01] the Branch wouldn't matter [15:01] jelmer: if it is write-only, then there is no reason to support it [15:01] since it couldn't be read [15:03] ok [15:03] a couple of tests seem to rely on the existing behaviour, but they don't reopen branches after they've been created [15:16] jelmer: then my guess is that it is an accidental by product of permutations and isn't meant to work [15:41] jam: you mentioned yesterday you were happy to see https://code.launchpad.net/~jelmer/bzr/blackbox-upgrade-formats/+merge/52275 land ? [15:42] jelmer: yes [15:42] must have been one of the rejections I didn't catch [15:42] marked approved [15:43] jam: thanks ! [15:47] jelmer: NameError: global name 'RemoteHgBranchFormat' is not defined [15:47] jelmer: can you stop some typo there ? [15:47] jelmer: or tell me where it's defined ? [15:48] vila: fixed [15:48] jelmer: in trunk ? [15:49] indeed [15:49] then I've got a fix for #713420 [15:49] pffft [15:50] bug #731240 (double tyop above, triple if you count the missing 'bug' ;) [15:50] Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,In progress] https://launchpad.net/bugs/731240 [16:00] vila: hmm? [16:00] ah [16:06] * jelmer finishes reading through ~2k failing tests [16:06] jelmer: here is the mp: https://code.launchpad.net/~vila/bzr/731240-range-parsing/+merge/52573 [16:07] I've filed bugs for all the different issues I've encountered, most failing ones are due to missing VersionedFiles.add_lines() implementations though [16:07] jelmer: hehe, that's far too much, better fix the most important one first :) [16:07] /go #pse [16:07] vila: \o/ I'll have a look [16:07] jelmer: what ? you need to read them all to find the most important one ? Where is your crystal ball ? [16:08] vila: I wish the test suite could tell us ;-) [16:09] 5 FAILURES (1 severe, 2 important, 2 minor) [16:09] hmm, good idea ! [16:10] jelmer: here is the mp for that: https://dreamcode.launchpad.net/~vila/bzr/731240-range-parsing/+merge/52573 [16:10] err [16:10] jelmer: here is the mp for that: https://dreamcode.launchpad.net/~vila/bzr/1-dwim/+merge/42 [16:10] hehe [16:14] vila: is "bytes=-" allowed? [16:14] no, let me test that :) [16:14] may any good soul remind me how to create a prefix like lp: ? [16:14] vila: there are two spaces in this line: + self.req_handler = RequestHandler(None, None, None) [16:15] tacone: It's a DirectoryService, you can register a custom one in a bzr plugin [16:15] jelmer: blame my shaking hand ;) [16:16] urgh. do i have to distribute a plugin to all my devs ? :) [16:16] tacone: better than asking them to *write* one ;) [16:16] villa: +1 [16:17] * tacone mispells nicknames [16:17] np [16:17] any other way to shorten a sftp long url ? [16:17] tacone: Well, you'll have to get *something* to them [16:17] tacone: can you elaborate a bit about what kind of aliasing you're after ? [16:17] perhaps bzr-bookmarks can be used for this sort of thing? [16:18] maybe, i'm looking it up right now, is it in the repos ? [16:18] the subject comes back regularly enough that we may investigate how to generalize *something* to the point where you could use it via some configuration [16:19] tacone: yes... lp:bzr-bookmarks ;) [16:19] tacone: There aren't any packages, if that's what you mean [16:21] ok [16:23] who is ADHB? [16:30] jelmer: abentley === zyga is now known as zyga-afk [16:30] jelmer: what is easier in the hg config API ? [16:30] jelmer: Hi. Aaron David Heuer Bentley here. [16:31] abentley: Ah, it's you! [16:31] Heuer and Bentley, talk about a luxury name ;D [16:32] vila: the API doesn't confuse me in Hg :) [16:32] vila: :-) [16:32] jelmer: haha, ok, but that doesn't tell me much ;) [16:35] jelmer: as in : I'd like our new config API to be easy for users and devs alike, so all inputs are welcome and... now is a good time ;) [16:39] is still Olive the supported GUI ? [16:41] well, it's hard to say that there is *a* supported GUI [16:42] tacone: qbzr/bzr-explorer are probably a better choice at the moment [16:42] Olive has been spun off from bzr-gtk, bzr-explorer was intended to support both gtk and qt but has been adopted by the qbzr devs. There seem to be more interest in qbzr than bzr-gtk but both projects are still active, Olive... is a different matter and could certainly benefit from some love... [16:43] i'm taking a look to bzr-explorer, thanks [16:59] jelmer: is https://code.launchpad.net/~jelmer/bzr/weave-plugin/+merge/51301 still reviewable ? (You mentioned BranchFormat4 a bit earlier) [16:59] vila: sortof.. I'm splitting it up further to make it more reviewable [16:59] jelmer: ok [17:00] vila: review of https://code.launchpad.net/~jelmer/bzr/branch4-no-metadir/+merge/52575 would be great though :) [17:00] jelmer: I'm on https://code.launchpad.net/~jelmer/bzr/per-repository-vf-reconcile/+merge/52283 [17:03] vila: ah, cool [17:04] vila: I'm not sure I understand your comment on per-repository-vf - the scenarios should be applicable for all files in this directory [17:05] jelmer: when poolie introduced the .scenarios attribute, the idea was to reduce the distance between the test classes and the parametrization [17:06] jelmer: in your case, ISTM, the distance is too big [17:06] jelmer: if the scenarios needs to be shared, I don't have a problem leaving them in __init__, but they can still be referenced from the scenarios attribute [17:07] jelmer: if they are *not* shared, then I would prefer for them to *not* be in __init__ (for the other submission) [17:08] jelmer: and when I reviewed the first mp, there was only 1 file in the dir ;) [17:08] vila: What do you refer to by scenarios attribute here specifically? [17:08] * jelmer suspects there's a concept he's missing here [17:08] jelmer: see test_http.py for examples [17:08] jelmer: yeah, it's possible you didn't see poolie's work there, it still has to be fully deployed [17:09] I inspired my existing code by bzrlib.tests.per_repository [17:09] jelmer: grep for load_tests_apply_scenarios [17:10] jelmer: roughly: the idea is to define an attribute on the test class instead of defining a specific load_tests function [17:11] jelmer: the implementation proposed by poolie has been working pretty well so far [17:11] there will be a lot of scenarios in this case though, in multiple files [17:14] vila: Do you mean just setting "scenarios = all_repository_vf_format_scenarios()" on each of these classes? === deryck is now known as deryck[lunch] [17:14] jelmer: right, I haven't into the details and maybe your proposal is good enough to land, but if you could have a look at this new organization I've got the feeling that the parmetrization could be clearer === charlieS_ is now known as charlieS [17:15] jelmer: may be, may be not, a common base class could work too, I don't remember if you could easily redefine (and enrich) for a daughter class [17:16] jelmer: as said above, there was only one file for the first mp hence my comment [17:16] jelmer: for the second mp, if the scenarios are not reused elsewhere then put them in the file that use them [17:17] vila: fair enough [17:17] jelmer: mainly the scenarios attribute helps putting the scenarios closer to the tests that use them which is the main point of my comments [17:20] does anyone know if it is possible to allow one version controlled branch inside another version controlled branch? I have a folder structure like /modules and /modules/abc in which I would like to keep the abc a separate branch but also commit the entire modules directory for easier deployment on my we server. When I initialize a branch in the modules directory it ignores the other version controlled folder. [17:20] web server* [17:21] smthomas: you want nested trees which is not implemented yet [17:21] smthomas: the container branch will ignore the contained branch for now [17:22] vila: ok thanks, any idea when nested trees will be implemented (for future reference)? [17:24] smthomas: no estimate for now as the bzr devs focus on other features but it's an highly desired feature nevertheless... [17:24] vila: yes I agree with that as I would like to be able to use it, thanks again for the help [17:25] smthomas: you know about the bzr-upload and the bzr-push-and-update plugins right ? [17:26] smthomas: the above are for deployment [17:26] smthomas: but there are also other plugins that try to address the nested trees feature (and I forgot their name, once *again* !) [17:26] bialix will kill me :-/ [17:27] vila: no I do not, I will have to do some research. I am fairly new to bzr. I have been using it for awhile but not much for deployment yet [17:27] bzr-externals ? [17:28] https://launchpad.net/bzr-externals yeah, sounds like it [17:28] smthomas: you may give it a try too [17:30] vila: what about something like this: http://bazaar.launchpad.net/~jelmer/bzr/per-repository-vf/revision/5688 [17:31] jelmer: exactly ! [17:31] err [17:31] except for the first line in the patch, do you really need to do that ? [17:32] in tests/__init__.py [17:32] I don't think we would discover that test file otherwise [17:32] * jelmer tries [17:33] yeah, without that line we don't run the tests in bzrlib.tests.per_repository_vf.test_repository. Previously the loader.loadTestsFromModuleNames call took care of that [17:34] then may be just a boilerplate load_tests in __init__ [17:34] I realize the per_xxx tests are not *that* regular either :-/ [17:38] oooooh noooo, bazaar-commits@lists.canonical.com thinks I'm spamming ??? [17:38] vila: what about http://bazaar.launchpad.net/~jelmer/bzr/per-repository-vf/revision/5689 ? === r0bby is now known as robbyoconnor [17:39] argh, no, it's even worse ! That's my own ISP !!! [17:39] vila: bazaar-commits@ still exists ? :) [17:39] jelmer: indeed ! [17:41] another bzr-git question, how do you update your import of a git repo? [17:46] chx: running bzr git-import again [17:46] ah! [17:46] tricky. [17:47] and bzr dpush in that directory, right? [17:47] where the shared repo is [17:48] and finally, how you create a new git branch w/ bzr-git? [17:50] chx: "bzr init" will create a new git branch [17:50] chx: bzr dpush in which directory? [17:50] jelmer: do you do bzr init in refs/heads? [17:50] jelmer: i have a directory (shared repo) resulting from bzr-import [17:50] chx: no, just in the root of the repository [17:51] chx: That's a bzr repository, creating something there won't help you get it into git [17:52] chx: What are you trying to do exactly? [17:52] jelmer: many things :) i try to use bzr-git in place of git... :) === seiflotfy_ is now known as seiflotfy [17:52] jelmer: Drupal moved to git from cvs and i tried git and i am ... well. i'd use bzr-git instead. just there isnt much docs. [17:53] Last time I tried bzr-git it didn't have the ability to operate on the bizarre multiple-branches-in-one-place model that git uses [17:54] chx: Contributions in that area would be welcome :) I guess at the moment there are mainly caveats, otherwise it should work like bzr itself [17:54] LeoNerd: it has that capability nowadays, but bzr's UI doesn't actually provide you with the ability to use that yet [17:54] jelmer: ok i will ask questions and write a blogpost for docs. Deal? [17:54] chx: WFM :) [17:54] Ah OK [18:00] maxb: bananas... [18:01] I like bananas. Bananas are good. [18:01] yeah and testables ! [18:01] jelmer: http://ex.privatepaste.com/bd99cc1e46 [18:02] chx: the git:// protocol is anonymous, so using that to push will probably not work [18:02]