[00:10] hi poolie, fullermd :) [00:11] hi === medberry is now known as med_out [01:03] something for the SCA folks: http://www.popularmechanics.com/technology/digital/fact-vs-fiction/medieval-knights-on-a-treadmill-put-historical-myths-to-the-tes [01:03] oops wrong chan [01:05] heh [01:31] poolie: hi [01:31] hi there [01:31] is there a way to get bzr to apply a patch file? [01:32] or do I just use patch? [01:32] "bzr patch" :) [01:32] gah, here I was looking for a merge option [01:32] from bzrtools i think [01:32] is this a bzr bundle, or just a plain patch? [01:32] if it's a bzr bundle with metadata, you want 'bzr merge' [01:33] it is a plain patch [01:33] which fails to merge [01:33] thumper, can you search your brain and social network for someone suitable for bit.ly/ubuntu-vcs-job [01:33] so I'll be editing the files manually by the look of it [01:33] try the external tool 'wiggle' [01:33] poolie: I mentioned the job to thomi [01:33] poolie: he is mildly interested [01:34] but committed to teach until Dec [01:34] yeah he could be interesting [01:34] wiggle? [01:35] Interesting to see Go in that job description [01:38] AfC: Go has been added to almost all the new canonical jobs [01:38] someone is becoming a fan [01:38] poolie: bit.ly is timing out for me :( [01:38] thumper: the same person who became a Qt fan? :) [01:39] AfC: perhaps [01:39] {sigh} [01:39] I couldn't possibly comment :) [01:39] that said, Go does look interesting [01:39] I've been trying to think of something interesting to write in it [01:41] thumper: http://www.dilbert.com/fast/1995-11-17/ [01:42] * thumper sighs [01:42] it seems vodafone's 3G is having issues [01:42] some ports are fine [01:42] but 80 doesn't seem to be one of them [01:47] afc, more like http://twitter.com/#!/gniemeyer [01:47] also, http://browsertoolkit.com/fault-tolerance.png [01:47] and hi [01:48] poolie: and unto you, hi [01:48] hahahah [01:48] i love that [01:48] that's bloody awesome [03:22] go and qt huh? has someone put them together? I goog'd but didn't find anything [03:23] also, that ft comic is awesome; does anyone know where the original is? [06:49] poolie: got a second? [06:49] hi, sure [06:49] I've managed to get the system-wide config file working under Linux, with a few caveats: [06:49] hooray [06:50] first, as far as I can see, the only place in bzrlib that uses the config stack rather than the old config store API is when picking which editor to use for commit messages. [06:50] Second, I'm unsure how to go about writing tests for the new code. [06:50] it's mostly not updated yet [06:50] vincent's in the middle of working on this [06:51] hm [06:51] oh ok, cool. [06:51] but if you update some of them that are relevant to your work, i'm sure he won't object [06:51] so, what do we want to test? [06:51] i'd say it's mostly that when you ask for one of these stacks, you get something that includes the global config fie [06:52] *file [06:52] right [06:52] there are tests already for the stack stuff.. let me see.... [06:52] for the purposes of test isolation, we might want to make sure we don't see the actual real global file [06:52] so i'd probably add something in osutils or config.py that says where it is [06:53] then that can be overridden by the test suite [06:54] So there's already a test that makes sure that the stack works as expected with mutliple config sources. [06:54] There's also tests that ensure that the config file stores work as expected. [06:56] Do we need a third test that explicitly tests with two files on disk? It seems like the functionality has already been covered by other tests; I'm not sure what I'd actually be testing... [06:59] so i think your incremental test mostly needs to be that the pre-canned class stacks are including something that points to the global one [06:59] i don't think so [06:59] we can add that if we find there's actually a problem [07:02] when you say "pre-canned class stacks" you're referring to "GlobalStack", "LocationStack" and "BranchStack"? [07:02] yes [07:04] hmmm, those Stack classes create the config store instances in their constructors, so unless I'm missing something (possible), I can't see how to write that test and keep it independant of the files on disk. [07:05] hm [07:05] it's ok if they read the file on disk during the test [07:05] we may want to make sure that other tests don't read the global config though, or it will tend to leak in [07:05] one way is to use overrideAttr to monkeypatch the method that gives you the file name [07:05] maybe you should push your branch and propose it and then we can look at that together? [07:05] ahhhh [07:06] ok, it's pushed, I'll propose it now, although you have to understand that it's really not finished yet ;) [07:06] that's totally ifne [07:06] *fine [07:07] * thomi waits for the diff to update... [07:10] Here we go: [07:10] https://code.launchpad.net/~thomir/bzr/add-global-config/+merge/69592 [07:13] nuts - my editor automatically trims trailing whitespace, which makes the diffs in launchpad look a bit messy. [07:21] hm [07:22] that's ok, there's not meant to be any whitespace [08:00] hello all [08:05] hello riddell [08:53] is there a way to set the default repo/pack format to use? [08:53] i'm dealing with a legacy remote and don't want to do the on-the-fly conversion all the time === Mkaysi_ is now known as Mkaysi [09:12] tmm1: hi [09:13] tmm1: you can set an alias for init, e.g. "bzr alias init='init --format=pack-0.92'" [09:33] jelmer: thanks === hunger_ is now known as hunger === Mkaysi is now known as FossBot === FossBot is now known as Mkaysi [14:39] bzr 2.1.1 break-lock not working - can't break the lock? how can I break a lock? Any ideas? [14:49] so... any ideas? [15:17] thevibe: what doesn't work about it? [15:17] oh, too late [15:24] hey everyone. quick question. i created a branch with --no-trees. How do i get a working tree back? [15:25] kjbbb: "bzr co" [15:25] ah, easy, thanks :) === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [18:31] if I want to alter a single tree on a machine such that "bzr uncommit" requires extra effort to do, maybe even blatting out a "no really, don't do that" message, is that trivial, or painful to do? [18:38] There's that param to require the head to stay on the left path. It's really aimed at keeping people from pushing over something changing the left path (e.g., 'merge X ; push X'), but it prevents uncommit too. [18:38] No override for it other than commenting out the config param, AFAIK. So that may be too heavy for you? === yofel_ is now known as yofel [22:36] hi all === 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: poolie [23:07] good morning poolie [23:07] hi there, good evening [23:08] jelmer, heya === r0bby is now known as robbyoconnor [23:13] Noldorin: hi [23:13] hi Riddell, poolie [23:13] jelmer, i'm back (after much time) to trying to install bzr-git ;-) [23:14] thought i could use your assistance a bit [23:14] how's Republika Srpska jelmer? [23:14] so firstly [23:14] how do i install dulwich so that it gets included by the precompiled version of bzr on Windows? [23:15] Riddell: it's great, much nicer than I had expected [23:16] Noldorin: you'll have to compile dulwich yourself, the standalone installer doens't include it [23:16] jelmer, sure...are there instructions anywhere? i see none [23:18] Noldorin: I don't think there are; if you're ok with running just the python source (not the optimized compiled versions) it should be a matter of putting dulwich somewhere in your $PYTHONPATH [23:18] jelmer, no INSTALL file in the package... [23:18] just dloaded 0.7.1 [23:19] Noldorin: The installation should be like any other Python package [23:19] python setup.py install [23:19] yes [23:20] jelmer, that works but remember i am running the Windows bzr binaries...which ignores PYTHONPATH i believe [23:20] Noldorin: you can't use the standalone python installer if you do that [23:20] I think [23:21] jelmer, so i cannot use the standalone python installer + bzr-git at all? [23:21] Noldorin: as far as I understand, no [23:22] right [23:22] got it [23:22] jelmer, time to uninstall the standaloen version and re-install the python 2.7 version :-) [23:22] jelmer, shouldn't affect how i use it, right? [23:24] Noldorin: I don't think so, but I have almost zero experience using bzr on windows [23:24] ok sure [23:24] yeah think you've said before [23:24] jelmer, it sounds logical though [23:27] jelmer, any x64 builds of the windows installer? [23:27] bzr-2.3.4-1.win32-py2.7.exe [23:27] but i want x64 [23:28] no idea, sorry [23:28] sure [23:28] Noldorin: the bzr-windows mailing list might also be of use [23:28] yeah [23:28] found something there already [23:46] jelmer, ok i've installed bzr-python (with a bit of trouble on my x64 box)...where is its location on disk? [23:47] also no tortoisebzr i guess? :-( [23:48] Noldorin: sorry, I have no idea about those things [23:48] ok sure [23:49] Noldorin: the bzr-windows list might be a better bet, or jam/bialix when they get back from holidays [23:49] jelmer, no-one else here eh?? [23:50] Noldorin: I'm not sure if there is anybody else here at the moment familiar with the internals of the windows installer [23:51] i think you can still catch jam today before he leaves but you'd better send mail [23:51] ok sure [23:52] poolie, nickname is 'jam' too? [23:52] yes [23:52] thanks [23:54] poolie, the code for building the windows installer is in the standard bzr branch? [23:54] maybe i can just modify that [23:54] * jelmer gets some sleep [23:55] g'night [23:56] Noldorin: i think it's in a separate project https://launchpad.net/bzr-windows-installer [23:56] ok cool [23:56] poolie, might be my best bet if i want dulwich/bzr-git on windows? [23:57] yes [23:57] ta [23:57] if you get that and update it to include them it could well work [23:57] yeah [23:57] that's the plan [23:57] and also make the installer x64 if it's not too hard!