[00:07] heya poolie! [00:08] knittl, heh, ingenious [00:12] beuno: well, it worked fastest :> [00:12] and so i made sure nothing is left [00:15] knittl: bzr clean-tree --ignored [01:02] Good morning. [01:06] hi there spiv, lifeless [01:11] spiv, would you care to give a second opinion on https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/ [01:18] poolie: sure [01:48] poolie: the apport one might be usable [01:51] lifeless: apport what? [01:52] it has a dup detection demon [01:52] for detecting things with the same backtrace [02:31] so, spiv, what do you think? [02:31] * poolie is going to see about getting scriptrunner to test interactive ui stuff [02:50] poolie: comment added [02:57] thanks for the review, and i think that's a nice statement about kwargs [02:57] i'd almost paste that into hacking [02:57] actually i will paste that into hacking [02:58] Ok :) [02:58] It took me a few goes to get my thoughts on kwargs reasonably clear. [02:59] yes, it's pretty much what i was trying to say [03:49] Hi folks. Just insalled bzr on the olpc-xo-1. When I try running bzr, I get ""bzr does not support python -OO." What did I do wrong? [03:55] grettke: bzr 2.2 should work with python -OO [03:56] It seems a bit unusual that bzr would be installed to be run with python -OO by default, but I guess it's an attempt to avoid wasting space on the XO. [03:57] grettke: how did you install bzr? As a workaround, you can probably do "python /usr/bin/bzr", although if there are only .pyo files and no .pyc files it could be quite slow. [04:02] I did a yum install bzr. [04:03] Sounds like a bug in the rpm package, then :/ [04:03] oh ok, good to know, thank you [04:03] But it wouldn't matter with the current release of bzr, which should work fine in those conditions. [04:04] (And thus also allow the space saving that -OO provides) [04:04] (And memory saving as well.) [04:04] On most systems I'd say those wouldn't matter, but they probably do help on the XO :) [04:28] is it just me or does lp-propose fail if there's already a proposal for the branch? [05:18] spiv, where was your testdoc branch? [05:19] poolie: it's in trunk now [05:19] oh, just lp:testdoc? [05:19] poolie: (also, jml made me the maintainer) [05:20] i like the idea of using it to review what i changed [05:20] tag :) [05:28] wow, very nice [05:29] Hooray :) [05:29] * poolie resolves to make his docstring slightly better [05:29] vila tells me it's unreadable with a light-background terminal ;) [05:30] :/ [05:30] that's such a mess [05:30] i mean it's probably true but it's a shame unix lets you say "yellow" when you want "a bold contrasting color" [05:30] Yeah. [05:31] i guess he could write a formatter that either uses just bold/underline/etc, or that uses emacs to rewrite stuff into its own face markup [05:31] actually you could write the whole thing inside emacs quite well [05:31] i'm kind of surprised jml didn't [05:31] Yes, for interactive use the editor is in a way a better home for it. [05:32] I think perhaps jml wasn't thinking of using it interactively initially (given that the original output format was Moin markup). [05:33] Also I can imagine writing elisp to invoke Python to do fiddly introspection might trip some "that's too gross" thresholds... [05:34] i probably wouldn't use real python introspection, just regexps to find the methods and docstrings [05:34] but i'm glad it's standalone, since i no longer use emacs [05:34] much [05:37] I think ideally it wouldn't use introspection, but it certainly makes it easier to write. [07:37] hi all ! [07:37] woohoo, connected to pratchett (.freenode.net) The day will be fun :) === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/ [07:49] hi [07:52] hmm, is it me or is lp using a new font in same places ? (the mp links at https://code.edge.launchpad.net/bzr/+activereviews for example) [07:52] bialix: _o/ [07:53] vila: the ubuntu font? [07:53] vila: \o_ [07:53] lifeless: hehe, looks like so to me, the funny thing is that I just installed it myself ;) [07:54] vila: thats why you just noticed. [07:54] lifeless: haaa, you mean the font change is older ? When did it occur ? [07:55] 2 weeks I think [07:56] lifeless: wow [07:58] lifeless: haa, right, I see the font *because* I installed it... [08:14] morning all. [08:20] see from planet debian Robert's done an interesting post on what he's been up to [08:20] I meant to edit it more, but it escaped due to wordpresss [08:21] > Bazaar is a tool anyone can install locally [08:21] > Launchpad, by contrast [08:21] is a tool no one can install :) [08:21] hah [08:23] jk [08:30] vila, are you up? [08:30] is there some trick about matching blank lines in test scripts? [08:30] poolie: yup ! === beaumonta is now known as abeaumont_ [08:31] * bialix waves at poolie [08:31] poolie: hmm, ring a bell... [08:31] hi there bialix [08:31] new qbzr release hits the street [08:32] I vaguely remember that initially blank lines were ignored when there was no '$' prefix for commands... Not sure we fixed that now that the expected output lines don't have a prefix [08:32] poolie: what do you observe ? [08:32] poolie: An expected output blank line not respected or detected or... ? [08:33] there's a blank line in the output [08:33] it seems to be a bug: by the time we run the checker, it's not in the 'expected' variable [08:33] poolie: check http://stackoverflow.com/tags/bazaar/info ; is it ok for you? [08:34] looks good [08:35] did you just set that up? thanks [08:35] actually, yesterday [08:35] I've got enough bazaar karma for this [08:36] ddaa asked me to do so... [08:40] poolie: right, so I think my bell was right, want me to look at it ? [08:41] no it's ok, i think i see it [08:41] poolie: bzrlib.script.py line 87 [08:42] yeah :) [08:42] just working out what level to test that at [08:42] poolie: right, and line 112 smells like an additional test would be good [08:42] i put up a branch ~mbp/bzr/script, that tests user interaction [08:43] poolie: like... test_empty_line_is_ignored ? :-D [08:43] exactly [08:43] i think in some contexts it should be ignored [08:43] i guess only at the start of the document [08:43] poolie: but I think this one should be kept... yeah, you got it [08:44] i.e. output can exist if a command as been seen, otherwise, just ignore [08:46] so as simple as just saying, we'll ignore one initial blank, but no more? [08:46] at the _script_to_commands level? === mthaddon` is now known as mthaddon [09:04] poolie: lp:~mbp/bzr/doc approved if you remove the 'I think' occurrences, I don't think we ever say 'I' in these docs ;-p [09:05] "I don't think we ever say 'I' in these docs" <- maybe you should add that to the docs [09:06] -lol- [09:06] mgz: my man ! Can you have a look at your mps ? There are some tweaks, but otherwise you have several you can land [09:07] yeah, I'm short news again aren't I? [09:07] hehe [09:07] probably [09:07] I'll add what's lacking and push. [09:07] mgz: s/I don't think// applies to your remark :) [09:08] when you next poke babune vila, lifeless has released a new pyjunitxml version. [09:08] mgz: already done, but thanks for the heads-up and thanks to lifeless for the upgrade ;) [09:09] ...you're always ahead of me [09:09] I try to avoid running private branches for babune or I lose... track ? my mind ? my sanity ? [09:09] mgz: not at all, just following closely instead :-p [09:10] mgz: ... which may mean I'm ahead when you stop :D [09:13] pqm has news merge on right? otherwise I'm going to conflict horribly here. [09:14] vila: proposal updated [09:15] vila :) [09:15] well, it was kind of quoted [09:15] but not very clearly [09:16] poolie: sure, but lp doesn't show any changes yet, you've pushed right ? [09:16] wow, I'm already in love with the new Ubuntu font :) [09:16] oh i meaont the scripts one [09:16] did it change again? [09:16] ha [09:17] poolie: ok, wasn't there yet [09:17] do you think that's a reasonable position about string interpolation? [09:17] "args are split in to words" ? into ? [09:19] poolie: hmm, I really dislike the idea of removing the first and final line [09:19] """\ works great for the first one [09:20] vila, and you can do the same for the last one [09:20] it just seems unfortunate to make every caller type that [09:20] especially because it's meant to be an easy way to get good tests, and because i don't think tracking them will ever be useful [09:20] they shouldn't need that if we ignore the first one (but take care of it if we need error reporting with correct line numbers) [09:21] your note about the comment handling is right though... [09:22] oh, so you're saying you don't mind ignoring them, but you don't like the implementation of trimming the list [09:22] because it will change the line numbers? [09:22] well, it will always be impossible to distinguish a comment *preceding* a command, from a comment in the expected output of the *previous* command [09:23] yes, I think it's fine to ignore the first line if it's empty (while keeping track of line numbers) knowing that anal script writers can use """\ [09:23] but I think we shouldn't ignore the last one until someone encounter problems with it (which hadn't occur yet right ?) [09:25] it does happen [09:25] and for the comments, well, the only robust solution I can think of is to allow \# when you want to use it literally [09:25] now that i don't ignore all blank lines, a bunch of tests fail [09:25] """ [09:25] $ echo foo [09:25] foo [09:25] """ [09:25] fails [09:26] because '\n'.split(that) has a '' at the end, after the last newline [09:26] rhaa, bogus split [09:26] Trim leading and trailing blank lines? [09:26] a bit surprising hey [09:27] that's what i'm doing [09:27] Or use """\ ;) [09:27] yes, but i'd rather write the trim once, not \ a hundred times [09:27] especially because the message is confusing if you miss it [09:28] poolie: you have 'if line == '': continue' indented, is that intended [09:28] wow, look mom, no typo ! [09:31] poolie: and the tweak in _check_output looks suspicious too [09:40] the indenting is actually intentional [09:41] it's a somewhat misleading diff [09:41] we want to skip lines that are blank only because they contain a whole-line comment [09:41] why suspicious? [09:42] poolie: yup, I'm digging [09:42] that's the change i was originally trying to make :) [09:42] so the interaction test works [09:42] test_confirm_action [09:42] needs it [09:43] is that because test_confirm_action doesn't require that the user type ? [09:44] no, it's because bzr doesn't write out a \n at the end of the prompt [09:44] it leaves the cursor there and the user presses enter for us [09:45] ouch, that's "expected output does not end with \n', ok [09:45] right, that's what you say in the comment :) [09:46] almost [09:49] isn't that nice? :) [09:54] then i can pop back one fram [09:55] poolie: right, it's not clean but 100% DWIM [09:55] so my goals, which i suppose are yours too [09:55] are that it's easy to use [09:55] poolie: what about http://paste.ubuntu.com/492989/ ? [09:55] when it fails, gives a decent message [09:55] and as much as possible lets you be precise if you want to [09:56] poolie: totally, the alternative would be to allow specifying an expected output *without* a final new line which means rewriting _script_to_commands for a little benefit [09:56] vila so it seems like the only actual difference in behaviour there is that you tolerate multiple leading blank lines [09:56] poolie: overkill [09:56] which does not seem useful to me [09:57] try putting a several lines long comment at the start [09:58] ok, let's add a test for that [09:59] that works [10:00] and an empty line after the opening comment ? [10:00] http://paste.ubuntu.com/492991/ [10:01] vila i'm not convinced that should pass [10:01] istm letting people have a leading """ with no \ is useful [10:02] but letting them have arbitrary blanks is not actually helpful [10:02] and may get in the way of precision [10:04] poolie: no, failing because they forgot to be precise before their first command is just annoying them for no good reason IMHO [10:06] in _script_to_commands, the split is the bulk of the scanner while the loop is the parser, the comments are scanned in the loop to finish the scanning, and the parser should really kick in when the first command starts, but well, that's not so important, it just feels cleaner [10:06] but the comment I deleted is obsolete and misleading now [10:08] well cleaner and respecting newlines which del doesn't... [10:09] anyway, don't spend time on it, this will matter more if/when we implement error reporting with linenos at which point whoever does it can fix it [10:12] jml: so, testtools MP, I gave feedback, you seem undecided? [10:15] lifeless, jml: As a data point, I came across 'a' and 'n' *this* wee-end and... found it akward [10:15] week-end I don't even know what wee-end could mean... [10:16] vila: EPARSE [10:16] good :) [10:16] I don't know what 'a' and 'n' you mean [10:16] yeah 'b' :) [10:17] at least this typo reveals my lack of understanding, I don't know what it's about so I can't type it properly :) [10:17] vila: I'm still lost [10:18] lifeless: I encountered 'a' and 'b' in assertEqualDiff and thought: "Wth ? Why not 'expected' and 'actual' ?" [10:18] oh right [10:18] yes [10:27] lifeless, yes. [10:27] lifeless, I'm otp atm. [10:27] hello jml! [10:27] jml: yes [10:27] poolie, hi [10:27] welcome back (if you are) [10:27] jml: we can talk about it tonight/tomorrow if you want [10:27] vila i'd kind of like to just merge this [10:27] lifeless, that'd be good. [10:27] that particular problem might be confusing but it hasn't bit me yet, anyhow [10:28] bug 636930 sounds familiar [10:28] Launchpad bug 636930 in Bazaar "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636930 [10:29] ah bug 513432 [10:29] Launchpad bug 513432 in Launchpad Bazaar Integration "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 13, heat: 23)" [Critical,Fix released] https://launchpad.net/bugs/513432 [10:30] spiv, if any, it looks like that has regressed in 2.2? [10:31] 633915 is the same bug and also new. [10:33] and 635874. [10:35] all of them involve launchpad, so the regression might be that side rather than in 2.2 [10:36] poolie: as in: "Thanks for review, but still" ? :-D [10:36] grr, %2Bbranch still ? [10:36] yes, "but still" :) [10:37] i feel like that's enough of that particular yak for today [10:39] poolie: ok, I've shelved my patch and I can trivially break your test, that's good enough :) [10:40] poolie: moreover I get a "SyntaxError: No command for line ''" which is a perfect case to implement better error reporting with line numbers :-D [10:44] yeah that would be higher up my list [10:44] also there's something strange happening with ellipsis [10:45] I triggered the elusive bzr: ERROR: Tree transform is malformed [('missing parent', 'new-1')] [10:45] lifeless: hmm, with bzr itself or builddeb ? [10:45] with bzr [10:45] 2.2b3 [10:46] rev 5340 [10:46] I had added a directory and files in the dir, and I did shelve --all [10:46] that's a bug then (all MalformedTransform are :-/) [10:47] oh, shelve... [10:47] or... did you have .pyc files there ? [10:47] ignored files yes [10:47] foo~ - editor backups [10:48] oh, wow [10:48] sounds like you have an idea about whats going on; perhaps you could file the bug ? [10:48] lifeless: can you try again with lp:~vila/bzr/323111-orphan-non-versioned-files ? [10:48] an actual bug, not a test suite bug [10:48] but not a very big one [10:48] vila: i will tomorrow [10:48] lifeless: ok, waiting for your feedback then [10:48] vila: you could try it yourself :P [10:48] vila: trunk, and then your branch [10:51] lifeless: yeah right :) I'm busy fixing my branch.conf files with lp spitting bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ urls everytime I create a new bzr branch :-/ [10:52] vila: you might like to file a bug on that [10:52] its good that private branches are supported, but its a bit annoying [10:52] lifeless: there isn't already one ??? I thought you mention tim related to that when I mentioned it... friday ? [10:52] I did [10:52] have you communicated with him about it though? [10:53] no, I thought you and I were already discussing it, rats, it's a bad bug [10:53] lifeless: should I file against lp or lp-code ? [10:53] ok, and now i get to fix the n-1th yak [10:55] lifeless: oooooh, but the urls work... [10:56] no need to fix my branch.conf files (I get fooled in a particular setup) [10:57] hmm, fooled twice even, if they work today, the problem I encountered friday was either transient or fixed since [10:58] lifeless: so bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/ will now always point to the dev focus right ? [11:00] I don't know. [11:00] I guess. [11:00] vila: yes [11:00] and anothe bug [11:00] :!bzr shelve --all debian/python-fixtures.install [11:00] Selected changes: [11:00] -D debian/ [11:00] -D debian/python-fixtures.install [11:00] bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-2'), ('missing parent', 'new-2')] [11:00] (filed) [11:01] mwhudson_: thx [11:11] poolie: still here? [11:14] hi, yes, though not for long [11:14] https://bugs.launchpad.net/bzr-website/+bug/636961 [11:14] Launchpad bug 636961 in bzr-website "www.bazaar.canonical.com URL does not work (affected: 1, heat: 6)" [Undecided,New] [11:15] really [11:15] it should [11:15] thanks [11:15] i can't fix it but i'll ask [11:15] so far I'll use URL without www. [11:16] good idea [11:26] ok good night all [11:38] poolie: yes, bug 636930 did sound familiar, thanks for finding the bug it may be a regression of [11:38] Launchpad bug 636930 in Bazaar "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 3, heat: 26)" [Critical,Confirmed] https://launchpad.net/bugs/636930 [11:38] I'll look into it tomorrow if no-one fixes before then. [12:16] poolie, good night. we should have a chat some time. === Meths_ is now known as Meths === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [14:28] 'bzr remove --keep file.php' keeps the file locally but removes it from repository. Is there a way to have it removed from repository but it when the repo is pull within a branch the file file.php is not removed within the branch [14:29] I know it also needs adding to the .bzrignore file === Ursinha-afk is now known as Ursinha === mbarnett` is now known as mbarnett [15:44] I'm looking for a way to create a shared repo system that allows for devs to have their own branches in the shared repo, but not have write access to a specific branch, for example, the trunk. what's the best way to go about doing this? [15:45] I basically want the space saving abilities of the shared repo (or similar) but need a gate keeping sort of system. I'm the only one who should have commit access to the trunk. Is this possible? or do I need the trunk to be in a separate repo? [15:45] You'll need everyone to have write access to the repository. You could enforce some application-level constraint on people who can change a branch tip [16:01] what's the quickest way to see what repo a branch comes from? (ie where all the rev info is stored) [16:02] bzr info ? [16:02] bzr info on a branch does not tell me where it's repo is located [16:06] rubbs: maybe have a look at stacked branches [16:06] they were designed for this kind of use case: [16:07] space saving of shared repo, without giving everyone write access to everything [16:08] http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html [16:08] maxb: ddaa thanks. I'll take a look at stacked. [16:09] Feedback from a satisfied customer on a proprietary project I'm working on that uses bzr: "`bzr merge --uncommitted --force --interactive`s. Neat." <-- the commenter is generally a die hard svn/centralized VCS traditionalist. [16:11] separatists of the world, unite! [16:11] splitter! [16:11] Hmm... seems like binding to a stacked branch could cause some problems. [16:13] generally, it's better to enforce this kind of constraint by policy, or to deal with the additional disk usage of having multiple independent repos [16:13] ddaa: yeah I htink I'm going to do that later. We would have the policy and I do trust the devs here, but I want that safety net if possible. [16:13] I think I'm going to have a dev repo and a release repo [16:14] disk space is cheap ;) [16:15] stacked branches were designed for launchpad, which has a relatively unique set of constraints and level of control. [16:18] hi Kinnison. Do you really, really hate the Romans? [16:21] * ddaa goes out to look at the bright side of life [16:33] rocky: Yes, it does, unless the repository is implicitly located within the branch bzrdir itself === khmarbaise_ is now known as khmarbaise === BasicPRO is now known as BasicOSX === zyga is now known as zyga-dinner === beuno is now known as beuno-lunch [17:32] can anyone help me figure out http://pastebin.ubuntu.com/493200/ ? the tarmac branch tests are all failing with this error in the PPA package builds. and rockstar and others seem to get the errors when running the tests, however, i am unable to get the errors to occur on my system. [17:33] * rockstar bets jam can help. [17:33] He is smart. [17:34] rockstar, dobey: starting with bzr 2.2 we require a configured username to commit, because we had a lot of problems with people forgetting to enter it, and then getting committers they didn't want [17:34] for test suitse [17:34] the bzr TestCase sets BZR_EMAIL as part of setUp() [17:35] dobey, we should be using the bzr TestCase in those examples. [17:37] ah [17:37] hmm [17:38] TestCaseWithMemoryTransport? [17:38] also, i'd still like to know wtf i'm not getting the issue while everyone else is === Ursinha is now known as Ursinha-lunch === deryck is now known as deryck[lunch] [17:42] dobey: do you have the env variable set already? [17:42] Are we any closer to a bzr book getting released? [17:42] again bzr's base TestCase clears out the environment variable while running [17:43] I just double checked the code [17:43] bzr's TestCase has a "_cleanEnviroment" function, called from TestCase.setUp() [17:43] which sets BZR_EMAIL = None, and EMAIL=jrandom@example.com [17:44] if you are inheriting from a bzrlib TestCase you should get that for free [17:44] jam: no [17:44] if you are just inheriting from unittest.TestCase then you won't [17:44] and you'll want to do something similar [17:44] jam: if i run 'bzr whoami' in os.system() in the test, it prints the message that it's unset [17:45] dobey: right, but that is because there are multiple ways of setting it [17:45] what does "set" give? [17:45] we will accept, EMAIL, BZR_EMAIL, or 'bzr whoami "foo bar " [17:46] none of those are in my env [17:46] and the tests are setting BZR_HOME to an empty dir [17:47] dobey: IIRC, 'bzr whoami' only looks at the information you gave it [17:47] (it doesn't look at the env vars) [17:48] dobey: would you have an older version of bzrlib? [17:48] like 2.1 ? [17:48] well it looks at the config too. and since it's printing the no value message, it is not reading it from my config [17:48] no, i'm on maverick and have bzr 2.2 [17:49] this broke when the 2.2 release went into maverick, and i did some work on the tarmac tests to make the error go away [17:49] but it seems to have cropped back up somehow, though i can't make it happen on my machine [17:52] dobey: sorry, I got disconnected for a second, last thing i see: [17:52] 11:49:11 AM) dobey: but it seems to have cropped back up somehow, though i can't make it happen on my machine [17:52] (11:50:00 AM) jam: dobey: this is for the tarmac test suite itself, right? [17:52] yeah, a subset of the tests in tarmac [17:53] i'm happy to switch it to using the appropriate bzrlib testcase, but want to understand why i seem to be the only person not seeing the issue :) === Ursinha-lunch is now known as Ursinha [18:30] quick question, is there a way to make a branch on the remote server without having to make commands via ssh. I'm basically saying can I from computerA do this: rubbs@computerA$ bzr branch bzr+ssh://computerB/branch1 bzr+ssh://computerB/branch2? [18:31] rubbs, you should be able to, yes [18:32] it would probably be slower than ssh'ing out to computerB or computerC though [18:35] jelmer: thanks, that worked. I know it may be slightly slower, but at this point it's easier to explain it to newbies. Long story short, I want all their branches to be on the server so I can back up their work. They will use bzr to create their branch on the server, then branch+bind to their local machine from the new server branch. If I can get them to do it all with bzr commands, it will make more sense to them. [18:35] after they are more comfortable I'll make sure they know they can do it faster [18:36] I'm also toying with the idea of giving them sftp access only to our repo server [18:39] rubbs: well, s/slightly/a lot/ [18:40] rubbs: rather than using local paths it would fetch all data locally to computerA only to send it off to computerB again === beuno-lunch is now known as beuno [18:59] jelmer: ah, I'll try to find another way around it. === zyga-dinner is now known as zyga === deryck[lunch] is now known as deryck [19:15] hi all! is there a [stable|reliable] way to have composite/nested trees? [19:45] servilio: the externals plugin seems popular [19:46] lifeless: will take a look, thanks [19:47] lifeless: just found the lp:~jelmer/bzr/foreign branch, but doesn't have any linked blueprints or bug report, so no info on when to expect it to be merged in core bzr === Ursinha is now known as Ursinha-brb [20:01] servilio: What do you expect that branch do be? [20:03] jelmer: it is a hosting environment, I have one repo for the environment skeleton, and another for the different hosting buildouts [20:03] servilio: I mean ~jelmer/bzr/foreign, what are you expecting it to do? [20:04] servilio: it's just the branch where I keep changes to improve foreign branch support that haven't landed yet. [20:04] so, are there any options in the stock bzr to be able to create nested branches? [20:05] like "bzr co repo:hosting . && bzr co repo:buildouts/b1 b1" [20:05] and then being able to do bzr pull independently in b1 and its parent to pull updates [20:06] is that possible right now? [20:06] servilio: no, see bug 402814 [20:06] Launchpad bug 402814 in Launchpad Bazaar Integration "Importing revisions with submodules is not supported (affected: 8, heat: 56)" [Wishlist,Triaged] https://launchpad.net/bugs/402814 === lool- is now known as lool-webchat [20:11] jelmer: just read the bug report [20:12] jelmer: but I don't have anything clear yet [20:12] jelmer: I mean, of current support and if it is possible to use it [20:13] servilio: there is no support in bzr core for by-reference nested trees. There are some plugins that provide alternatives. [20:14] jelmer: and what's the prospect for its support in the core? [20:15] jelmer: any plugin that has some kind of forward compatibility with the approach that core will head to? [20:15]