[00:02] mwhudson, I have to run off for a while. I need to run some errands I've been putting off. I'll read the backlog when I get back, and finish up the cleaner-url patch. FWIW, it's in: lp:~beuno/loggerhead/zpt.cleaner_urls [00:02] beuno: okidoke [00:02] i should do some non-loggerhead stuff too [00:03] morning [00:06] jelmer: If you haven't gotten an answer, you can use 'hg export' to create a patch-like file.. Not sure about the email part. The patchbomb extension, perhaps. [00:08] Peng, hg doesn't have a bundle-like format that preserves vcs metadata? [00:08] jelmer: 'hg export' does. [00:09] jelmer: The git diff format can store binary data. [00:09] jelmer: Mangled line endings can cause problems though. [00:11] Peng, ah, thanks === mark1 is now known as markh [00:47] igc: where is your stacked loom again ? [00:50] abentley, lifeless: do you know if https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 is now fixed? [00:50] Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged] [00:50] the associated branch is 'trunk', so... [00:52] also, what's BzrDir.clone expected to do when the associated bzrdir is for a loom? [00:54] jml: I know that a hacky fix was applied, so it should be better, but not perfect. The wrong hook will fire. [00:55] I don't know why BzrDir.clone would do anything different when the associated bzrdir is for a loom. [00:55] jml: as abentley says [00:55] jml: works, wrong hook. [00:57] ahh ok. [01:01] hey guys, I have a question about workflow. I'd appreciate it if you could point me in the right direction. Whilst developing a feature in a new branch, it is useful to keep up to date with the latest changes made in "trunk". Why does bzr force you to merge, even if a pull wouldn't have resulted in a conflict? This makes many merges appear in the revision log. Is there a workaround, or am I missing the point? [01:02] For example, if I'm working on project/somedir/*, and the project changes project/otherdir in trunk, that would require a merge from my side. But I'd be quite happy to just rebase my branch on theirs... [01:02] instead of merging, I would then again be able to pull [01:03] If this is all crazy-talk, just point me to the right FAQ, please... [01:03] stefanv: so this is a whole-tree vs partial-tree thing [01:04] stefanv: in CVS each file has its own timeline, so you can 'pull'(update there) and it has to relevance to other files [01:04] stefanv: the same goes for SVN [01:04] stefanv: darcs doesn't really have a timeline, which is why a similar thing works there [01:05] stefanv: for whole-tree systems, like bzr, hg, monotone, git, it doesn't matter which files you edit - concurrent activity requires some action to resolve. [01:05] stefanv: there are different low level tools that can be used, they basically boil down to either /rewrite history/ or /merge the activity/ [01:05] lifeless: the problem is that we see many merge entries in our logs, which seem kind of unnecessary.. we would have been happy to just base the branches off the new trunk, if possible [01:06] rewriting history is problematic - it turns tested code into untested code, it makes collaboration much harder [01:06] Rewriting history just to get an arguably nicer presentation seems like overkill to me :) [01:07] spiv: it worries the developers when they see so many merge messages, but maybe that is just a mental block we need to get over. the idea of a "merge" is still somewhat severe, coming from SVN. [01:07] lifeless: thank you for the detailed answer. [01:08] if merges could take place without conflicts, though, why merge instead of just pulling? [01:09] Because pull is a way to update a mirror of a branch. [01:09] But if you have a branch with independent changes, it's not a mirror, so it cannot have the same history. [01:09] Ah, that makes sense. [01:10] If your branch has no new commits in it, then you can use pull. But then it's not a very interesting feature branch either :) [01:10] Doesn't hg fast-forward? [01:10] spiv: true :) [01:10] stefanv: 'merge --pull' does what 'fast-forward' does [01:11] stefanv: which we put in for folk that enjoy that particular workflow [01:11] stefanv: with respect to merges - merging is what happens when concurrent development takes place [01:11] stefanv: and bzr can't tell that "standard_includes.h" is unable to cause a test failure in "uses_standard_includes.c" [01:12] stefanv: which is why we don't commit it automatically (though you can definitely write a wrapper script if you wanted to) [01:13] lifeless: shouldn't the developer take the responsibility of only merging valid changes in? [01:13] lifeless: bzr can't really protect against that, either way [01:15] right [01:15] all a merge record in the history means is that a developer has done that [01:15] lifeless: is there a way for a developer to hide all those merge records? [01:15] lifeless: i.e. if he wants to say "here is my new feature, but you guys really don't need to know about successful merge attempts"? [01:16] lifeless: or should we just use the --short option for logs? [01:16] It is possible to write a plugin to hide them from e.g. log. They do have semantic value to bzr (to make merge work correctly for instance) [01:16] Launchpad doesn't have a very detailed log display, unfortunately. [01:17] stefanv: out of interest, what does e.g. http://bazaar.launchpad.net/~bzr/bzr/trunk/changes lack that you'd like to have? [01:18] Oh, that's fine. === kiko is now known as kiko-zzz [01:18] I'm referring to the one displayed on the code page. [01:18] Oh, right. [01:19] thumper: ^ [01:19] It basically comes down to this: we need to be more careful about labelling merges with mainline. [01:19] We need to include something like "Merge in MrX's changes to the build machinery." -- to give credit to the developer [01:19] Instead of relying on his name appearing in the "changelog". [01:19] hello [01:20] spiv: https://code.launchpad.net/~vcs-imports/libs/main [01:20] spiv: revisions have a tendency not to appear in that display :) [01:20] yes, we'd like that to be better [01:21] beuno: are you still here? [01:22] mwhudson: if you could implement the snazzy display we see on a tool like olive, that would kick serious ass [01:22] indeed [01:23] that sounds like an .... interesting ... challenge [01:23] we've moved IPython onto Launchpad... so we're in it for the long haul [01:23] one we may even be able to do, but it's a considerable amount of work [01:23] stefanv: Commits with multiple authors (because it's a merge of many revisions) could be displayed much better by Launchpad. I think there's work towards doing that, actually. [01:24] spiv: that's great news [01:24] mwhudson: it shouldn't be *too* hard. [01:24] stefanv: of course, bzr log will still show you all those revisions. [01:24] stefanv: and if you're merging dev in a feature branch, those revisions will allready be credited earlier on [01:24] LarstiQ: yes, but web uis are more interactive, FSVO inter [01:25] lifeless: I agree the trunk log page is really bad [01:25] spiv: no, that shouldn't be [01:26] though i don't think we have enough data in the launchpad db to make a merge sort trivial [01:26] lifeless: recently lots of people have been complaining that their revisions get lost in merges. Not sure why that plays up now. === bigdo2 is now known as bigdog [01:34] About the pull vs merge issue, hg handles it with multiple heads... you can pull even if diverged, but the changes go to a different head. [01:35] I'm not sure whether that's possible in bzr, or if it's even a good idea. [01:35] ToyKeeper: well, that's just keeping a separate branch [01:35] (in bzr terms) [01:38] and in hg terms too :) [01:39] when are those heads merged? [01:39] in hg, when you do 'hg merge' [01:40] (which you normally do immediately) [01:40] right... and only then is it really useful... [01:43] It can basically let you switch between various branches, in the same directory... work on one head for a while, then a different head, without changing directories. [01:45] I get the impression hg has the feature because git has it, but it seems conceptually simpler to have different directories for different lines of development. [01:45] Yes, that sounds like a potential source of confusion. [01:50] I suppose it would be nice for large projects, to avoid having two copies of history, but both bzr and hg have other ways to do that. [01:51] It's also nice to avoid rebuilding large working trees. [01:52] And some tools (eclipse is one I think?) also prefer the absolute path not to change, so to work with those tools it can be more convenient to change one tree in place rather than have many trees. [01:52] So we have "bzr switch" [01:53] It'd be nice if launchpad merge requests used a merge directive instead of a branch. [01:54] thumper: ^ [01:54] ToyKeeper: hello [01:54] It seems expensive to use O(project history) space for those instead of O(patch). [01:54] ToyKeeper: we have plans, cunning plans [01:54] :) [01:54] ToyKeeper: with the new stacking, space will be O(patch) [01:55] thumper: when does that roll out? [01:55] ToyKeeper: but also we are considering being able to email Launchpad a merge directive :-) [01:55] LarstiQ: we are hoping RSN [01:55] At first I was sure I was doing it wrong. :) [01:56] LarstiQ: planned release is 1.2.6 [01:56] Wow, that's much sooner than I thought it'd be. [01:56] ToyKeeper: it is something we have been looking at for a while [01:57] speaking of stacking [01:57] Pieter: done [01:57] thumper: I know it has been discussed much longer. [01:57] LarstiQ: that it has [01:57] LarstiQ: I think we started talking about it seriously in October last year [01:57] thumper: oooh, 1.2.5 is current. Cool! [01:57] can someone explain briefly to me the connection between the branches that igc has been sending to the list and the big bundle lifeless sent yesterday? [01:58] "big bundle" heh heh heh [02:01] ig1: where is your stacked loom again ? [02:02] lifeless: http://people.ubuntu.com/~ianc/bzr/shallow-branch/ [02:02] is there a way to apply a bundle, but to assume that the base is the current tree, instead of the one it came from? === ig1 is now known as igc [02:19] stefanv: why? doesn't merge do what you want/ [02:19] poolie, back [02:25] beuno: I fixed the huge-numbers-of-files things before work this morning [02:25] lifeless, you're going too fast, I can't keep up :p [02:25] * beuno pulls again [02:25] spiv: is there a bzr-svn python trunk in packs around? [02:25] lifeless, I have one locally [02:25] igc passed it on to me in the sprint [02:25] want me to try and index that? [02:25] L [02:25] LWhatever we decide, I think we should at least file a bug for it [02:25] and maybe add some FIXME here and there, so that a newcomer will [02:25] have a hint or two about what is the way we want things to be [02:25] done and don't get puzzled by finding several different ways in [02:25] bah, copy n paste garh [02:25] beuno: yes [02:26] lifeless: http://code.python.org/python/ [02:26] (docs at http://www.python.org/dev/bazaar/ should you need them) [02:28] lifeless, I get: ImportError: No module named transport [02:29] beuno: argh [02:29] beuno: pushing a replacement revision now [02:36] and indexing... [02:38] ah, random progress bars! [02:38] thats the inventory walk [02:39] ~200mb sustained ram usage [02:40] that's as much as it takes to just render a 36k diff with LH :) [02:42] what are you indexing ? [02:42] python tree [02:42] interesting; mine is at 585 :P [02:42] I haven't passed 201 RES at any point [02:44] it sure likes CPU though :) [02:45] are you running 64-bit or 32 ? [02:45] 32 [02:45] I'm on 64 [02:45] I suspect thats the difference [02:45] yeah [02:45] it just jumped to 218 [02:46] but it's not that much of a memory hog [02:46] well it finished [02:46] its tunable easily [02:46] dynamic tuning is harder, because python [02:47] time bzr search Andrew Bennetts [02:47] File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:46995'. Summary: 'No summaries yet.' [02:47] Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'Patches #1298449 and #1298499: Add some missing checks for error' [02:47] File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'No summaries yet.' [02:47] real 0m1.412s [02:47] user 0m0.736s [02:47] * lifeless goes back to merging big branches [02:47] sys 0m0.096s [02:48] oh, I must say, that having written a search engine now, my respect for evolution-- [02:49] beuno@beuno-laptop:~/bzr_devel/test_repos/python$ time bzr index [02:49] real 10m42.939s [02:49] user 10m9.302s [02:49] sys 0m3.868s [02:49] 4 seconds to search a similar corpus, *in C* [02:49] * mwhudson wonders about spotlight hooks on os x... [02:50] lifeless, 0.5 to search random terms on the python tree. *very* cool :) [02:50] * beuno goes tackle the nice-url LH branch === bigdo2 is now known as bigdog === rockstar_ is now known as rockstar [03:26] beuno: so i think bits and pieces from paste will probably be sufficient to make a wsgi app version of loggerhead [03:26] i think what's in loggerhead will become two wsgi apps though [03:27] one that displays a single branch (replacing BranchView in the current code) [03:28] and another that has a browse branches view and dispatches branches to the former app as defined by loggerhead.conf [03:28] (for compatibility if nothing else) [03:28] sounds sensible [03:29] I'll look into what it will take to replace cherrypy for paste's bits, unless you where planning on doing that [03:29] except aaaaaaaaaaaaargh [03:29] oh, hm [03:30] * beuno hides [03:30] oh phew [03:30] i thought for a moment there that paste shared cherrypy's insanity about %2F's in urls [03:31] ah, that would close a bug we have laying around [03:31] indeed [03:31] that bug is one of the two reasons i want to get rid of cherrypy [03:31] (it breaks browsing bzr-svn imports) [03:32] (although the cleaner-urls branch will help there too) [03:32] ah, right, I hadn't thought of that [03:32] the other is that there's no way of distinguishing _ and . in urls [03:32] so if someone registers branches called foo.bar and foo_bar in launchpad, you'll only be able to browse code to one of them [03:33] that sounds stupid. That's cherrypy screwing up? [03:33] yes [03:33] its a feature! [03:33] the %2f thing is probably stupider fwiw [03:33] %2f is at least a standard [03:34] yeah, . _ is odd [03:34] why would it think it's the same???? [03:34] or do I not understand the discussion :P [03:34] lifeless: no, that foo%2fbar is the same as foo/bar makes sense [03:34] lifeless: however with cherrypy foo%252Fbar is the same, too [03:35] oh! [03:35] hmm [03:35] beuno: cherrpy replaces . with _ because it does url traversal with getattr [03:35] try %252f%25.%25. [03:35] ah, ew [03:35] (and escape dot, forgotten the asc() value [03:36] try %252f%2546%2546 [03:36] see if you can escape :) [03:36] (double escaping is a great way to have bugs) [03:37] so . and _ for traversal its nuts [03:37] Out of curiosity, why does URL escaping have to be user visible at all? [03:37] if you are going to escape, escape properly [03:37] lifeless: doesn't seem to work [03:37] * AfC is presently doing a `bzr push` and I must admit that seeing [03:37] lifeless: but i don't really want to think about it [03:37] mwhudson: minor relief; I'd want to look at the code though TBH [03:37] Using saved location: bzr+ssh://afcowie@master.gnome.org/home/users/afcowie/public_html/bzr/gtk%2B/trunk/ [03:38] seems ... less than ideal [03:38] AfC: in the general case a url can be in any encoding [03:38] AfC: e.g. that could be in big5 [03:38] lifeless: the code is like this: [03:38] # Decode any leftover %2F in the virtual_path atoms. [03:38] virtual_path = [x.replace("%2F", "/") for x in virtual_path] [03:38] Um, if you say so. [03:38] AfC: the short story is, its a bug in std66 [03:39] they could have said 'its utf8', instead they recommend that providers (e.g. your server) use utf8, but consumers are told 'it is opaque' [03:39] All I know is I wrote "gtk+" and know that the directory I am in is named "gtk+" and the one I am pushing to is named "gtk+". [03:40] I'm kind of surprised + is being escaped, offhand [03:40] I'd need to check the BNF [03:41] AfC: thats because you're on linux going to linux, and all the systems are running locales whose language is one where + maps to 2B. [03:41] AfC: it can easily get extremely feral [03:42] still don't know why %2B has to be shown to a user. [03:42] the options are: [03:42] - the url (7-bit data, safe to present) [03:43] - the decoded url (8-bit data, unknown encoding) [03:43] while i'm whinging about loggerhead, why in the world is http://bazaar.launchpad.net/~mwhudson/pydoctor/dev/changes/1111 a 500? [03:43] - use heuristics on the decoded url to get a unicode string) [03:43] * mwhudson goes off to do more useful things [03:44] running full tests on this merged stacked branch now, first thread [03:44] My locale is en_CA.UTF-8. That should be more than sufficient to present characters like ' ', '+', and '~'. [03:45] but its not your locale that the url is it [03:45] is *in* [03:45] its in the locale of the process of the remote server [03:45] Just seems it would make for a nicer UI for mere humans. Bazaar likes to be good at that sort of thing, so I hear. [03:45] *at best* [03:45] indeed, and I raised this on the http wg list [03:45] backwards compatibility I hear [03:47] AfC: I'm saying I would like to do better, but we also try to be correct, and there is a tension here - some things are harder than others [04:00] mtaylor: ping [04:17] mwhudson, sent the clean-urls patch [04:17] at some point, I'd like to fit in a good week or two of work to just cook up tests [04:18] ah yes [04:18] that would be really really nice :) [04:19] for which, btw, we have one failing in trunk [04:19] ah dammit [04:19] it's the diff truncation one isn't it? [04:19] yes :) [04:23] aaaand, I'm off for today [04:24] beuno: gnight [04:24] mwhudson, let me know if you need any changes to the clean-urls patch. I'll check back in a few hours [04:25] beuno: the navigation links still use ugly urls [04:25] but i like it :) [04:25] lifeless, night! I've been thinking of several ways to tackle the re-indexing problem, so I may give it another shot if I get my hands on some free time [04:26] mwhudson, argh, I forgot to pass that on from my first branch [04:26] I *really* need to clean up my LH branches [04:26] beuno: yah, my lunch at the moment [04:26] beuno: I'm actually just about to do it once I finish putting everything into single packs [04:27] lifeless, ah, cool. I'll keep my eye on it, and use that time to get it workin in LH :) [04:27] beuno: and clicking the 'browse files' link in the annotate view breaks [04:27] beuno: I'd love to have bzr-gtk/bzr-eclipse/loggerhead start having use of it [04:27] beuno: users -> drive interfaces [04:28] * igc lunch [04:28] mwhudson, that's odd. I didn't touch that... let me poke at it [04:29] ah, that's why it breaks. I didn't touch it :) [04:29] you took the clear=1 out [04:30] yeap [04:31] I'll do another pass at changes against trunk [04:31] * Verterok looking if eclipse have a extension point for the search actions [04:32] beuno: but thanks heaps for doing this :) [04:32] mwhudson, glad to [04:32] I hate the way we handle URLs though [04:33] we shouldn't have to explicitly have to tell it not to drag the values... [04:36] yes [04:37] lifeless: as far I can see, bzr-search integration into bzr-eclipse don't look too difficult :D [04:37] Verterok: cool [04:38] mwhudson, sent the patch with the fixed clear=1. I'll get the navigation links working tomorrow, as my patch doesn't apply cleanly, and I'm already 20 minutes late :) [04:38] * beuno waves at Verterok [04:38] if I can get some spare time, I'ld try to get a working prototype [04:39] * beuno -> out [04:40] beuno: bye [04:40] g'nigth beuno [04:41] Verterok: that would be pretty damn cool :) [04:42] lifeless: indeed :) [04:43] I'll try to do it as an extension to bzr-eclipse...so it 'll be completely optional [04:43] yeah, thats a good idea ;) [04:45] and 'll make my life a lot easier than trying to include it in bzr-eclipse :) [05:10] lifeless, spiv, i'm going to talk to spiv then jump into reviews [05:10] starting with spiv's resubmitted test patch then the big mutha [05:15] lifeless: do you want to hear about some typos in BUGS in bzr-search? [05:16] "does not component components." and "does not component components." [05:16] no [05:16] "requires nearly 200B of memory" [05:16] is MB mega bytes or bits. I forget, continuously [05:17] bytes, according to teh wiki [05:23] anyhow thanks done and pushed [05:23] poolie: igc: the "Development1" patch is the one that needs to change to support stacking on VersionedFiles [05:25] thanks lifeless [05:25] (and thus the one I would hesitate to land until thats done) [05:25] I'm writing the mail I promised now [05:45] lifeless: easy mnemonic: "B" is bigger than "b" [05:46] I'll try [05:46] :) [06:47] Re Loggerhead templates, what about Jinja? Or Jinja2? It's not tree-based, but it is supposed to be fast. [06:49] mwhudson_: Eek, lp:loggerhead doesn't use packs? [06:50] Peng: no, haven't got around to upgrading it [06:50] mwhudson_: bzr upgrade sftp:// do it now :P [06:51] jinja made my eyes bleed on an 0.1 s impression [06:51] lifeless: on *my* connection after 17:30 ? [06:51] yeah, its a small branch [06:51] * Peng just spent almost 5 minutes pulling new revisions over http. :P [06:51] kick it off and forget about it [06:51] Peng: one of them was huge i suspect [06:52] the zpt-templating merge merged over 100 revisions [06:52] or better yet, screen + devpad [06:56] lifeless/Peng: done [06:58] :) [07:01] Also, my copy had a few inconsistent parents that reconcile can fix. [07:05] Peng: i reconciled trunk too, thanks for the pointer [07:07] :) [07:07] (from a machine in the data centre :)) === mwhudson_ is now known as mwhudson [07:09] Heh, that's cheating. :P [07:13] i'm reading igc's "Development1 format" [07:14] poolie: thats the one I'm now editing [07:14] poolie: its the one that has to change [07:14] lifeless: just a quick hack, but is a proof that can be done :-) http://guille.beuno.com.ar/images/bzr-eclipse-search-fullscreen.png [07:15] Verterok: oh man, that rocks [07:17] Verterok: would you prefer to do hit summaries yourself? [07:17] Verterok: e.g. do you want a minimal output of just the keys, or do you want the humanesque output it generates at the moment [07:18] Verterok: *nice* [07:18] Verterok: excellent place to put it. [07:18] I told you about those slanty tabs, though :) [07:18] btw, at my lunch I stabilised the disk format [07:19] its now unlikely to change until major feature changes - like extreme scaling work, or phrase searching, that sort of thing [07:19] lifeless: I was planning to write a xml output so I can integrate it more easy [07:19] Verterok: that would be lovely. I'd be delighted to include that in the plugin [07:19] Verterok: either as a separate command or an option [07:20] lifeless: great. so, that's my next step [07:21] I'm calling it a day for /work/. been paging back in stacking and my mind has melted [07:22] lifeless: I'll draft an xml format and send it to the list [07:22] cool [07:22] I would suspect that only returning the document keys is most appropriate [07:22] your existing bindings for getting file texts and revisions and so on should be more than adequate to generate summaries in eclipse itself [07:23] but you know more than me about that; so please feel free to specify what you'd like most:) [07:23] actually, the current bindings call bzr [07:24] but the upcoming xmlrpc service that should be a lot easier [07:24] s/but/but with/ [07:24] exactly [07:30] lifeless: keys == revid, I'm right? [07:31] Verterok: see DESIGN [07:31] Verterok: ('f', FILEID, REVID) for instance [07:31] ok, thanks! [07:31] is a file hit at a particular revision id [07:31] ('r', '', REVID) is a revision hit === gour is now known as gour_away [07:32] I'm slowly getting it :) thanks [07:34] I'm off for today [07:34] * Verterok heading to bed [07:34] seeya [07:36] night === mwhudson__ is now known as mwhudson [09:35] hi there [09:35] I have two repos: A & B with email interaction only. A is at rev 3, B was at rev 3 but now is at rev 7. How do I create a bundle to update A to rev 7 from B without access to A? [09:36] * igc dinner [09:38] cd B && bzr bundle . -r 3..7 ; doesn't cut it because there is nothing much in the bundle since bzr says: well I have the files why put them in the bundle? [09:46] Kinnison: have you seen bzr-search? [09:48] lifeless: I've not, is this your new indexy thingy for bzr? If so, what is it meant to do? [09:48] (I saw your blog posting about databases but unfortunately couldn't come up with anything useful) [09:49] Kinnison: https://launchpad.net/bzr-search [09:49] Kinnison: enjoy [09:50] * Kinnison has been following the threads about stacked branches with interest [09:50] Hmm, bzr-search looks amusing, but I can't think of anything particular to do with it right now [09:51] * Kinnison writes it on his white-board to think about [09:51] sounds interesting, where might I find a summary on stacked branches and where things are up to? [09:51] Kinnison: its a replacement for bzr log --message, bzr grep, amongst other things [09:51] Kinnison: also annotate [09:52] Kinnison: I've been thinking about the annotation problem for a bit, and I think annotate is just a very crude search [09:52] hmm, I guess [09:52] * Kinnison needs coffee before he can think about this in detail [09:52] :) [09:52] * Kinnison goes to see if the machine has finished making black heaven [09:58] lifeless: any specific bzr requirements for the plugin? [09:58] nah [09:58] I mean, I've only tested with .dev, but its darn generic [09:58] * Kinnison will update his .dev anyway [09:59] coo, branching from launchpad requires SSH [10:01] * Kinnison removes the air-gap firewall from between his PC and his SSH keys to try again [10:01] nah, its just because it knows you [10:01] if it didn't it would do http [10:02] pity it doesn't either fallback [10:02] s/either/ [10:02] I believe there is now a bug open [10:02] heh [10:02] * Kinnison wonders why his key hasn't mounted [10:03] not enough ponies [10:03] it's as though hal is not responding [10:11] Hi, I have a little problem with "bundle"... [10:11] I have the branch of a friend locally (call it X) and i merged from him into my branch (call it Y) [10:11] then I did some changes to my branch, now I want to send him the changes... [10:12] sincerely from the docs I don't understand what the submit and public branches are... :( [10:12] lifeless: I've decided that my best bet for trying this search tool on a respectable codebase is to make a branch of one of our projects at work [10:12]