[00:00] like having no register_command() call, just looking up bzrlib.commands.$foo? [00:02] that sort of thing [00:02] and then falling back to some other place [00:02] but honestly, it doesn't really matter [00:02] and this is better than what we have today [00:05] Hi igc [00:05] Night all [00:05] hi garyvdm [00:06] Must get some sleep... [00:08] hello spiv [00:08] jam, that might be nice, but it seems to hit some snags with aliases etc [00:08] i'll try to keep going on it [00:08] being able to actually test that it's working and does not regress is very nice [00:08] if i say so myself [00:08] jam, spiv, don't forget to organize your travel btw [00:10] *nod* [00:31] I'm consistently getting "out of memory" errors migrating my huge svn repos to bzr. Any way to get 64-bit bzr on windows? [00:32] codebloc: if you install a 64-bit python and then install from source that should do it [00:33] poolie: thanks, and I almost got that going, but failed when zlib was missing [00:33] hm [00:33] i would have thought that would be included with python [00:33] "bzrlib/_chk_map_pyx.c(32) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory" is the error [00:34] i read it's statically linked with python [00:34] ah ok, you're trying to compile it? [00:34] but even if it's included, the header file isn't [00:34] don't I have to compile it, to install from sources? [00:34] you can run the pure python version [00:34] but that will be slower, which might be bad if you have a huge project [00:35] igc is working on windows build stuff [00:35] I tried adding "--allow-python-fallback", as an option to setup.py build, but that wasn't recognized as a valid option [00:35] it may ring a bell with him [00:35] i'm absolutely willing to use the slower pure python option if it gets me over this hump [00:35] i'm trying to convince executives to switch to bzr from svn [00:36] hm [00:36] what happens if you just run 'bzr' from the source directory? [00:37] hmm. it seems to run at least well enough to display usage [00:37] let me try to run the convert command line from here [00:37] codebloc: are you converting using svn-ipmort or fastimport? [00:38] I read svn-import was faster, so that's what I'm trying [00:39] codebloc: you might want to try the --incremental option and convert the repository in batches [00:40] ok, so I tried what poolie suggested, and did a 'python bzr svn-import', but it reports the svn-import command is unknown, which I imagine is due to the warning it also issues saying some compiled extensions could not be loaded [00:40] i'm willing to try batches as a one-time thing if that'll work [00:40] but here's my concern [00:41] some of the revisions in this repos include changes to a ~100MB binary file [00:41] when I tried converting those revisions with mercurial, which I realize is somewhat different, the process jumped to nearly 2GB of memory and crashed almost right away [00:41] that will probably fit [00:41] is it realistic to expect 32-bit windows bzr binaries to handle a few hundred MB files? [00:41] especially if you're using bzr 2.1 and going to a 2a repository [00:41] imbw [00:42] i am [00:42] ok, I'll try to do it incrementally [00:42] i'd try it [00:42] codebloc: memory overhead for a X MB file is ~ 3X [00:42] codebloc: some operations are a lot better, some few are worse. [00:42] there is a [00:43] bug, https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/331342 that you can subscribe to/vote for [00:43] Ubuntu bug 331342 in bzr "bzr python-based installer requires 32-bit python on windows; unclear message" [Medium,Confirmed] [00:43] yeah, i saw that bug. i'll definitely subscribe to it [00:43] i'll try the incremental approach [00:43] thanks for the help [00:44] if I run into more trouble i'll be back [00:54] codebloc: oh also https://bugs.edge.launchpad.net/bzr/+bug/545637 thanks for pointing that out [00:54] Ubuntu bug 545637 in bzr ""setup.py build --allow-python-fallback" doesn't work; need build_ext" [Medium,Confirmed] [00:56] poolie: no problem. I'll subscribe to/vote for that one too [00:57] Speaking of bugs, which we weren't, am I somehow missing the blindingly obvious way to see the list of affects-me-too bugs? [01:00] https://bugs.edge.launchpad.net/malone/+bug/283539 does claim to be fixed... [01:00] Ubuntu bug 283539 in malone "Make it possible to search for bugs affecting me" [Medium,Fix released] [01:04] fullermd: there is an option hidden 3 pages down in the advanced bug search page :/ [01:05] Yes, but it doesn't show me all the bugs that I set affect on. [01:05] ! [01:05] i think you're right [01:06] I search for any status, affects me, and I get 7 results, but bug 374734 (which I hit Affects on) doesn't show up. [01:06] Launchpad bug 374734 in bzr "upgrading many branches is tricky" [High,Confirmed] https://launchpad.net/bugs/374734 [01:06] And the list it does give is kinda weird. Some of them I filed, but it's not all the ones I filed. I'm pretty sure I didn't click affects on at least some of them... [01:15] Owell. Just wondered. If I'm gonna be puzzled, I might as well be puzzled in company 8-} [01:17] i commented [01:17] you can too :) [01:18] I would, but I set that it affects me, and now I can't find it again O:-> [01:25] james_w: now what's happening? http://pastebin.ubuntu.com/400307/ [01:30] poolie ping [01:30] hi [01:30] I need to run in a few minutes [01:30] while I'm gone ... [01:31] is there any chance we can rebuild the desolution instance? [01:31] or whatever the term is [01:31] there's new windows updates and some new software (sphinx) installed there [01:32] poolie: it keep asking me to reboot but I'm not sure if we need to rebundle first or not? [01:32] on phone, we'll do it when you get back? [01:32] we can rebuild it but i don't want to rush [01:32] poolie: sure [01:33] poolie: it may reboot itself (thanks to Windows updates) while I'm gone anyway [01:33] ok - got to go [01:34] * igc back in a few hours [02:23] Oh bother. [02:46] fullermd: looks like someone's having client issues? [02:47] or is an evil bot [03:22] fmm... zlib124dll.zip doesn't contain zlib.h [03:22] Windows installer fails. [03:38] mwhudson: I think the package hadn't built yet [03:39] How do I resolve a 'path conflict'? [03:40] Ah, looks like if I just resolve the target it works. [05:16] back [05:19] hi igc [05:19] hi poolie [05:33] Morning all. [05:33] I'm trying to use lazy imports in qbzr more. [05:34] I've run in to a problem I'm not sure how to solve. [05:34] I get this error on all os.path.xxx calls: [05:34] bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'path' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory [05:35] But no where am I lazy importing os or os.path [05:35] Any ideas ? [05:36] hi GaryvdM - no ideas from me sorry [05:36] * GaryvdM smacks forhead [05:37] did have a lazy import of os.path - sorry all [05:39] :) [05:44] EODing [06:07] When I commit a bunch of changes to my local branch, and then I 'bzr push' to a remote branch, which of the commit messages will be shown primarily? [06:09] all of them [06:09] since push will only work if the remote branch has no new commits [06:11] ah, I thought that [06:12] bzr would show a "tree of commits", like what you see when you look at the output of bzr log --include-merges [06:13] are you talking about push -v or something? [06:14] sorry, I should have been clearer [06:14] what I was thinking of was the commit notification emails that other people receive. (I might be incorrectly using the word "commit" here.) [06:15] but it also shows in the output of 'bzr log', without --include-merges, it shows sort of a "parent" commit summary, and if you specify --enable-merges you see the individual commits that happend before the person merged and, presumably, subsequently pushed their branch. [06:16] s/--enable-merges/--include-merges/ [06:18] so, basically, what I'm trying to do is this. bzr branch remote local; (make change); bzr commit -m "minor change 1"; (make change); bzr commit -m "minor change 2"; bzr push -m "Summary of changes: ..." remote [06:19] at least, it is my understanding that is roughly how a bzr workflow should look... [06:19] bjacques: There is no message on the push. [06:20] If you want something like that, you can do it. [06:20] Well, obviously I also want to show people the big picture rather than a long list of incremental changes. [06:21] So how would I do something like that? [06:21] So, what you want to do is make a merge commit. [06:21] You can't do that remotely, but that's ok. [06:22] You'd do something like bzr branch remote trunk; bzr branch trunk mychanges; ... hack in mychanges, committing as much as you like ...; cd trunk ; bzr merge ../mychanges ; bzr ci -m "Summary of what the mychanges merge does" ; bzr push remote [06:23] ah, cool, will try that [06:23] spiv, you might like to update hydrazine to get a fix for bug 541586 [06:23] Launchpad bug 541586 in hydrazine "feed-pqm should match subject to avoid breaking threads in gmail" [Medium,Fix released] https://launchpad.net/bugs/541586 [06:23] or to tell me it's not fixed :) [06:30] poolie: hmm, I did run 'bzr pull' just before using it [06:34] Oh, the fix is very new, ok :) [06:36] poolie: FWIW, mutt already threaded them just fine :P [06:36] RAOF: that did the trick, thanks! [06:38] poolie: (I think because Launchpad automatically sets the In-Reply-To header for those messages?) [06:54] poolie: with --profile-imports, can I turn it off at a certin check point. I want it show me all the imports before a gui window shows, not after [07:01] spiv, i know, it's really a gpg bug [07:02] poolie: Figured it out. [07:02] GaryvdM: what did you do? [07:02] spiv: s/gpg/gmail [07:03] I insert this at the point that I want to view: [07:03] import profile_imports; import sys; profile_imports.log_stack_info(sys.stderr) [07:03] (it assumes that profileing is on) [07:04] poolie ^ [07:09] ok [07:24] hi all [07:24] GaryvdM: still there !!! Hi ! [07:24] hi vila [07:24] how are things [07:25] hi vila, at work [07:25] GaryvdM: pfew, so you had some sleep, good :) [07:26] poolie: pretty well, I'm working on bug #375898 [07:26] Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898 [07:27] I think I roughly understand what is happening and will try to write a small enough test for it, [07:27] but ISTM that what is really wanted is nested trees and I don't expect to fix that :-( :-) :-? [07:28] So I'll try to see if a simple fix can be devised and investigate possible workarounds (including fixing bzr-merge-into) [07:30] And I'll try to keep up with the patch pilot stuff but I've lowered my expectations there :-/ [07:47] * vila afk [07:56] vlia, thanks for looking at that one [07:56] and for telling me [08:05] night all [08:23] vila: review sent your way [08:24] * spiv is done for the night [08:36] night poolie, spiv [08:36] hi vila [08:36] * igc dinner [08:41] hello! is there a known problem with upgrading branches from the LP ui? I'm trying to upgrade https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu so that I can merge my changes from trunk into that branch but it does not work, upgrading via cmdline downloads ~30mb and then tells me backup.bzr is already there. deleting that via sftp (I'm sure it was gone) does not help, got the same error again. I'm on lucid, bzr 2.1 [08:43] * vila back [08:43] mvo: maybe you can upgrade via web ui. the branch owner will see an "upgrade" link on the page https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu [08:43] hi spiv, igc [08:44] parthm: thanks, I tried that first, I see a "upgrade in progress" box then for some minutes and when it vanishes the branch format has not changed (both on the web-ui info and from bzr info -v bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu/) [08:45] I wouldn't bother much, but it prevents me from merging from my other branches because the formats are not compatible :/ [08:53] spiv: hehe, the test scenarios went through multiplesss iterations, I'll check your remarks and will try to explain why I went this route, [08:54] spiv: the principal intent was to be able to define the scenarios right before the tests instead of in load_tests() [08:54] spiv: these tests are unusual in that their setup is far more complex than our usual tests [08:56] spiv: but as always when focused on a given task, and exploring various ways, reviews are usually raising interesting points so I'll look into that carefully [08:57] spiv: thanks for the review anyway [08:57] vila: I don't have much time right now, but part of my concern is that hopefully we don't need multiple ways of defining scenarios [08:58] spiv: there is one reason here: each scenario needs to be mirrored so that merges are tried in both directions *and* resolutions are tried for both sides [08:58] vila: the APIs for it are already a bit esoteric [08:58] yeah, it was hard to get there so there is certainly ways to improve that [08:58] I don't understand why the mirroring requires special support [08:59] As opposed to e.g. scenarios = scenarios + mirror_scenarios(scenarios) [09:00] spiv: may be I missed a simplification at one point, but when I introduced mirror_scenarios, multiply_scenarios wasn't doing the right thing [09:01] My gut reaction is that it can be simpler. [09:01] spiv: hehe, you should look at some previous versions :-D [09:01] But if you need a more advanced scenario-construction API, then TestCases aren't the tool for it. [09:01] spiv: but I'm all for simpler tests :) [09:02] I can take a stab at simplifying tomorrow if you like. [09:02] TestCases allowed me to keep some locality which make tests simpler to understand [09:02] spiv: if I don't find the time to push anything until tomorrow, you're warmly welcome ! [09:03] spiv: I'll try to answer your review at least [09:03] I seems to me you have a base set of scenarios, and then you wish extrapolate a bunch of other scenarios from that basis. [09:03] And that's something you ought to be able to express directly with the scenarios themselves. [09:04] Maybe the scenarios should have less keys but richer objects in them? [09:04] Not sure, I have a few rough ideas I can explore. [09:04] Maybe inspiration will strike while I sleep :) [09:04] Actually, I'm not sure I get the point about locality either. [09:04] spiv: I'm not confident I've found the right hooks yet (not the right infra for that matter), I've discovered many details why translating the test (from back to white boxes) [09:05] spiv: have a look at the history, things may be clearer that way [09:05] AFAICT, you're essentially just keeping the components of a scenario local with itself? [09:05] I don't see why inheriting from TestCase helps there. [09:06] err, by TestCase you mean TestParametrizedResolveConflicts ? [09:06] I know you want to define custom methods like assertion methods, but that can be done pretty easily in a plain scenario dict without grouping the scenario parts in a TestCase definition. [09:06] Er, right. [09:06] That's not a TestCase? [09:07] oh wait ! You need to look at lp:~vila/bzr/537956-parent-loop-incomplete ! [09:07] spiv: I've changed many things in the test infra there ! [09:07] I see no prerequisite-branch on the merge proposal :P [09:08] that's because I changed things *after* this branch and this branch is a pre-requisite of the following one :) [09:08] spiv: https://code.edge.launchpad.net/~vila/bzr/537956-parent-loop-incomplete/+merge/21224 [09:08] Well, a comment about this would have been handy, at least :) [09:08] Feel free to tell me if I missed one, of course! :) [09:08] spiv: sorry about that :( [09:09] Ok, I'll take a look at that tomorrow. Thanks for the pointer. :) [09:09] spiv: I didn't realize this when we started this discussion :( [09:09] Me either ;) [09:10] mvo: i tried the upgrade locally and it worked. http://pastebin.com/8iZrsJGb [09:10] mvo: i am using bzr 2.1 on karmic [09:10] vila: so, a final thought before I go for the night [09:10] spiv: And I don't remember exactly what I backported from one branch to the other, I'll re-read everything carefully [09:10] vila: I can see the attraction of using the class statement to construct a complex scenario [09:11] vila: but does that class actually need to inherit from TestCase -- or anything else? [09:12] i get a large set of "can't start new thread" error on 'bzr --no-plugins selftest --parallel=fork' http://pastebin.com/AbQ8G0Ge is this expected? [09:12] Also, I wonder if a hugely complex scenario is a smell. I think probably they are unavoidable for genuinely complex situations, but I'm not sure... [09:12] vila: anyhow, good night, and thanks for fixing bugs and improving the test coverage :) [09:13] spiv: one final remark before you go to sleep too :) : I consider this a work in progress, there are still tests that needs to be translated and there are still *no* tests involving several conflicts... So I'm definitely open to enhancements but I don't want to to delay landing fixes either [09:13] mvo: i am not too sure how launchpad branches work but you branch seems upgradable to me :) [09:13] parthm: thanks, locally I can upgrade too, its the remote end I want to upgrade. what is the most efficient way? or some reason bzr+ssh errors out with "backup.bzr" already exists (even if I delete it with nautilus on the server). and the LP webui upgrade does nothing for me. I'm trying sftp:// upgrde now, but it appears to be really slow [09:13] (locally I have upgraded already :) [09:15] spiv: yeah, the complex setup allows to use pdb with the right simple context in the right place, that's the goal, this smells, but I don't want to cheat too much either, building the conflicts "manually" with their associated wt.... yells "brittle" far too loud to my ears :) [09:16] spiv: thanks for feedback anyway, this is hard stuff and I'm glad to be able to discuss it [09:16] mvo: fwiw, bzr 2.2dev allows multiple backup.bzr folders as backup.bzr.~N~ so that particular error will go away. you could try using lp:bzr [09:18] mvo: https://bugs.launchpad.net/bzr/+bug/300001 i am not sure how that plays with launchpad though. [09:18] Ubuntu bug 300001 in bzr "existence of backup.bzr blocks running upgrade a second time" [High,Fix released] [09:19] parthm: thanks, I check the new bzr out now and will try that [09:26] parthm: thanks for your help (much appreciated). I solved it now the cheap way by renaming the lp branch and pushing my local upgraded one as a new branch [09:27] mvo: that sounds good to me :) [09:27] * mvo is *so* happy to be able to commit again [09:47] hi everyone [09:48] I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging [09:50] hello all [09:50] I've read "Contributing to Bazaar", but I'd like to know if they could be considered interesting [09:50] they? [09:54] bialix: ^ quote "I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging" [09:55] from panta [09:57] ah, ok [09:59] panta: Please send an email to the list about them [09:59] panta: If they're generic enough I think we'd be interested in them. [10:02] jelmer: ok, thanks. Should I include a preliminary patch? [10:03] panta: yeah, please do [10:05] jelmer: ok, thanks for the info. [10:15] Hey, im getting a strange error when committing http://pastebin.ubuntu.com/400482/ === shane_ is now known as fagan [10:16] I got it when I did a bzr commit [10:18] I have my ssh and pgp key set up but I only did it an hour ago. (I did a fresh install so I made new keys) [10:19] shane_: you can't commit via http [10:20] Why is it trying that then? [10:20] presumably you have bound your branch to another branch via http [10:20] 'bzr info' oughta show you [10:21] bob2: can I change it to https? [10:21] you probably can't commit via https either [10:21] is this an lp project? [10:22] Yep its planet-ubuntu [10:22] Im just updating my hackergotchi :) [10:23] well, bind to the bzr+ssh url [10:25] bob2: I figured out what was wrong [10:25] It hadnt logged me into bzr yet :) [10:25] that you had bound to a http url [10:25] and you can't commit via http :) [10:25] ah, launchpad-login [10:27] bob2: yep I have it working now [10:27] excellent [10:27] Thanks [10:27] Got to run [11:06] hy! i'm get this: "ERROR: exceptions.IndexError: list index out of range" when I try to bzr fast-import my.fi new-repo/trunk [11:06] what I doing wrong? [11:06] new-repo is created with init-repo before, and it's empty, using bzr 2.1.0 [11:11] u-foka: use just `bzr fast-import my.fi new-repo` [11:11] if it does not work you need to file a bug [11:13] same error :S [11:13] u-foka: pastebin output of `bzr -Derror fast-import my.fi new-repo` [11:13] 1 sec [11:14] how you have created my.fi? [11:14] bzr fast-export old_repo my.fi [11:14] old repo need to be altered [11:15] but the unaltered fi makes the same error [11:19] pretty odd [11:19] are you on windows? [11:21] http://pastebin.com/hCy75EpM [11:21] I'm on lucid [11:24] u-foka: I don't know what the version of fastimport you have. You may want to try to use the latest version from trunk [11:24] but there is definitely error in fastimport plugin [11:24] please, file a bug, and specify the version of the plugin [11:24] okay, thanks! [11:25] the same fi imported on the karmic machine fine [11:26] definitely the bug [11:26] use fastimport as of version on karmic then [11:28] fastimport 0.9.0dev [11:31] it seems to me that this already reported as bug #287767 [11:31] Launchpad bug 287767 in bzr-fastimport "fastimport from git fails" [Undecided,Fix released] https://launchpad.net/bugs/287767 [11:34] bzr rm file1; bzr ci file1 -> "paths are not versioned: file1" [11:34] huh? [11:35] sorry, my bad [11:35] bzr st prints filenames relative to branch root, not to my $PWD :( :( :( [11:41] mgedmin: https://bugs.edge.launchpad.net/bzr/+bug/520662 [11:41] Ubuntu bug 520662 in bzr "Add option to output relative paths" [Medium,Confirmed] === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [14:28] night all === BasicPRO is now known as BasicOSX [15:42] why is sftp so slow. I tried bzr+ssh and I was worried when it had finished so quickly. I thought perhaps it didn't send the commits to the repo. But it had!! [15:44] sftp has to do everything via file reads over the network. [15:44] bzr+ssh spawns a remote bzr instance that can do those file reads on the server. [15:44] so it's faster. [15:44] but sftp works even if you don't have bzr installed remotely. [15:46] jelmer: ping [15:46] vila: 'lo! [15:46] jelmer: hi ! [15:47] bzr-loom is currently broken because BranchFormat.open got a new 'name' keyword arg, rings a bell ? [15:47] vila: ah, yep [15:47] vila: It's documented under "API CHANGES" in NEWS ;-) [15:47] jelmer: long story short, that means bzrlib API needs to be bumped :-/ [15:47] vila: I'll submit a aptch to bzr-loom [15:48] jelmer: thanks ! Not a big deal for loom (I just added the name arg in a hurry as I couldn't use my loom anymore), but bumping the API will have more consequences... [15:49] (for other plugins that is) [15:49] jelmer: the related patch in only in bzr.dev right ? [15:49] vila: yep [15:49] * vila checks 2.2 release date [15:49] vila: this is all work done towards colocated branches [15:50] jelmer: I know, I know, good work ! :D [15:50] rats, 2.2b1 expected in 8 hours [15:51] jelmer: could you propose a patch with the API bump so that poolie wont miss it ? [15:51] vila: ok === salgado is now known as salgado-lunch [15:51] vila: Whoa, I wasn't aware 2.2 was already that close [15:51] jelmer: thanks a ton ! [15:52] jelmer: well, that's what https://edge.launchpad.net/bzr/2.2 says (I have a bit of mail backlog but I'm pretty sure poolie announced it) [15:53] vila: Thanks === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch === IslandUsurperAFK is now known as IslandUsurper [16:56] hmm. no jelmer... guess i won't talk about my bzr-svn bug yet. :) === salgado-lunch is now known as salgado [17:02] Hi! What's the easiest way to find the first mainline revision integrating a given revision using the command line? In other words, how do I find out when a given revision actually got merged? [17:02] MvG: bzr log .. -l [17:02] -l? or -n [17:03] -l == --limit [17:03] oh i see what you mean now [17:04] Missing -r. [17:04] The idea is to start log at the revision you're interested in until the tip limiting the output to at least the merge depth of the revision [17:04] MvG: argh, yeah, sorry [17:04] Otherwise it gives me "bzr: ERROR: Start revision not found in left-hand history of end revision." [17:05] MvG: double-argh, yes add -n0 [17:24] No luck either: "bzr log -r 4056.2.1.. -l3 -n0" for the bzr.dev branch prints the same as "bzr log -l3 -n0". No indication of the merge point for 4056.2.1 === beuno-lunch is now known as beuno [17:25] vila: by max_merge_depth, what number did you have in mind there? [17:26] MvG: meh, that's a bug [17:27] vila: i still don't see how your approach is supposed to work either. [17:28] I understand the -r part, and I see I'd like the last mainline rev printed by that output. I don't see the role of the -l there. [17:28] vila: Oh, a --forward does help. [17:29] MvG: it's to avoid displaying all the revisions you don't care about, ha rats, yeah, damn, 2 args good out of.. 5 ? :-/ [17:29] "bzr log -r 4056.2.1.. --forward -l1 -n0" looks pretty good. I guess I'll define an alias. [17:29] yeah, the result is correct, no bug here, sorry === deryck is now known as deryck[lunch] [18:05] Is there a way to merge two distinct revisions from one branch into another branch? [18:06] Trying to do it in one command, and it is not a range of commits. [18:06] rellis, no, not in one command if they are not sequential [18:07] gotcha, thanks === radoe_ is now known as radoe === deryck[lunch] is now known as deryck [19:43] Peng: have you looked at https://code.launchpad.net/~tseaver/loggerhead/sphinxify/+merge/21948 at all? [20:39] mwhudson: thanks for the review of my pygpgme branch [20:39] mwhudson: do you know if there's any eta on mirrored branches/vcs imports for packaging branches? [20:40] jelmer: i think it's mostly a matter of having a ui to be able to create them now [20:40] mwhudson: does that mean there's already a API to create them ? >-) [20:41] jelmer: ah, no, probably not [20:41] the internal apis probably need to be cleaned up a bit [20:42] but mostly around creation i think [20:42] if you could magic one into existence it would mostly work i think [20:54] the windows installer version of bzr 2.1.0 runs out of memory doing "bzr svn-import" on my repository due to the presence of a single change to a 250MB file [20:54] this on a 64-bit windows machine with 12GB of RAM [20:54] I have created a test SVN repository that can reproduce this problem [20:54] I'd like guidance as to whether this should be a separate bug, or just another manifestation of https://bugs.launchpad.net/bzr/+bug/109114 [20:54] Ubuntu bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Wishlist,Confirmed] [20:55] if it is another instance of 109114, is there any hope of this bug getting a higher importance? I can't use bzr as long as it has this limitation [21:03] mwhudson: hmm, I might then :-) [21:05] codebloc: it's just another manifestation of that bug [21:05] codebloc: I'd recommend asking for a higher priority on that bug report === salgado is now known as salgado-afk [21:49] Hi! Is there anybody here? [21:49] hi andreasheintze [21:50] Hi there! I'm having a question about bazaar and I thought maybe someone here can help me? [21:50] andreasheintze: usually :) [21:51] I'm new to bazaar so... anyway. I have set up a repository of our intranet at work, wich I'm developing in PHP and javascript. [21:52] I have access to the whole site, but I got another developer that is responsible for everything under one folder in this site. [21:53] How can I limit him to just be able to update the files and folders inside that folder? [21:54] I don't want him to able to commit and merge changes of files outside of that folder. Can I do this? [21:57] If anyone has a link or can guide me in the right direction, it would be great! [22:04] andreasheintze: normally this would be done by having separate branches [22:05] I'm pretty sure that bzr doesn't have a restriction like this for a single branch [22:06] mwhudson: Um, probably not. I've been AFK. :D [22:06] Ok, I thought so, but how? If I make a new branch of my main branch it will create the whole site, not just that folder. [22:07] mwhudson: I'll get to it later -- no guarantees I'll do any more than think "hmm, that looks complicated -- I'll let mwhudson handle it". :P [22:07] I've posted a bug for bazaar hookless-mail, but I'm not sure anybody will read it as I'm the only one who is subscribed: https://bugs.launchpad.net/bzr-hookless-email/+bug/546431 Is this bug going to just die? [22:07] Ubuntu bug 546431 in bzr-hookless-email "[whishlist] Support for multiple e-mail adresses" [Undecided,New] [22:10] mwhudson: another thing, newer versions of bzr-svn should be able to handle the KDE repository - it'd be nice if we can get a newer version on Launchpad before the rollout [22:12] jelmer: i think that got integrated when i did the incremental import thing [22:12] Peng: well fair enough [22:12] ah, nice [22:12] bmm: appropriate prodding here should get some bzr developers to at least look :) [22:13]