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!