[00:11] Noldorin: there's a new bzr-git release (0.6.5) from a couple of days ago [00:13] no bed quite yet, better do travel now. [00:14] wgz, it doesn't have to be right now [00:14] will save round trips in the morning :) [00:15] by 'today' i meant my today, friday [00:28] it's done/ [00:29] and my sis is still on the phone, so I'd not have got the extra sleep anyway :) [00:38] jelmer, oh does that fix the issue i was having with my branch though? [00:41] Noldorin: no, that issue is still open [00:41] jelmer, ah, oh well... [00:41] targeting it soon? [00:41] i guess it's good news the project is still moving...thought this was a pretty crucial issue though [00:48] Noldorin: your repository is the only I've seen it with so far [00:49] Noldorin: it's on my list of things to work on, but I'm swamped by other stuff at the moment [00:55] jelmer, heh okay sure [00:55] jelmer, very surprising, since i isolated quite a simple reproduction case :-) [00:56] jelmer, but clearly you haven't forgotten...thanks [00:56] brb [01:08] GRiD, ok that still sounds pretty good then [01:10] ok cool. the bzr-search change should be pretty easy too, i think. i can look at that after if i get a minute. [01:11] well, easy in that i would just skip the key it's trying to add if it's too big, although i don't know if that's the right thing to do [01:13] i guess the question is why is the key getting so big [01:13] if it's just encountered a really long whitespace-delimited "word" [01:13] then skipping it would be reasonable [01:13] i don't know if that is actually the cause [01:19] yeah i didn't have a chance to investigate that. but if you try to reproduce the original bug (by indexing ubiquity) with my patch, it now excepts on a key that is about a 4k (iirc) string of hex characters [01:21] fwiw, if the long keys are skipped (which one of my early patches did silently), the indexing of ubiquity completes and seems to be usable. [01:27] GRiD, ok, so i think the main thing here is that the decision to skip is a policy of bzr-search, not bzr core [01:27] search may not care about indexing long strings but for other things that might lose data [01:30] yep, agreed. i only meant it in that if bzr-search caught the exception and simply skipped for now (perhaps with warning), it may be sufficient. if it's not, someone who knows more about bzr-search should take a look. [01:30] i think that'd be good [01:30] thanks for fixing it [01:30] lifeless, ^ [01:31] yah, I've been following along [01:31] all sounds good to me [01:32] ok i'll take a look at making bzr-search skip then. === iBasic is now known as BasicOSX [09:15] morning! === jam1 is now known as jam [11:20] hm, it's good to know someone else is interested in maintaining paramiko, but looking at the changes 'bitprophet' has on github doesn't fill me with confidence [11:23] the only significant changes seem to be the rename (to 'ssh'... which seems unwise) and changing all the copyright headers(!) [11:23] and has done two releases to pypi without updating NEWS or otherwise indicating what's different as far as I can see [11:33] mgz: well, having an official release channel is what we are after. We've written a few patches that have just gone ignored for long stretches of time. [11:33] I agree that the 'ssh' thing seems a bit wonky. There can be many ssh libs around, having a unique name is nicer. Though maybe just a namespace "from paramiko import ssh" [11:34] or 'import paramiko_ssh as ssh" [11:35] anyone know if github lets you issue pull requests for other people's branches? [11:35] ...not that they'll let me sign in, no openid support and demand js enabled. [11:39] mgz: if you had an account, you could always 'fork' the other person's branch and propose it directly, so I would think they would allow you to propose someone elses' branch [11:47] jam: on your running tests against implementations in different languages thing, [11:47] (I don't know why but was thinking about that before going to sleep last night) [11:48] what people generally do is structure the cases as data as far as possible, then just write the bits they need for the runners in python/js/etc [11:49] eg htmllib5 [11:51] mgz: sure, but it means implementing a test-suite runner in each language [11:51] or it's nearly what bt.test_conflicts.TestParametrizedResolveConflicts is [11:51] which may not be much better than implementing a test-suite in that language [11:51] yeah, and when you get to the point where it's nearly a mini functional language, the tests aren't very easy to read [11:51] so far, it seems the only way if we want to ensure the *same* tests get run in each language [11:52] mgz: we just need to port the python interpreter to vala, js, java, etc, and we'll be golden [11:52] php will be fun :) [11:52] but there's probably a middle ground where the test cases are still easy enough to write, but the runners don't need to be overly complicated [12:01] mgz: I think you meant "forwarding our existing patches" not "forwarding out existing patches". [12:01] ...I did === zyga_ is now known as zyga [12:02] the keys are like, right next to each other. === Quintasan_ is now known as Quintasan [13:54] okay, let's do the github dance [14:09] ha, and I don't actually have git installed here, have just been using bzr-git [14:11] mgz: bzr-git should work for pushing too.. [14:11] :) [14:13] I need to do a couple of merges and thought I'd try the vanilla option first :) [14:46] I need to go out briefly, will be back shortly [15:31] back. [16:09] how do I undo a merge? I want to merge from the same branch, I just wan't to do it later [16:09] `bzr revert` [16:10] if you have changes in your tree you want to keep, it's a bit harder [16:10] but you can tell bzr to forget the merge then undo the merged changes manually [16:12] I thought revert only changed the working directory === beuno is now known as beuno-lunch [16:14] it also forgets merges if you don't give specific paths, see `bzr help revert` for more. [16:14] The fact of a pending merge is an attribute of the working tree. [16:18] i commited the merge [16:18] And other stuff since then? [16:21] if you haven't done other stuff, can use `bzr uncommit` then my earlier advice, otherwise you're better off... doing something clever fullermd will tell you about [16:21] Oh great. No pressure, right? [16:22] you're the super sub :) [16:23] can sit out most of the game but expected to sometimes come on and produce miracles. [16:23] ok, uncommit followed by revert worked :) [16:23] * fullermd takes the credit. [16:24] see, this match we won anyway, so you just get to rest. :D [16:24] Nono, too late! You already made me cross the sideline! [16:27] i guess you also have to rm -rvf any remote branches you have been pushing too... [16:27] Or push --overwrite 'em. [16:28] only if you pushed that last change with the merge you didn't want [16:28] for very public locations, it's most polite to work on from mistakes, rather than trying to pretend they never happened [16:30] hmm === daveb_ is now known as croepha [16:57] Oh no, the shame is bad enough he had to change his name. === beuno-lunch is now known as beuno [17:25] lol [18:10] jelmer: no need to pass a source branch revno to bzr log, it should print it so we can use it with other commands, like diff [18:10] bzr diff -rrevno:115532:tree1 [18:10] for example [18:12] bzr log should just display an extra line for each merge operation: "source branch revno: 115532" [18:12] in case it is expensive it should happen only with bzr log -n0 [18:17] jimis: that revno is specific to the source branch [18:17] jimis: so you have to pass in the source branch somehow [18:18] jimis: the revno displayed by log is already usable in e.g. diff [18:18] bzr diff -r13423.32.1 [18:19] * jelmer -> weekend [20:17] jelmer: if and when you have some time, I could use some help with (modifying) bzr-rewrite [21:09] I have bound branch, I did local commit and then bzr up, now the revision of the local branch was set back, how would I find the commit and push it? [21:13] The local commit is now a pending merge. [21:16] it was aggregated with uncommited changes [21:17] I would prefer to have them as two separate commits [21:18] I seem to be able to get the revid via bzr heads --all [21:25] backing up working tree, updating to revid and restoring did the job