[00:06] jelmer: ping [00:40] SmileyChris: when do you want that shown? [00:40] only when you ask for it? [00:40] or on every commit? [00:40] poolie: I found how the equivalent shows up in "git status" useful [00:41] i can see how that would be useful [00:41] robert was asking for status to also tell you what branch you're working on [00:42] Git keeps every branch on-hand, but bzr doesn't, so it isn't really possible.. [00:43] Sure it's possible. It's just really painful. [00:44] yeah, thinking about it I realise it's a bit different, git has the remote origin branch stored locally in it's repo [00:45] well... [00:45] in at least some cases we could easily do it [00:45] if the parent was local [00:47] something tag like that points at the revision i pushed/pulled last could be useful. so you find out by looking at your local history if you did offline work [00:51] hm, something like that could be hacked as plugin? pre-push hook: remove tag, then in post-push hook: add tag, move tag in post-pull and merge [00:53] there could even be multiple such tags, one for each location one used in the past to push to [01:00] Good morning. [01:01] hello spiv [01:04] poolie: I've got good progress on bug 429747 I think. [01:04] Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,Confirmed] https://launchpad.net/bugs/429747 [01:05] I think I have a reasonable interface and implementation for the higher-order-function suggested in the bug, and I'm just fleshing out the tests and experimenting with how it works in actual code. [01:07] There are a couple of variations, like "convenient way to run N cleanups so that they all run even if some fail", which commit at least ideally wants. [01:08] I have some code for those too, but there's also a simple "run_cleanup" function that just runs a function and logs/reports any error without letting it propagate. [01:10] poolie: still planning on coming up today? [01:12] spiv, hi [01:12] on phone atm, still basically planning [01:12] depending on weather [01:14] Yeah, it's a bit unpleasant. Fascinating though... [01:15] lifeless: There? [01:19] spiv: with any luck the rain we've copped overnight and is still happening should settle it all down for you. big mud puddles everywhere but an improvement. [01:19] spm: yeah, looking forward to that. [01:19] spm: in the meantime, I've been admiring http://www.flickr.com/photos/plasticbag/galleries/72157622310168099/ [01:20] wow! we got nothing like that. dusty, but wow. [01:25] jkakar: phone call [01:25] lifeless: Ah, okay. [01:27] spiv: Amazing photos! [01:41] lifeless, poolie: just an FYI, but upgrading stacked branches works now (just tested on staging) [01:41] for Launchpad anyway [01:45] Hi [01:45] does anyone know if tortoisebzr and tortoisesvn can be installed on the same system? [01:46] ub3rst4r: is there any reason it wouldn't be possible ? [01:46] i dunno [01:54] ub3rst4r: I believe they can be [02:07] jkakar: hi [02:07] lifeless: Heya! [02:07] lifeless: I'd like to use cmd_alias in Commandant, ideally making it automatically available to any Commandant-based program. [02:07] lifeless: I've implemented a prototype and got it working. [02:08] lifeless: There's a couple of warts though: [02:09] 1. It prints 'bzr' in it's output. I've dealt with this in the help text produced by Command.get_help_text by using text.replace("bzr", "my-program"). This trick isn't really possible with the cmd_alias command. [02:09] 2. I have to monkey patch the bzrlib.config.config_filename to return the patch to my program's configuration file, instead of ~/.bazaar/bazaar.conf. [02:10] lifeless: So, I'm thinking about making the change in Bazaar to make this easier. [02:10] I think these are: 1. Add a set_config_filename function to bzrlib.config. [02:11] if I can tempt you with doing a little more [02:11] 2. Add get_program_name and set_program_name functions (probably to bzrlib.__init__) which default to 'bzr'. Change places that use 'bzr' to use the function. [02:11] we'd like /etc/bazaar/*.conf to work (bazaar/locations/..) [02:11] 3. Make %(program-name)s work in docstrings. [02:11] this would seeem to conflict with just set_config_filename [02:12] lifeless: Yeah, it feels like what I'm proposing is good for me, but not necessarily clean for Bazaar. [02:12] lifeless: That's why I wanted to chat you up, to figure out what the right thing to do is. I'm happy to be tempted to do more than I originally intended. :) [02:13] jkakar: so I think if you got /etc/bazaar/* working, and then added something that works for you, we'd both be happy [02:13] for get/set program name. [02:13] * fullermd is very worried about implementations of /etc/bazaar/* [02:13] that's fine, I wouldn't add it to __init__ though [02:14] commands for now please [02:14] lifeless: Ah, so for /etc/bazaar/* you want something like a set_config_path? [02:14] lifeless: commands sounds like a good place for that, yeah. [02:14] and 3 seems kindof obvious [02:14] Cool. [02:14] fullermd: in what regard? [02:15] jkakar: for substitions, uhm, there should be a method on Command [02:15] or something like that, so it can be locally controlled yada yada yada [02:15] either to do, or to look up the thing being substituted [02:16] we have 2 primary use cases today: manpage generation, and online help [02:16] lifeless: Yeah, I was thinking about something like adding a check for a get_substituted_variables function on command, and then passing the dict of default + command variables to Command.get_help_text. [02:16] Well, in a sentence, because it brings up a lot of problems in our config structure, which means either (a) a very long process of working them out, or (b) an implementation that explicitly disavows doing that, and probably makes it worse in the long run. [02:16] fullermd: what sort of problems - I'm completely at a loss here [02:17] lifeless: I'll have to figure out how manpages are generated to make sure the substitution logic lands in the right places. [02:17] jkakar: see make docs [02:17] lifeless: Ta. [02:17] It relates to the issue of "branch.conf parameters that should be propogated by branch vs shouldn't", which we unsatisfactorally sidestep at the moment. [02:18] Some things we'd want to hard-override per system, some we'd want to default. Mechanism, blah blah. [02:18] (and the unrelated issue of "/etc? No, it should be..." of course) [02:20] fullermd: will you be unhappy if jkakar puts a patch forward that makes /etc/bazaar/bazaar.conf & locations.conf work ? [02:21] * fullermd shrugs. [02:21] I don't get a vote in such things anyway. [02:21] I'm just rather pessimistic today, and it feels lose-lose to me. [02:21] If the discussion doesn't come up, we've added another layer of pre-existing conditions we have to somehow not screw up when we DO add such capabilities. [02:22] If it does, I'm sure it will get to a useful conclusion almost as fast as per-branch rules. [02:23] fullermd: so per branch rules stuck because the folk needed in such a discussion where backlogged way above eyeballs with performance [02:23] fullermd: and its non trivial. [02:24] fullermd: If you agree that system wide configuration is useful [do you?] [02:24] I know. I don't claim it's because of malice or indifference, but it still bogs down. [02:25] i think we certainly want system-wide config [02:25] we can always say 'we suggest you don't set X system-wide' [02:26] yup [02:26] jkakar: so - we have a go ;) [02:26] jkakar: can i suggest that rather than setting these things individually there should be some kind of ConfigFactory [02:26] Absolutely. We very much need many levels of configuration beyond "OK, tell all your users to manually edit this file to add these lines" [02:26] and you replace that wholesale to make it think it's called something other than bzr [02:42] poolie: Sounds like a plan. [02:43] lifeless: Yep, I'll start on it tonight. :) [02:52] lifeless: do you know off hand how to ask apt whether a set of packages would be installable, short of installing it? [02:52] nope, sorry [02:52] theres a graph resolver thingy [02:52] justinstall --dry-run? [02:52] oh [02:52] I thought you meant pyapt :) [02:53] thingywhatsit [02:53] apt-get -u install foo? [02:53] apt-get -s install foo [02:53] mm [02:53] https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987 [02:53] Launchpad bug 434987 in devscripts "chdist fails with "E: Internal Error, Could not perform immediate configuration (2) on libattr1"" [Undecided,New] [02:54] Ah, -s it is indeed. I'm used to using -u with upgrade and dist-upgrade so thought it might work with install (it doesn't). [02:55] -u shows what will be upgraded [03:00] lifeless: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf <-- a bit interesting [03:00] images...pdf :P [03:01] [reading] [03:03] this explains why they did the C code blocks work :P [03:06] I needed to use non bzr diff and patch. The patch is only changing a few lines in the files but bzr diff shows that bzr wants to change the whole file for those changed. Can I do anything about this? [03:08] Meths: you may be dealing with some EOL issues [03:08] Meths: are you on windows? [03:08] yeah [03:08] patch has probably changed the line ending on the file [03:08] you could see if it has an option to control that, and if it does bzr revert then apply the patch again with that option [03:08] Diff and patch? Like, GNU diff and patch? [03:09] ah, so a dos2unix should get a normal diff, I'll go try now, thanks. [03:09] Peng_: yep [03:09] What are you doing? Why not use 'bzr merge' or a revision bundle or somesuch? [03:11] Sweet, dos2unix fixed them up nicely, shoulda known [03:29] :( [03:29] a crash [03:30] What crashed? [03:30] bzr [03:31] * thumper is filing a bug [03:31] Ah. [03:33] https://bugs.edge.launchpad.net/bzr/+bug/435000 [03:33] Launchpad bug 435000 in bzr "bzr crashed on commit after removing a directory of files" [Undecided,New] [03:34] Nice bug number. [03:37] I've made a local branch [03:37] and I've just committed to it [03:37] but I want to push the branch as of one revision ago to LP [03:37] is there an easy way to do this? [03:37] bzr push -r 123 [03:37] Well, -2 [03:37] * igc lunch [03:38] * thumper tries [03:47] spiv: more dust photo's, tho .. I dunno. 'shopped maybe? http://www.militaryphotos.net/forums/showthread.php?t=165656 [03:49] spm: nah, I used to live near there. That was a regular sight ;) [03:50] * spm thinks for a suitable response. can't, so just sniggers. [05:23] hello all [05:25] hai [05:25] versioning yourself now? [05:25] poolie1.1.1.1.1.1 [05:25] :D [05:26] is irc bug [05:26] No, it would be like poolie1.1.1.1.1397.1. [05:26] Anyway, I'm done now. === poolie1 is now known as poolie [06:01] lifeless: any particular reason for bug 435026? [06:01] Launchpad bug 435026 in bzr "bzrlib.ui docstring references factories not in the module" [Wishlist,Confirmed] https://launchpad.net/bugs/435026 [06:04] Hmm, I think clearing test._log_contents in more cases (e.g. not applicable, known failure) significantly cuts the test suite's memory consumption... [06:05] How significantly? [06:05] it's only at 59M after 1500 tests, and growing very slowly. [06:06] Give me a few minutes and I'll have a decent direct comparison. [06:06] poolie: yes, fixing a deprecation warning you added ;) [06:07] poolie: in conflictchecker, its cron is annoying everyone watching it ;) [06:07] ? [06:07] which one? [06:07] poolie: direct construction of ProgressBar [06:07] and what checks the docstring? [06:07] programmers [06:08] I read pydoc to find out what I should be using [06:08] and had forgotten that things were in submodules, so when I added ui_factory=bzrlib.ui.TextUIFactory() - well it failed ;) [06:08] i'll fix that bug if you're not immediately going to [06:09] poolie: please [06:09] poolie: its not major, but having observed it I just wanted to capture it [06:09] sure [06:09] i just wondered if you were running an api doc tool or something [06:10] no, interesting idea though [06:13] Hmm, or maybe it's making less difference than I thought. I thought I was seeing much worse memory consumption yesterday though... hmm. [06:13] ~1514 tests == VmPeak of about 205 MB for me. [06:14] Peng_: I'm running the "(?i)commit" subset, for no particular reason. [06:14] And on 32-bit. [06:14] I was running no particular subset, on 32-bit. [06:15] I'm not sure VmPeak is very useful, I think Python tends to allocate lots more address space than it actually uses. [06:16] VmPeak is interesting because everything else is the current value, not the peak value. [06:16] VmRSS: 85584 kB [06:17] I tend to look at VmHWM. I wouldn't mind an authorative link for exactly what the different fields in -Dmemory mean... [06:17] I know *roughly*, but details tend to matter. [06:17] I have no idea what VmHWM is. [06:19] Peng_: man proc claims "Peak resident set size ("high water mark")" [06:19] Oh, cool! [06:19] That sounds perfect! [06:19] spiv++ [06:26] lifeless: http://pastebin.ubuntu.com/276214/ - pre-review welcome [06:27] what am I looking at? [06:29] is there how to query bzr status of a file? [06:29] bzr st file [06:30] I'm doing a rebase but when I commit the change list shows "missing some_file.OTHER" [06:30] lifeless: the whole file is new, it's an attempt at interface testing of uifactory [06:30] poolie: ok [06:30] i think it's uncontroversial [06:30] but that's why i'm asking [06:31] poolie: I just needed some context :) [06:31] there's a comment explaining the point, but we also talked about this a while ago [06:32] a conflict occurred in rebase, so I solved it manually and bzr resolve filename, but now when I commit filename.OTHER shows as missing [06:32] poolie: I'd be very strongly inclined to use injection rather than subclassing here. [06:32] is this normal? I don't want that artificial info on the history [06:33] RenatoSilva: I don't really know, few folk in the bzr community use rebase. [06:33] if the files were added on separate branches that you're now rebasing together [06:33] lifeless: it seems very interesting! [06:33] it's reasonable that you'd end up with [06:33] that kind of conflict and it's not necessarily a problem [06:34] lifeless: tell me why? just because we're generally doing that? [06:34] poolie: I'm not asking about the conflict itself, which was solved [06:34] i was originally going to do that but the problem i ran into is that the resource i want to inject includes some code that makes assertions about what happened [06:34] poolie: I'm asking about the artificial "missing xxx.OTHER" when committing [06:35] and that code can most conveniently be written within a subclass of TestCase [06:35] poolie: I think it would fit and scale better [06:36] to use scenarios? [06:36] poolie: yes [06:36] mm [06:36] poolie: possibly in combination with resources, or something the encapsulates the setup of the fixture [06:36] how would you handle having assertion-making code be parameterised? [06:36] s/the/that/ [06:37] lifeless: I just achieved a clearer, natural history, as described in http://pastie.org/625271 [06:37] lifeless: a guy from #git said that it may work for small feature branches, but not for long-lived [06:38] so [06:38] your conflict is probably a name conflict [06:39] xxx.OTHER means rebase is trying to readd a file already on the other side [06:39] this could be a bug in rebase [06:39] or in how you're using it. [06:39] lifeless: weird! I uncommitted, then committed again and the xx.OTHER is not reported anymore [06:39] thats because the pointer to it was removed on the first commit [06:40] so it's a bug right [06:40] you may find you get a delete+add when you merge to the other branch [06:40] and that your history of that file is disconnected [06:40] RenatoSilva: no, it may be you using rebase when you shouldn't :). Or it may be a bug. I don't know. [06:41] lifeless: bzr resolve --all maybe does not clean .OTHER files [06:41] poolie: well, when I look at your code, you have 'create a resource' code, 'execute the test' code, and 'check the resource' code. [06:41] RenatoSilva: the file was deleted, but your tree still wanted it. [06:41] RenatoSilva: because it was part of the conflict [06:42] lifeless: conflicts on a merge are displayed as BASE and THIS, in rebase it is BASE and OTHER, maybe bzr resolve does not know OTHER [06:42] RenatoSilva: conflicts within a file are BASE+THIS+OTHER, conflicts about *names* show up differently. [06:42] RenatoSilva: but I'm having to guess because I don't know what happened [06:43] lifeless: well, I think bzr resolve --all should have deleted all info about those files [06:48] Woot, Command.get_help_text is using the program name from a centrally registered ProgramInfo instance! [06:51] spiv: https://bugs.edge.launchpad.net/bzr/+bug/435048 [06:51] Launchpad bug 435048 in bzr "many get_parent_map calls during walk to common revisions" [Medium,Confirmed] [06:52] poolie: thanks [06:52] is that new or old ? :) [06:53] lifeless: the bug? Dunno, that's why I asked him to file it ;) [06:53] lifeless: http://yfrog.com/0ximagemxap [06:53] lifeless: better resolution: http://img33.yfrog.com/img33/5295/imagemxa.png [06:55] RenatoSilva: yes, I understand what you're doing [06:55] RenatoSilva: that doesn't mean I know what happened [06:55] RenatoSilva: you need to look at the per file graphes [06:56] I will also note that you're publishing these branches as you develop, so rebase really isn't a good choice. [06:56] lifeless: for solving the .OTHER issue? I think it's ok now [06:56] RenatoSilva: Until you've checked the per file graph in both branches after merging back, you can't know. [06:57] lifeless: confusing [06:58] RenatoSilva: how so? [07:01] publishing these branches as you develop, so rebase really isn't a good choice. ----> I don't know how would that rebase affect another derived branches, I think that it would make merge easier. I don't know... [07:02] maybe I need to get more experienced [07:04] try it and see....but as you say that rebase is bad, maybe I'll keep the former approach (update merges) [07:05] the wonderful thing of that rebase is that it's just liked I branched trunk today, and I could bzr push (not merge) to trunk now [07:06] * RenatoSilva flips a coin for pushing userprefs or userprefs.rebase [07:07] RenatoSilva: rebase _breaks_ the ability to pull or merge the old branch [07:07] RenatoSilva: it breaks the links in history [07:07] RenatoSilva: in the git world, rebase is used for private branches, not for ones shown to the world [07:11] well, I can't understand it atm, hope to do in the future as I get more used to it... [07:11] thank you anyway! [07:13] hi all [07:13] hi [07:13] http://paste.ubuntu.com/271990/ have you reproduced at all? [07:15] lifeless: actually, yes, just this morning on gentoo, but it's still... random [07:15] vila: open a bug please [07:15] was it ext4 again? [07:16] lifeless: err, let me check, I think the last time was on karmic no ? [07:16] no ext4 on my gentoo VM [07:17] lifeless: so tmpfs or ext3 [07:39] lifeless: I think I've done the basic things necessary to have customizable program information (name and version right now) and substitution in help text generated from docstrings. [07:40] lifeless: I'm going to start a second branch, based on this first one, to update bzrlib.builtins, since I've only touched bzrlib.commands so far. [07:40] lifeless: Should I create a merge proposal for the first branch now, or would you prefer them together? [07:51] lifeless: bug #435065 [07:51] Launchpad bug 435065 in bzr "Random test_hammer_hashcache failure" [Medium,Confirmed] https://launchpad.net/bugs/435065 [07:52] lifeless: I'll comment to add the new occurrences if ever [07:52] at first I thought that said "test hammer headache failure" which I would think would be an easy test to pass; apply hammer to head, and assert(). === AfC2 is now known as AfC === vila is now known as vila-dentist [07:55] AfC: :D [07:58] vila-dentist: thanks [08:10] Are there tests for the bzrlib.builtins module? [08:11] Ah ha, bzrlib/tests/commands. [08:18] jkakar: not really [08:18] jkakar: they are ... odd [08:18] jkakar: bzrlib/tests/blackbox/test_foo is our current preferred place [08:35] lifeless: Yeah. [08:35] lifeless: I'd like to write a test that basically goes through each builtin command and calls Command.get_help_text() on it, to make sure that the interpolation works properly. [08:37] I don't want to misspell %(program-name)s and not find out until it's too late. [08:38] jkakar: don't [08:38] lifeless: Heh, okay. [08:38] jkakar: I think thats essentially a CPU time waste [08:39] because, the code is in command.py [08:39] lifeless: Yeah, I can see that. On the other hand, I do want to make sure users don't get a broken experience. [08:39] so we should have a test there === weigon_ is now known as jan [08:39] if a particular command wants to vary, it should be able to === jan is now known as weigon [08:39] I don't think that e.g. 'cmd_push' should show up as anything other than 'bzr push' in its help [08:39] There's a test for the generic logic, just not each actual docstring for each builtin command. [08:39] lifeless: Oh, hmm. [08:40] lifeless: I've gone and replaced all the 'bzr' instances in the help text with %(program-name)s. [08:40] there are commands that are general and reusable [08:40] such as alias, where it makes sense [08:40] lifeless: Maybe I should only do it for commands that are obviously reusable? [08:41] jkakar: I think you should do it for the ones you want to reuse, so we can evaluate if it makes sense etc [08:41] cmd_help :) [08:41] I don't see that branding the front end for 'cmd_serve' makes a lot of sense though. [08:41] lifeless: Also cmd_version. [08:42] the text is easier to read for program authors as 'bzr this' [08:42] and 'bzr that' [08:42] lifeless: Okay, I guess I'll revert the changes that aren't necessary. [08:42] lifeless: It is, yeah. [08:42] so we should only pay the price of having it have subst vars when there is a benefit [08:42] lifeless: Right now it always tries to. [08:42] [a benefit we want :P] === vila-dentist is now known as vila [08:42] jkakar: the cost to calculate them is low, I'm fine with the program always translating [08:43] lifeless: Okay, cool. [08:43] jkakar: cmd_version seems surprising to me, I would have expected --version to be what you advertise/want folk to see [08:46] lifeless: I was just looking at it and it's not as trivial to replace as I'd hoped. [08:47] lifeless: I have a cmd_version in commandant.builtins that prints the program name and version and has a --short option. [08:47] lifeless: I was hoping to remove it and use the version in bzrlib, but it's not obvious just now how to do that nicely. [08:49] I have two thoughts here [08:50] one is that --version != 'frontend version'. I wish bzr didn't have a 'version' command. [08:50] the second is that you can probably write an appropriately hookable thing, but its such a shallow thing I'd rather we encouraged people to do what bzr does [08:51] and include all sorts of useful things there [08:51] by not giving the a fork [08:51] the second is kindofweakandarguable [08:53] Yeah, makes sense. [08:54] Being able to install a custom bzrlib.version.show_version would be the trick I guess. [09:04] fullermd: hey [09:04] fullermd: you still around? === mrevell-dinner is now known as mrevell [09:16] hello bzr [09:19] Where do you say in Launchpad what version of Ubuntu you're running when reporting a bug? [09:19] AfC, in the comment? :) [09:20] otherwise, you file the bug against the package in the specific series [09:20] AfC: ubuntu-bug will do that for you [09:20] beuno: garh no [09:20] lifeless: what's that? [09:20] AfC: are you filing a bug upstream on e.g. bzr, or on something in ubuntu itself? [09:21] beuno: really? You mean their bug tracker devoted to bugs about a Linux distro doesn't have concrete metadata for which distro version something is being reported about? [09:21] lifeless: ubuntu [09:22] AfC: then you should run, on your machine 'ubuntu-bug PACKAGE' [09:22] AfC: and thats all :> [09:22] oh [09:22] AfC, correct. Primarily because it's not ubuntu-specific [09:22] [well, in this case not sure what package, but I guessed] [09:22] beuno: well that's stupid. [09:22] beuno: because it may not be Ubuntu specific, but it's surely Ubuntu central! [09:22] AfC: the feature of tracking versions <->packages is called 'infestation'. We had it, but not polished, so it was removed to avoid the massive scaling problems it engendered. [09:23] beuno: I think you should have some coffee; or some sleep. [09:23] lifeless: sure [09:23] * igc dinner [09:23] lifeless, I've had both! [09:23] lifeless: but I mean, you'd think it'd be important for me to concretely be able to say [09:23] beuno: because you're suggesting things the ubuntu bugs team would be quite unhappy with! [09:23] "THIS IS A RELEASE CRITICAL BUG IN KARMIC". You know, just FYI. Trying to help. Hello? Anyone? [09:24] AfC: so by definition we can only have RC bugs with unreleased code ;) [09:24] lifeless, I don't think I'm suggesting anything at all. I'm stating how things work! [09:24] AfC: a floating bug is presumed to be in karmic [09:24] beuno: only ubuntu-bugs & teams with similar privileges can open series bugs; other folk have to nominate. [09:24] lifeless: well, sure. I'm taking the definition from what it meant in Debian terms ~ 10 years ago. I'm sure things have involved. [09:24] evolved* [09:25] beuno: and its used to track planned work, not present-in [09:25] beuno: in Ubuntu's usage of launchpad today. [09:25] anyway, it just seems kinda important to be able to indicate I'm actually using Karmic so that maybe this report is timely, etc [09:25] oh well [09:25] they'll see it some time in 2012. [09:26] AfC: the vast bulk of reports are from $current [09:26] end users rarely file bugs compared to contributors [09:26] lifeless: so am I running $current or $current + 1? [09:26] (and by running karmic you're a contributor) [09:27] lifeless: yeah, not for long [09:27] in my lingo you're running $current [09:27] * AfC can't wait to not be a contributor anymore. This is hell [09:27] Yesterday it was "crash the system on logout". [09:27] I mean, sure, that's one way to shut down, but not quite what I had in mind :) [09:27] Hi, where's the plugins directory? it isn't ~/.bazaar/plugins? [09:28] jnz_: yes [09:28] it isn't there :\\\ [09:28] jnz_, you can create it [09:29] lifeless: and, of course, "try to use 3G card a 2nd time makes CPU spin to 100%, no workie for you" is not exactly fun either. Especially when it was working fine 4 days ago. [09:29] ok, and what about this: Unable to load plugin 'filters'. filters I don't know what kind of plugin it is. [09:29] Sorry, I'll stop venting now. Just been a really frustrating few days. Not really what I was expecting. [09:30] how do i add the actual root to a MemoryTree on a fresh branch [09:31] jnz_: does the command [09:31] $ bzr plugins [09:31] jnz_: give you sane looking output? [09:31] here is some random stuff i tried, im a bit puzzled http://paste.pocoo.org/show/141082/ [09:32] yes AfC, but I don't see filters [09:33] bzr is v2.0rc2 [09:33] jnz_: run the failing command with -Derror [09:33] jnz_: that will give a backtrace [09:33] ronny: look in the bzr test suite for MemoryTree, you can see example usage [09:34] ronny: note that when you drop the lock on a MemoryTree it resets to no-changes [09:34] AfC: well, to be fair we haven't hit Beta yet. its a shame its rough though [09:35] hmm, now i have to check, why i loose the lock [09:36] If I use a different repo format than the launchpad mirror, pulls will b ereally slow, right? [09:36] eh, I mean branch (someone is trying to get a copy of an existing branch on lp) [09:36] lifeless: thnaks for the hint with the lock, didnt think that one would have an issue [09:36] (basically he wants git clone) [09:37] lvh: if the format is different, some degree of transformation will be needed [09:37]