| jelmer | Noldorin: there's a new bzr-git release (0.6.5) from a couple of days ago | 00:11 |
|---|---|---|
| wgz | no bed quite yet, better do travel now. | 00:13 |
| poolie | wgz, it doesn't have to be right now | 00:14 |
| wgz | will save round trips in the morning :) | 00:14 |
| poolie | by 'today' i meant my today, friday | 00:15 |
| wgz | it's done/ | 00:28 |
| wgz | and my sis is still on the phone, so I'd not have got the extra sleep anyway :) | 00:29 |
| Noldorin | jelmer, oh does that fix the issue i was having with my branch though? | 00:38 |
| jelmer | Noldorin: no, that issue is still open | 00:41 |
| Noldorin | jelmer, ah, oh well... | 00:41 |
| Noldorin | targeting it soon? | 00:41 |
| Noldorin | i guess it's good news the project is still moving...thought this was a pretty crucial issue though | 00:41 |
| jelmer | Noldorin: your repository is the only I've seen it with so far | 00:48 |
| jelmer | Noldorin: it's on my list of things to work on, but I'm swamped by other stuff at the moment | 00:49 |
| Noldorin | jelmer, heh okay sure | 00:55 |
| Noldorin | jelmer, very surprising, since i isolated quite a simple reproduction case :-) | 00:55 |
| Noldorin | jelmer, but clearly you haven't forgotten...thanks | 00:56 |
| Noldorin | brb | 00:56 |
| poolie | GRiD, ok that still sounds pretty good then | 01:08 |
| GRiD | 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:10 |
| GRiD | 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:11 |
| poolie | i guess the question is why is the key getting so big | 01:13 |
| poolie | if it's just encountered a really long whitespace-delimited "word" | 01:13 |
| poolie | then skipping it would be reasonable | 01:13 |
| poolie | i don't know if that is actually the cause | 01:13 |
| GRiD | 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:19 |
| GRiD | 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:21 |
| poolie | 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 |
| poolie | search may not care about indexing long strings but for other things that might lose data | 01:27 |
| GRiD | 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 |
| poolie | i think that'd be good | 01:30 |
| poolie | thanks for fixing it | 01:30 |
| poolie | lifeless, ^ | 01:30 |
| lifeless | yah, I've been following along | 01:31 |
| lifeless | all sounds good to me | 01:31 |
| GRiD | ok i'll take a look at making bzr-search skip then. | 01:32 |
| === iBasic is now known as BasicOSX | ||
| mgz | morning! | 09:15 |
| === jam1 is now known as jam | ||
| mgz | 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:20 |
| mgz | the only significant changes seem to be the rename (to 'ssh'... which seems unwise) and changing all the copyright headers(!) | 11:23 |
| mgz | and has done two releases to pypi without updating NEWS or otherwise indicating what's different as far as I can see | 11:23 |
| jam | 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 |
| jam | 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:33 |
| jam | or 'import paramiko_ssh as ssh" | 11:34 |
| mgz | anyone know if github lets you issue pull requests for other people's branches? | 11:35 |
| mgz | ...not that they'll let me sign in, no openid support and demand js enabled. | 11:35 |
| jam | 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:39 |
| mgz | jam: on your running tests against implementations in different languages thing, | 11:47 |
| mgz | (I don't know why but was thinking about that before going to sleep last night) | 11:47 |
| mgz | 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:48 |
| mgz | eg htmllib5 | 11:49 |
| jam | mgz: sure, but it means implementing a test-suite runner in each language | 11:51 |
| mgz | or it's nearly what bt.test_conflicts.TestParametrizedResolveConflicts is | 11:51 |
| jam | which may not be much better than implementing a test-suite in that language | 11:51 |
| mgz | 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 |
| jam | so far, it seems the only way if we want to ensure the *same* tests get run in each language | 11:51 |
| jam | mgz: we just need to port the python interpreter to vala, js, java, etc, and we'll be golden | 11:52 |
| jam | php will be fun :) | 11:52 |
| mgz | 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 | 11:52 |
| jam | mgz: I think you meant "forwarding our existing patches" not "forwarding out existing patches". | 12:01 |
| mgz | ...I did | 12:01 |
| === zyga_ is now known as zyga | ||
| mgz | the keys are like, right next to each other. | 12:02 |
| === Quintasan_ is now known as Quintasan | ||
| mgz | okay, let's do the github dance | 13:54 |
| mgz | ha, and I don't actually have git installed here, have just been using bzr-git | 14:09 |
| jelmer | mgz: bzr-git should work for pushing too.. | 14:11 |
| jelmer | :) | 14:11 |
| mgz | I need to do a couple of merges and thought I'd try the vanilla option first :) | 14:13 |
| mgz | I need to go out briefly, will be back shortly | 14:46 |
| mgz | back. | 15:31 |
| daveb_ | how do I undo a merge? I want to merge from the same branch, I just wan't to do it later | 16:09 |
| mgz | `bzr revert` | 16:09 |
| mgz | if you have changes in your tree you want to keep, it's a bit harder | 16:10 |
| mgz | but you can tell bzr to forget the merge then undo the merged changes manually | 16:10 |
| daveb_ | I thought revert only changed the working directory | 16:12 |
| === beuno is now known as beuno-lunch | ||
| mgz | it also forgets merges if you don't give specific paths, see `bzr help revert` for more. | 16:14 |
| fullermd | The fact of a pending merge is an attribute of the working tree. | 16:14 |
| daveb_ | i commited the merge | 16:18 |
| fullermd | And other stuff since then? | 16:18 |
| mgz | 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 |
| fullermd | Oh great. No pressure, right? | 16:21 |
| mgz | you're the super sub :) | 16:22 |
| mgz | can sit out most of the game but expected to sometimes come on and produce miracles. | 16:23 |
| daveb_ | ok, uncommit followed by revert worked :) | 16:23 |
| * fullermd takes the credit. | 16:23 | |
| mgz | see, this match we won anyway, so you just get to rest. :D | 16:24 |
| fullermd | Nono, too late! You already made me cross the sideline! | 16:24 |
| daveb_ | i guess you also have to rm -rvf any remote branches you have been pushing too... | 16:27 |
| fullermd | Or push --overwrite 'em. | 16:27 |
| mgz | only if you pushed that last change with the merge you didn't want | 16:28 |
| mgz | for very public locations, it's most polite to work on from mistakes, rather than trying to pretend they never happened | 16:28 |
| daveb_ | hmm | 16:30 |
| === daveb_ is now known as croepha | ||
| fullermd | Oh no, the shame is bad enough he had to change his name. | 16:57 |
| === beuno-lunch is now known as beuno | ||
| croepha | lol | 17:25 |
| jimis | 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 |
| jimis | bzr diff -rrevno:115532:tree1 | 18:10 |
| jimis | for example | 18:10 |
| jimis | bzr log should just display an extra line for each merge operation: "source branch revno: 115532" | 18:12 |
| jimis | in case it is expensive it should happen only with bzr log -n0 | 18:12 |
| jelmer | jimis: that revno is specific to the source branch | 18:17 |
| jelmer | jimis: so you have to pass in the source branch somehow | 18:17 |
| jelmer | jimis: the revno displayed by log is already usable in e.g. diff | 18:18 |
| jelmer | bzr diff -r13423.32.1 | 18:18 |
| * jelmer -> weekend | 18:19 | |
| slangasek | jelmer: if and when you have some time, I could use some help with (modifying) bzr-rewrite | 20:17 |
| ccxCZ | 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:09 |
| fullermd | The local commit is now a pending merge. | 21:13 |
| ccxCZ | it was aggregated with uncommited changes | 21:16 |
| ccxCZ | I would prefer to have them as two separate commits | 21:17 |
| ccxCZ | I seem to be able to get the revid via bzr heads --all | 21:18 |
| ccxCZ | backing up working tree, updating to revid and restoring did the job | 21:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!