| poolie | hi spiv | 00:22 |
|---|---|---|
| spiv | Hi poolie | 00:27 |
| poolie | hi there | 00:41 |
| poolie | hi spiv | 00:44 |
| poolie | i'm just about to confirm the sprint on the 16th may | 00:44 |
| poolie | that's still ok with you? | 00:44 |
| spiv | I'll double-check, just a sec | 01:05 |
| spiv | Yep, that's fine. | 01:05 |
| poolie | cool | 01:06 |
| === marienz_ is now known as marienz | ||
| maxb | poolie: whereabouts in London are you going to be? | 02:52 |
| poolie | millbank | 02:52 |
| poolie | do you want to come by? | 02:53 |
| maxb | nice, I could probably even come by bike :-) | 02:54 |
| poolie | good | 02:56 |
| fullermd | Blah. I wish revert took globs... | 05:22 |
| fullermd | Would be handy in resurrecting piles of files. | 05:23 |
| poolie | huh, nice idea | 05:23 |
| quotemstr | Down that road lies madness. | 05:27 |
| fullermd | Nah, I'm right here. | 05:27 |
| chx | hi. it seems i messed up big time. how can i restore? I have merge din trunk, committed that, then pushed Pushed up to revision 18093. then it said "conflicting tags" and I have deleted that conflicted tag and now all revisions after 18093 are gone! they are in that one commit (because it's the previous-HEAD merge) -- is there a way to restore the commit history? :( | 06:18 |
| poolie | hi chk | 06:21 |
| poolie | chx | 06:21 |
| chx | poolie: hi | 06:21 |
| chx | poolie: i am in a panic pretty much. | 06:21 |
| poolie | it's ok | 06:21 |
| poolie | i'm not sure how the tags come into this y | 06:21 |
| poolie | so you merged trunk, and pushed your branch on top of trunk, and now you wish you hadn't? | 06:22 |
| poolie | are we talking about a push --overwrite, or something else? | 06:22 |
| chx | just a push... then i saw what i did then i tried a bzr uncommit... it's lp:examiner -- alas it's private but i am more than glad to add you to help me fix up this mess | 06:23 |
| poolie | so if you do 'bzr log -n0 -r -1' does that show you all your trunk revisions? | 06:23 |
| chx | it does but not with the original commit numbers | 06:25 |
| chx | it says revno: 18091.1.25 and it was 18116 | 06:25 |
| chx | (I must note that 18091+25 is 116) | 06:25 |
| Peng | Right. The revision numbers are irrelevant and depend on your point of view; the revisions are still the same. | 06:26 |
| chx | Well, it's all fine, but basically i need to get https://bazaar.launchpad.net/~examiner-dev/examiner/trunk/revision/18116 working by tomorrow morning :/ | 06:26 |
| poolie | so can you tell me, in order, what you did? | 06:26 |
| poolie | maybe if you temporarily subscribe me (~mbp) to that branch it will help | 06:27 |
| chx | poolie: http://ex.privatepaste.com/8e40d70b5e | 06:28 |
| chx | poolie: added | 06:29 |
| chx | poolie: in short i did everything to make sure i am messed up. | 06:30 |
| chx | I also failed because the Drupal community after all migrates to git not bzr on Thursday :( | 06:33 |
| fullermd | So many people these days just won't go that extra mile to make sure they're messed up. They just keep hoping it'll happen by chance... | 06:34 |
| fullermd | Which it does, of course. But still, so sad, the lack of effort... | 06:34 |
| chx | fullermd: i think i went the extra mile by pushing committing and uncommitting. | 06:35 |
| chx | fullermd: even i have no idea where the hell i am. | 06:35 |
| fullermd | See? True artistry. I doff my cap, sir. | 06:36 |
| Peng | chx: You made a good effort, but I've seen better. | 06:37 |
| chx | Should I laugh or cry? | 06:37 |
| fullermd | I think the only honest answer is "yes". | 06:38 |
| chx | poolie: is it very bad :( ? | 06:42 |
| poolie | no i think your revision is still there | 06:43 |
| poolie | why did you reconfigure then uncommit? | 06:43 |
| poolie | actually | 06:43 |
| poolie | if you can see the revision you want in 'bzr log -n0 --show-ids' you should be able to just do 'bzr pull . -r revid:WHATEVER' to go back to it | 06:43 |
| chx | because... i wanted to reconfigure from the beginning, that was the only thing i wanted to do but then i saw what happened and i tried to back out | 06:43 |
| poolie | i'm not sure if that's what you're already trying to do in the last line? | 06:44 |
| chx | i pulled the uncomitted revision back yes | 06:44 |
| chx | i have the lost revisions there yes but if i commit that again then i will have all the "newer" revisions under that one id | 06:44 |
| chx | ie the 'official' number will be 18091.1.25 instead of 18116 :( | 06:45 |
| poolie | hm, you don't need to commit after a pull | 06:45 |
| chx | a very 'hatchet' solution would be to uncommit 18093 and 18092 and then (with some script?) commit back the revisions one by one and then finally commit whatever 18092 contained. | 06:46 |
| chx | (which i have saved anyways) | 06:47 |
| fullermd | That would be really hatchetish... | 06:47 |
| fullermd | From the description, it sounds like all you did was merge trunk into a feature branch and pushed it. The way back is just to create a copy of trunk as it was, push --overwrite it, then merge your branch into trunk and push it from there. | 06:48 |
| poolie | just looking at it | 06:48 |
| poolie | yes, it seems like what fullermd says is correct | 06:48 |
| chx | fullermd: as it was? but how can i get trunk as it was??? | 06:48 |
| fullermd | Create a new tmp branch from 18091.1.25 (or whatever the latest that was trunk is), and push --overwrite that over turnk. | 06:49 |
| fullermd | The old revs are still there; they aren't subsumed or anything, they just have a different number because of the way things are organized now. | 06:49 |
| poolie | let's just make sure we have the right thing before we overwrite it | 06:49 |
| poolie | correct | 06:49 |
| chx | 18091.1.26 was the last. | 06:50 |
| fullermd | 'k. So, `bzr branch -r18091.1.26 $MINE tmp`. Then look at tmp; it should look like trunk did beforehand. | 06:50 |
| chx | ooooh pretty! | 06:51 |
| chx | it does. | 06:51 |
| * chx dances | 06:51 | |
| poolie | :) | 06:52 |
| chx | revno: 18117 [merge] | 06:52 |
| chx | YAY | 06:52 |
| chx | now...? | 06:52 |
| chx | bzr push --overwrite lp:examiner? | 06:53 |
| fullermd | Yes, that should stuff it back to where you were beforehand. | 06:53 |
| chx | and then what i should rtfm about these X.Y.Z revision numbers? Saw them during merging before, but honestly never understood 'em. | 06:53 |
| fullermd | Then you can either (a) merge $MINE, accepting the 'extra', 'unnecessary' merge rev on top, or (b) merge $MINE before the merge of trunk, making it as if you were just landing the feature branch, then push that. | 06:54 |
| chx | poolie: hm, so all i can do is deactivate you, can't delete? oh well. | 06:55 |
| fullermd | Try looking at <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering>. If it doesn't help... well, I don't have time to do anything about it, sadly, but I'd still like to know about it. | 06:56 |
| chx | catastrophe averted. thanks fullermd and poolie. | 06:57 |
| fullermd | Sweet. Now I can go _cause_ a catastrophe, and the scales will balance out. | 06:58 |
| chx | so basically i created a branch ( which was not my intention ) merged in trunk and then made that branch the mainline somehow? | 06:59 |
| * chx is crafty. | 06:59 | |
| poolie | it sounds like you crafted a branch which was trunk merged into you, and pushed that over trunk | 07:00 |
| chx | poolie: how did i manage to do that without push --overwrite? | 07:00 |
| fullermd | Because you weren't overwriting anything; the revision tree you were pushing was a superset of the one already existing. | 07:02 |
| fullermd | It just happened to be one where some of the revs previously on the mainline were "off to the side". | 07:02 |
| chx | so is this a bug, a misfeature or should i just buzz off? | 07:05 |
| fullermd | Well, it's neither of the prior... maybe it's a 'gotcha'. | 07:06 |
| fullermd | Think of it as an emergent property of the nonlinearity of history. | 07:07 |
| chx | lol, i come from a socialist country even those had a linear history it was just changing in time :p | 07:08 |
| chx | There is an append_revisions_only branch configuration variable which can be set to help this; it will make bzr refuse to do any operations that would change the mainline | 07:09 |
| * chx digs where those things are set | 07:09 | |
| fullermd | There's a 'config' command (new in 2.3, I think?). I don't know if it works remotely. | 07:09 |
| poolie | yeah, i was going to suggest that | 07:10 |
| fullermd | If not, you can probably do it on LP via some sftp'ing and manual editing of the branch.conf. Not difficult, though a step or two above trivial. | 07:10 |
| poolie | 'config' should work remotely | 07:10 |
| chx | fullermd: questions. if i just change branch.conf and commit -- works? | 07:10 |
| chx | ah | 07:10 |
| chx | understood. | 07:10 |
| fullermd | Well, you need to change the branch.conf on LP, since that's where somebody might be push'ing too. | 07:10 |
| chx | if i set append_revisions_only then uncommit will stop working? | 07:11 |
| fullermd | Yes, that's one of the effects; since uncommit pops off the top commit, it removes something from the mainline. | 07:11 |
| fullermd | (uncommit of stuff that gets to LP, of course; it won't affect what you do on an unconnected local branch of it) | 07:11 |
| chx | https://bugs.launchpad.net/bzr/+bug/605067 | 07:12 |
| chx | i want this it seems. | 07:12 |
| chx | probably last question, can bzr push --overwrite cause data loss? | 07:15 |
| fullermd | Semantic quibbles aside, yes. | 07:16 |
| fullermd | push alone will refuse to work if the result of making the remote branch a duplicate of your local would result in revisions that were previously in it no longer being so. --overwrite becomes a "do-it-anyway" | 07:16 |
| poolie | so | 07:17 |
| poolie | you can normally get back from that by using 'bzr heads' but it is basically a --force type option | 07:17 |
| * fullermd crams a couple more 'result's in that sentence, just for fun. | 07:17 | |
| fullermd | Yeah. It doesn't actually _remove_ the "lost" revs from the repo, but they're no longer in the branch, and you'd have to know that they're there and explicitly look for them to find them. | 07:18 |
| chx | poolie: that was an answer to push --overwrite? | 07:19 |
| chx | poolie: i feel much safer if yes. | 07:19 |
| fullermd | So, technically speaking, they're not quite really disappeared from existence, but it's the next best (worst?) thing. | 07:20 |
| chx | so there is bascailly no 'nuclear' option that would remove a revision for good from the repo? | 07:21 |
| fullermd | It's pretty much the same as when you uncommit; the rev you popped off is still _there_, but it's no longer connected to the branch. You can recover it, but you have to know it's there and go looking for it. | 07:21 |
| fullermd | (after all, uncommit isn't at the branch/repo level any different than push --overwrite'ing yourself ;) | 07:21 |
| fullermd | Not at the UI level currently. | 07:22 |
| fullermd | Actually, there was a PoC-ish 'gc' plugin at one time, I think. No idea if it still works (or if it ever worked well enough to really be used) | 07:24 |
| chx | You know? I am glad. | 07:24 |
| chx | :) | 07:24 |
| fullermd | Pbbt. You just wait'll the next time you commit a 10 gig coredump :p | 07:25 |
| chx | We are PHP developers... | 07:25 |
| chx | We commit PHP files and puppet config files. | 07:26 |
| chx | so hopefully no 10gigs. | 07:26 |
| fullermd | I was doing a data import thing some years back (in PHP). | 07:27 |
| fullermd | Working on the code for the import was tricky. And parsing the input data files took a long time (minutes), so it was real slow testing out the post-parse code. | 07:27 |
| chx | ( I know what you are thinking, this si a php developer that's why he is so clueless, i am learning python, but currently php puts bread on the table ) | 07:27 |
| fullermd | I figured I could shortcut it by just doing the parse one, serialize()'ing out the parsed array, and writing a little script that just had that serialization assigned to a var, deserialized it, and went on its merry way. | 07:28 |
| fullermd | (obviously, a brilliant plan. But then, I thought of it, so naturally...) | 07:28 |
| chx | lol. | 07:28 |
| fullermd | Turned into about an 80 meg .php script for testing; just a $foo = "longassstring"; $foo_a = unserialize($foo); basically. | 07:28 |
| chx | NICE. | 07:28 |
| * chx hands include to fullermd | 07:29 | |
| fullermd | So far, so good. Then I tried running it, just to see how much faster it was than re-parsing the files every time. | 07:29 |
| fullermd | It ran for 4.5 hours, then blew out the 512 meg memory limit. | 07:29 |
| chx | if my memory is correct it takes three times as much memory as the original structure | 07:29 |
| fullermd | ... so I went back to blowing a couple minutes every test run. | 07:30 |
| chx | 4.5 hours????? that was one particularly speedy machine. did you run it on a 386 :P ? | 07:30 |
| fullermd | Not especially speedy, but it was a dual Athlon TBird. Not quite pokey. | 07:30 |
| fullermd | Yeah. I was floored. Obviously unserialize had some minor pessimizations somewhere along the line... | 07:30 |
| vila | chx: don't blame his OS, it gets things done ;) | 07:31 |
| chx | pessimization rotflmao | 07:31 |
| fullermd | After about 5 minutes I realized it wasn't going to work, but at that point I just HAD to know how long it would finally take... | 07:31 |
| chx | fullermd: you do not need to praise php to me -- after all i run the blog phpwtf.org | 07:31 |
| fullermd | In retrospect I should have tried JSON'ing it out; that would probably have worked better. But I needed to get on with it. | 07:32 |
| lifeless | because why have one problem when you can have two? | 07:32 |
| fullermd | Piffle. All problems can be solved by creating another layer of abstraction. | 07:33 |
| chx | Yesss | 07:33 |
| chx | http://www.phpwtf.org/numeric-and-integer-keys i think this is my favorite php feature. | 07:33 |
| fullermd | I've had its confusing of reference and referent bite me once or twice. | 07:34 |
| poolie | hi vila | 07:34 |
| poolie | nice answer there | 07:34 |
| chx | creating an array which has inacessible values with [] that's classy even for php. | 07:35 |
| vila | poolie: hey ! Pfew, thanks, I wasn't sure about the tone ;) | 07:44 |
| vila | poolie: err, your were referring to the OOM bug right ? | 07:45 |
| poolie | yes | 07:45 |
| vila | just checking :) Sometime telepathy doesn't work *that* well online... | 07:46 |
| * fullermd knew you were going to say that... | 07:46 | |
| bialix | bonjour vila | 08:04 |
| vila | bialix: !!! hey ! | 08:04 |
| bialix | :-) | 08:04 |
| * fullermd waves at bialix. | 08:04 | |
| vila | I was hoping to catch you here yesterday | 08:04 |
| * bialix warmly waves back | 08:04 | |
| vila | bialix: can you find a couple of minutes to speak about the configobj fix ? | 08:04 |
| poolie | hi bialix | 08:05 |
| bialix | vila: I had business trip yesterday | 08:05 |
| bialix | hi poolie | 08:05 |
| bialix | poolie: the big island is okay? | 08:05 |
| * bialix saw the bad news from New Zealand | 08:05 | |
| poolie | heh | 08:05 |
| poolie | well, if you don't count the fires, floods, and cyclones, yes | 08:06 |
| bialix | :-/ | 08:06 |
| bialix | vila: yes, I'd like to talk with you about configobj | 08:06 |
| bialix | vila: I'm not quite get your comment on MP | 08:06 |
| poolie | it's ok though :-) http://en.wikipedia.org/wiki/Severe_Tropical_Cyclone_Yasi | 08:06 |
| vila | bialix: in the test, you seem to mention a *different* but in configobj that requires splitting lines or something (let me refresh the page) | 08:07 |
| poolie | ok, i should go | 08:07 |
| vila | poolie: enjoy your evening ! | 08:08 |
| poolie | i'm going to be offline for a week | 08:08 |
| poolie | thanks | 08:08 |
| vila | poolie: and your riding :) | 08:08 |
| poolie | thanks | 08:08 |
| lifeless | poolie: your pqm is whinging | 08:08 |
| lifeless | WARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not fetchable due to <class 'urllib2.URLError'>: <urlopen error [Errno 101] Network is unreachable> | 08:08 |
| lifeless | oh | 08:09 |
| lifeless | no not yours | 08:09 |
| poolie | huh | 08:09 |
| lifeless | lp's is | 08:09 |
| poolie | that's a bit naughty | 08:09 |
| lifeless | I saw the sphinx bit and leapt to a conclusion | 08:09 |
| poolie | jml(?) is trying to use it in lp too | 08:09 |
| fullermd | I think that means you incorrectly answered the Riddle, and it gets to eat you now... | 08:10 |
| vila | bialix: the other bit is that a comment for your fix in configobj will ensure the next merge can be done without too much additional knowledge about why this fix should stay in place | 08:10 |
| vila | fullermd: hehe | 08:10 |
| bialix | vila: the comment about not splitting the lines there because it bites me | 08:12 |
| bialix | vila: it bites me while I've been coding that test | 08:12 |
| vila | bialix: but is it triggered only in this test or can it *also* occur in bzr ? | 08:13 |
| bialix | I think I can use just another StringIO() wrapper instead of lines to read the config back | 08:13 |
| bialix | vila: one sec | 08:13 |
| bialix | vila: look at bzrlib/util/configobj/cobfigobj.py line 1975 | 08:14 |
| vila | close, I was at 1971 :D | 08:15 |
| bialix | vila: this is only affects test | 08:15 |
| vila | but yeah I noticed this comment after you said you could use a StringIO | 08:15 |
| vila | ha good ! | 08:15 |
| vila | bialix: and is it still there if you use a StringIO ? | 08:15 |
| bialix | vila: no of course | 08:16 |
| vila | I remember configobj being so helpful sometimes with accepting different inputs transparently it hurt :) | 08:16 |
| bialix | I've been meaning to use lines for self.assertEquals | 08:16 |
| bialix | but then I did not | 08:16 |
| bialix | vila: what should I do? | 08:17 |
| bialix | do you want me to fix this part to use StringIO instead? And send bug report to mfoord? | 08:17 |
| vila | ideally: at minimum: at comments on both subjects (and I'll land that), then see if you can work around the bug in the test and/or file the bug upstream (and then includes the bug number in the comment... meh, bad circular dependency there >-/) | 08:18 |
| vila | break the circle: just say the test bug will reported upstream and do a followup submission against trunk once the fix get there | 08:19 |
| vila | s/will/will be/ | 08:19 |
| vila | bialix: then, there is the higher level discussion about how qbzr should get away from configobj entirely and what is currently missing in bzrlib.config that blocks this goal | 08:20 |
| vila | bialix: that may includes support for commit data in branch.conf | 08:21 |
| vila | bialix: and if you could stop using dict values for config options I won't ask for a ponny :D | 08:21 |
| bialix | I can't | 08:21 |
| bialix | dict values provide me atomic transaction | 08:22 |
| vila | never say I can't :D | 08:22 |
| vila | it's the other way around: you could if... | 08:22 |
| vila | bialix: when you say "I can't" I feel sad, if you say "I could if" I'm willing to help and that's far better for my karma :D | 08:24 |
| bialix | well, let's don't talk about qbzr right now | 08:24 |
| bialix | because the bug reporter has started long thread about what we should and should not do in qbzr, and then Gordon said we should store those data not in branch.conf | 08:25 |
| vila | well, if you don't talk about it right now, I won't be able to address the need tomorrow either (for extended values of tomorrow ;) | 08:25 |
| vila | indeed | 08:25 |
| bialix | if we talk about qbzr then I have to say that using branch.conf was/is horribly bad idea | 08:26 |
| vila | the plan with bzrlib.config is to reach the point where a given config file is read once and written once for any given bzrlib operation (the higher level the operation the better), | 08:26 |
| bialix | because commit_data should be stored in the tree.conf | 08:26 |
| vila | as opposed to read for each option and written for each option | 08:27 |
| bialix | or at least inside .bzr/checkout | 08:27 |
| vila | yup | 08:27 |
| vila | tree.conf ftw | 08:27 |
| bialix | but when we did what we did there was no tree.conf | 08:27 |
| vila | indeed, not throwing stones (or I should throw them at bzrlib.config) | 08:28 |
| bialix | what is best strategy for qbzr? | 08:28 |
| vila | (and I dislike working on code under a stone rain) | 08:28 |
| bialix | can we use tree.conf now, or we should store our data in the different file? | 08:28 |
| vila | bialix: try to converge to bzrlib.config and nag me when you encounter bugs | 08:28 |
| bialix | that part of code is already using bzrlib.config | 08:29 |
| vila | migrating from one file to another will *most* probably involve some kind of migration, so let's try to have a single migration | 08:29 |
| vila | bialix: oh, when I say use bzrlib.config I imply do not touch configobj *at all* | 08:30 |
| vila | no _get_parser() calls either | 08:30 |
| bialix | def _set_new_commit_data(self, new_data): | 08:31 |
| bialix | config = self._get_branch_config() | 08:31 |
| bialix | old_data = config.get_user_option('commit_data') | 08:31 |
| bialix | if old_data == new_data: | 08:31 |
| bialix | return | 08:31 |
| bialix | try: | 08:32 |
| bialix | config.set_user_option('commit_data', new_data) | 08:32 |
| bialix | except AttributeError: | 08:32 |
| bialix | pass | 08:32 |
| bialix | vila: there is no _get_parser() calls! | 08:32 |
| bialix | vila: qbzr/lib/commit_data.py | 08:32 |
| vila | bialix: right | 08:34 |
| bialix | too bad we have not reached any agreement with bzr-gtk about joining our efforts re commit-data | 08:34 |
| bialix | I'd be happy to see some common code, even inside bzrlib, to support that | 08:34 |
| vila | bialix: I think we have agreement from all parties involved :D It's just that nobody found the time to assemble a mp against bzr.dev... | 08:34 |
| bialix | I don't remember any bzr-gtk dev ever commented on my proposal | 08:35 |
| vila | bialix: the problem with _set_new_commit_data is that it's using a dict value for an option | 08:35 |
| bialix | bzr-gtk uses bencoded value | 08:35 |
| bialix | using dict was abentley idea | 08:35 |
| vila | bialix: huh ? I discussed this with Gary back in.... Barcelona ? (Or am I mixing sprints here ?) | 08:35 |
| bialix | vila: I'd like to have atomic write of all commit_data options | 08:36 |
| vila | bialix: the problem is that it uses sub sections relying on configobj, there are no explicit tests for that in bzr (which means no explicit support for them) | 08:36 |
| bialix | only using dict I can get atomic | 08:36 |
| vila | bialix: they are supported by configobj | 08:36 |
| bialix | we want to get rid of configobj? | 08:37 |
| bialix | I won't be upset is yes | 08:37 |
| vila | bialix: atomicity should be provided by bzrlib.config, it isn't right now | 08:37 |
| bialix | I won't be upset if yes | 08:37 |
| vila | no, we don't want to get rid of it, just use it as an implementation detail that users don't have to be aware of and don't *use* unsupported features | 08:38 |
| vila | of it | 08:38 |
| vila | bialix: so until we get bzrlib.config there, dict values will be supported but the plan is to get away from them so we can explicitly deprecate them | 08:40 |
| bialix | vila: do you want me to use bencoded dict as bzr-gtk does? | 08:40 |
| vila | bialix: that would indeed be better (if you manage to find a suitable migration strategy for it) | 08:41 |
| bialix | vila: commit_data already has migration strategy | 08:41 |
| vila | bialix: but if it means migrating for that now and migrating again later for something else, then no, not a good use of your time | 08:41 |
| vila | huh ? Which one ? | 08:41 |
| bialix | scroll down the file | 08:42 |
| vila | oh, you mean moving it into core ? | 08:42 |
| bialix | no, in the past we had different option named commit_message | 08:42 |
| bialix | then I've extended it to more rich dict | 08:42 |
| vila | hmm, interesting | 08:43 |
| bialix | so, it's not problem to make another change | 08:43 |
| bialix | but I'd like to migrate into tree.conf as well | 08:44 |
| vila | bialix: I still have a couple of things to add first: sections in all config files, config registry, config stacks, option declarations... but we'll get there | 08:45 |
| bialix | ETOOMUCHSTUFFFOR ONE MORNING | 08:45 |
| vila | the last three are pre-requisites to get to the point where we can guarantee one read/write by config file as opposed to one read/write by option | 08:46 |
| vila | aka atomic modifications | 08:46 |
| vila | all right, I've got enough feedback from you for the long term plans, thanks | 08:46 |
| vila | bialix: if you can add the comments and push, I'll take care of landing the fix in 2.2 and up to trunk | 08:47 |
| bialix | vila: to clarify: I'll change lines to pure StringIO and send bug report to mfoord, and keep the comment in the test | 08:48 |
| vila | yup, and add one above the fix for future merges | 08:48 |
| bialix | vila: do you want me to add corresponding comment about the fix in configobj.py as well? | 08:48 |
| vila | yup | 08:49 |
| bialix | ok, got now | 08:49 |
| bialix | doing now | 08:49 |
| montywi | poolie: 'bzr check' still running, after 12 hours... | 09:16 |
| vila | montywi: not unsurprising, the emphasis is on making sure all data relationships are valid, not on speed | 09:17 |
| vila | montywi: it's unfortuante in your case that there aren't options for quicker and more focused checks though | 09:17 |
| montywi | still, no it's so slow that it's unusuable | 09:17 |
| montywi | I am sure that with a little bit of caching one could make this 1000x faster | 09:18 |
| vila | montywi: s/no/now/ ? | 09:18 |
| vila | montywi: sure | 09:18 |
| vila | montywi: hence my remark | 09:18 |
| montywi | yes, now | 09:18 |
| montywi | still, a full check is very useful when you suspect something is wrong | 09:18 |
| vila | montywi: check is targeted at corrupted data in *unknown* ways, caching may be tricky and should be done with care | 09:19 |
| vila | montywi: exactly | 09:19 |
| vila | montywi: but sometimes you can have good guesses at what you want to check and checking everything and the kitchen sink is not what you want ;) | 09:20 |
| montywi | having a simple cache where you store 'file name' + file block of 8K' would save you millons of open + seek + read+close | 09:20 |
| vila | montywi: patches welcome :D | 09:20 |
| montywi | I know ;) | 09:20 |
| montywi | Still, mariadb development takes much of my time and it's better to code the things you know most about... | 09:21 |
| vila | montywi: I wholeheartedly agree anyway, I try to do that the whole day every day, smaller checks still hasn't reached the top of my stack so far... :-/ | 09:22 |
| montywi | but if I get a pause, I may look at this as the fix should be relatively easy | 09:22 |
| montywi | and I 'really' would like to know if my repro is ok or now; Now I have no way of knowing as I will not have the time to let this finnish | 09:23 |
| vila | montywi: I think lifeless was the last one working on that and he did put in place some infrastructure to enable that kind of focused checks | 09:23 |
| vila | montywi: urgh, can't you duplicate it ? | 09:23 |
| vila | hmm, too late for that I suspect... | 09:24 |
| montywi | Yes, I am considering moving the repro to another computer to run thecheck | 09:24 |
| montywi | now running bzr check on another computer that I don't need for the next 2-3 days. Hope it finishes... | 09:27 |
| vila | montywi: hehe, oh, it should finish... or crash :) | 09:31 |
| vila | montywi: but back to your original issue, did you try to commit from the command line instead of gcommit ? | 09:31 |
| bialix | vila: please check my changes in https://code.launchpad.net/~bialix/bzr/2.2-configobj/+merge/50507. If they're ok for you I'll update 2.3 branch as well | 09:32 |
| montywi | after it failed onces, I tried bzr commit and bzr gcommit and both worked | 09:32 |
| montywi | i have now taken a full copy of my repro and will continue to keep the backup up to dates so that if/when it happens again I can reproduce it | 09:32 |
| vila | montywi: 8-/ The error message was quite obscure, but now if it was spurious on top of that... | 09:33 |
| vila | montywi: good, thanks | 09:33 |
| vila | bialix: p-e-r-f-e-c-t | 09:34 |
| bialix | you're too kind to me | 09:34 |
| vila | bialix: I'll land in 2.2 and up to trunk, if you update your 2.3 branch, I'll use it, otherwise I'll do it myself, just let me know | 09:35 |
| bialix | one sec | 09:35 |
| bialix | vila: 2.3 done too | 09:49 |
| vila | cool, 2.2 one pqmed, I'll wait for it to aggregate up to trunk | 09:50 |
| bialix | vila: merci | 10:10 |
| cbz | Is bzr-eclipse the only eclipse plugin for bzr? | 10:11 |
| vila | cbz: no I think there is a qbzr-based variant which is better | 10:12 |
| vila | . o O (I could swear someone nicked cb??? asked this same question less than a week ago...) | 10:12 |
| cbz | vila: it looks like it hasn't been developed in a while .. | 10:13 |
| vila | which one ? | 10:14 |
| cbz | https://launchpad.net/qbzr-eclipse/ ? | 10:14 |
| vila | then it works reaaally well or is not maintained, I can't answer that one ;) | 10:16 |
| vila | but nick allen rings a bell, I'm pretty sure he's still active in the bzr community, may be not on the plugin, try the ml to get more feedback | 10:17 |
| vila | and the last update seems to be dated 2010-11, so I won't qualify that as 'hasn't been developed in a while' | 10:18 |
| vila | cbz: finally, from the url you gave above: https://answers.launchpad.net/qbzr-eclipse/+question/145746 | 10:19 |
| cbz | thanks | 10:24 |
| vila | jelmer: pingeling about babune and reviews ;) | 10:24 |
| amanica | cbz: I use qbzr-eclipse every day and it works fine. bzr-eclipse stopped working for me some time ago then I switched. | 10:26 |
| vila | amanica: wow, hey guy ! Long time not seen ! | 10:27 |
| cbz | amanica: thanks | 10:27 |
| amanica | vila: hi! have been busy :) | 10:27 |
| cbz | amanica: bzr-eclipse seems to work for me, it's just that it doesn't integrate very well into eclipse | 10:28 |
| vila | I sure hope so :) | 10:28 |
| amanica | cbz: yes I understad, I liked the other one too, but on the other hand, I like the qbzr dialogs | 10:29 |
| pfarrell | hi. I'm on ubuntu maverick. for some reason when I commit to my repository over bzr+ssh, a notification window pops up in the rhs of my screen, with details of my commit. it isn't obvious what process controls it or is putting it there. what I'd really like to know is when my collaborator pushes to /his/ repository -- can that be done? | 10:30 |
| cbz | amanica: thats odd - i installed it, but it doesn't seem to add bazaar to the 'share project' vcs options | 10:32 |
| vila | pfarrell: this sounds like bzr-notify plugin, IIRC it's based on DBus so little chance that it can track changes on lp, but check the questions/bugs at lp:bzr-notify or file a bug there | 10:33 |
| vila | https://launchpad.net/bzr-notify | 10:33 |
| vila | bah | 10:34 |
| cbz | ah - orythogonal | 10:34 |
| amanica | cbz: where are those options? I mainly use commit, diff, push, pull etc. | 10:34 |
| pfarrell | vila: ok, thanks | 10:35 |
| vila | wrong url, https://launchpad.net/bzr-dbus exists though, so the notification thing should come from.. bzr-gtk maybe ? | 10:35 |
| amanica | cbz: normally I set up everything on the commandline, but its nice to commit straight from the ide | 10:35 |
| pfarrell | I do have bzr-gtk installed, maybe that's it | 10:35 |
| vila | pfarrell: and bzr-dbus ? | 10:35 |
| pfarrell | yep, bzr-dbus too | 10:35 |
| vila | I thought you needed some config to activate it, I should look into that.... when time permits ;-/ | 10:36 |
| vila | pfarrell: now, you should also be able to subscribe to your mate branch at lp, but the notification will be mail based instead... | 10:37 |
| pfarrell | oh, we're not using launchpad | 10:43 |
| pfarrell | but thanks for the tip | 10:43 |
| vila | pfarrell: oh, ok | 10:43 |
| vila | pfarrell: hmm, I think the original idea for bzr-dbus was to allow this kind of notifications in a local network anyway (like in sprints) but I lose track of what was/wasn't implemented to reach that goal | 10:44 |
| vila | pfarrell: so exposing your use case on lp:bzr-dbus is the best you can do to help making it supported ;) | 10:45 |
| pfarrell | :-) | 10:46 |
| lifeless | bzr-dbus + bzr-gtk can do lan notificaitons | 10:46 |
| lifeless | broadcast pickup and transmit | 10:47 |
| vila | pfarrell: ha ! listen to lifeless :D | 11:03 |
| pfarrell | lifeless: is there an example anywhere? | 11:04 |
| cdbs | I am having a wierd problem with bzr. http://paste.ubuntu.com/570524/ Please see this | 11:33 |
| cdbs | I tried everything, but bzr add simply doesn't work on those two folders | 11:33 |
| cdbs | it works on other files. I created a dummy file, bzr added it and it worked | 11:33 |
| cdbs | but not those two folders | 11:33 |
| cdbs | I don't have a .bzrignore | 11:34 |
| vila | cdbs: what does 'bzr ignored' says | 11:34 |
| cdbs | vila: well, I do have a bzrignore, this is bzr ignored output: http://paste.ubuntu.com/570527/ | 11:35 |
| cdbs | vila: bzrignore is a small 2 line file which I wrote myself. None of it is currently mathing those 2 folders | 11:35 |
| cdbs | I am using Ubuntu Natty, so could python 2.7 be a problem causer? | 11:36 |
| cdbs | just tried running bzr with python 2.6, same problem | 11:36 |
| cdbs | can't find a bug with a similar problem | 11:37 |
| vila | but are there files to be added below these dirs ? | 11:37 |
| cdbs | I also tried bzr pack , and tried again | 11:37 |
| vila | bzr pack is totally unrelated ;) | 11:37 |
| cdbs | vila: no, all the other files below these DIRs have been added | 11:37 |
| vila | huh ? | 11:38 |
| cdbs | vila: I mean, all the files below these directories were already added in previous commits | 11:38 |
| vila | if some files are versioned *below* these dirs, they shouldn't be unknown | 11:38 |
| vila | what does 'bzr ls' says | 11:38 |
| vila | bzr ls -R that is | 11:39 |
| vila | or just 'bzr ls' but inside these dirs | 11:39 |
| cdbs | vila: https://code.launchpad.net/~bilalakhtar/hall-of-fame/my-work/ is the repo on Launchpad, pushed uptil the latest commit | 11:39 |
| cdbs | vila: okay, pasting that now | 11:39 |
| cdbs | vila: http://paste.ubuntu.com/570530/ | 11:40 |
| cdbs | I also did bzr add src/ubuntu_website/* | 11:40 |
| cdbs | no change | 11:41 |
| vila | and what does a regular 'ls -al' says in ubuntu_website ? | 11:41 |
| cdbs | vila: aha! | 11:42 |
| cdbs | vila: there is a .bzr directory in ubuntu_website! | 11:42 |
| cdbs | got it! | 11:42 |
| cdbs | thanks | 11:42 |
| vila | you're welcome ;) | 11:42 |
| cdbs | wierd, when I did ls -R | grep bzr earlier, there was no output | 11:42 |
| cdbs | except for the usual dirs | 11:42 |
| * vila lunch now | 11:43 | |
| lelit` | hi all, I'm facing a problem with a bzr repository, where "bzr annotate" gives me a KeyError on a very old commit | 12:13 |
| lelit` | googling around, I see it may be related to bzr-svn, which I used, very early in proj history when its master was kept under svn | 12:15 |
| maxb | If you pastebin the full traceback, which you can probably find in ~/.bzr.log - or, you can get on the console by running the command again with the -Derror flag - people here can help diagnose | 12:15 |
| lelit` | here is a summary, done on a fresh clone of my master repo: http://pastebin.com/t2Yd4mWX | 12:24 |
| lelit` | as said, it may be that at that time (that is, december 2009) I used bzr-svn for a while on this repo | 12:26 |
| jelmer | lelit`: it might be a bug in annotate dealing with ghosts | 12:31 |
| lelit` | hi jelmer, thx. Is there anything I can do to either fix the repo, or to workaround the problem? | 12:32 |
| lelit` | afk, later | 12:36 |
| vila | maxb, jelmer: I've lost track: do we still carry our own configobj in bzrlib.util for ubuntu or not ? | 12:43 |
| jelmer | lelit`: bug 438959 | 12:43 |
| ubot5 | Launchpad bug 438959 in Bazaar "annotate breaks on ghost text revisions" [Medium,Confirmed] https://launchpad.net/bugs/438959 | 12:43 |
| jelmer | vila: we do | 12:43 |
| vila | cool | 12:43 |
| maxb | We do? | 12:43 |
| maxb | jelmer: But you deleted it? | 12:43 |
| jelmer | uhm, sorry | 12:44 |
| jelmer | we do still patch it | 12:44 |
| === Kraln- is now known as Kraln | ||
| vila | bialix fixed an issue there that has a fallout for 2 tests | 12:44 |
| maxb | Yes, but on ubuntu, we delete our patched version and use the system :-/ | 12:44 |
| vila | err, you lost me there | 12:44 |
| jelmer | vila: so we no longer include bzrlib.util.configobj | 12:44 |
| vila | argh | 12:44 |
| jelmer | maxb: we patch bzrlib to use the system configobj is what I meant | 12:45 |
| jelmer | sorry for all the confusion | 12:45 |
| maxb | I am tempted to suggest reintroducing our private and fending off complaints about embedded libraries by explaining it's a fork | 12:45 |
| vila | +1 | 12:45 |
| vila | I'm currently blocked otherwise | 12:45 |
| jelmer | vila: in what way is ours patched? | 12:46 |
| vila | we run the tests for Ubuntu only and they will fail for bzr >= 2.3.1 | 12:46 |
| maxb | I recall there being a comment noting that we've cut bits out we didn't need to optimize startup time | 12:46 |
| vila | see https://code.edge.launchpad.net/~bialix/bzr/2.3-configobj/+merge/50511 | 12:46 |
| vila | maxb: the new fix is not available upstream (yet) AIUI but has been devised with upstream input | 12:47 |
| jelmer | vila: that fix seems like it should make it into upstream configobj as well | 12:47 |
| maxb | even without this fix, there's still the issue that our configobj has bits cut out to optimize startup time | 12:48 |
| vila | but I can't land it in bzr/2.3 | 12:48 |
| vila | maxb: less problematic than FTBS no ? | 12:48 |
| vila | F | 12:48 |
| maxb | vila: Presumably you can land it, but we need to decide what to do about the debuntu packaging before 2.3.1 ? | 12:49 |
| jelmer | maxb: when profiling I haven't seen anything to indicate that optimization actually matters | 12:49 |
| vila | pqm rejected it because two tests failed (''' and """ are toggled in configobj output) | 12:49 |
| jelmer | for natty, I think we should get upstream configobj patched | 12:49 |
| maxb | jelmer: Fair enough - if so, we should back out the customization from our local configobj copy | 12:49 |
| vila | I can trivially fix the tests but they would fail again if an unpatched configobj is used during the build tests | 12:49 |
| vila | jelmer: I would prefer to get the patched configobj available everywhere we need it *before* removing util.configobj from our packages | 12:51 |
| vila | and even better get our other fixes upstreamed and be able to rely on the upstream version once and for all | 12:52 |
| jelmer | vila: the debian/ubuntu packages have used the system configobj since 2.1.0~rc2-1, though they still shipped the bzr copy of it | 12:53 |
| jelmer | vila: this fix is new, and I think we should get it upstreamed for the natty/sid packages | 12:55 |
| vila | jelmer: the problem is that I either 1) don't land bialix fix 2) land it with the additional test fixes knowing the 2.3.1 won't be pass the tests | 12:55 |
| jelmer | vila: Do you mean the packaging of 2.3.1 build ? | 12:56 |
| vila | jelmer: sent: https://bugs.edge.launchpad.net/bzr/+bug/710410/comments/9 but no url... | 12:56 |
| vila | jelmer: yeah sorry | 12:56 |
| jelmer | vila: Don't worry about that, that's the packagers responsibility - I don't think we should complicate our upstream work because of it. | 12:57 |
| vila | hmm, so you mean I should land with fixed tests then, right, wfm | 12:58 |
| vila | jelmer: right and since I will then merge that into trunk, expect the daily build to fail too | 13:00 |
| jelmer | vila: that's fine, it's what packaging is about :) | 13:01 |
| vila | jelmer: indeed, I was realizing that only Ubuntu was affected by the issue because... of two packaging decisions (remove configobj, run tests during build) | 13:02 |
| bialix | vila: what's wrong with my test? | 13:20 |
| vila | hmm, still, qbzr may continue to encounter bug #710410 if bzr doesn't use a patched configobj | 13:21 |
| ubot5 | Launchpad bug 710410 in Bazaar trunk "ConfigObj is able to write bad branch.conf which is not possible to read back" [High,In progress] https://launchpad.net/bugs/710410 | 13:21 |
| vila | bialix: not yours, other ones | 13:21 |
| vila | bialix: 2.3 added some tests for multi-lines values | 13:21 |
| bialix | point me please | 13:21 |
| vila | bialix: and your patch toggles the quotes used in this case (''' <-> """) | 13:21 |
| bialix | oops, sorry | 13:22 |
| vila | bialix: lp:~vila/bzr/2.3-integration | 13:22 |
| bialix | I think I've ran all test_config tests | 13:22 |
| bialix | but maybe I did not | 13:22 |
| vila | bialix: hehe, blackbox ones :) | 13:22 |
| bialix | aaaa | 13:22 |
| vila | -s bt.test_config -s bb.test_config | 13:22 |
| bialix | sorry | 13:22 |
| vila | bialix: no worries, I fall in this trap *very* often even when working on config myself... | 13:23 |
| bialix | :-/ | 13:23 |
| vila | bialix: that's why we have pqm :D | 13:23 |
| vila | and babune | 13:23 |
| bialix | yeah | 13:23 |
| vila | of course it will help if I was receiving pqm emails... | 13:23 |
| bialix | babune rocks | 13:23 |
| vila | bialix: and windows stay blue ! | 13:24 |
| bialix | the hard working monkey | 13:24 |
| bialix | coool | 13:24 |
| vila | bialix: the only regression there have been related to bash completion and even there it started running tests it shouldn't have ;) | 13:25 |
| vila | s/there have been/there, have been/ | 13:26 |
| bialix | vila: I don't like that change | 13:27 |
| bialix | I think I can fix the configobj to preserve the old behavior, so you don't need to patch your tests | 13:28 |
| bialix | I think double quotes is more appropriate for Human Beings by defauklt | 13:28 |
| bialix | I think double quotes is more appropriate for Human Beings by default | 13:28 |
| bialix | vila: what's your mind? | 13:28 |
| bialix | vila: oops, sorry | 13:29 |
| bialix | I've mixed those | 13:29 |
| vila | bialix: I would prefer that too, if you can push this on your 2.2 branch and verify it works with -s bb.test_config in 2.3, that would wfm | 13:29 |
| vila | you mean between triple double quotes or single ones ? :D | 13:30 |
| bialix | I meant: it will be nice to have double quotes in the user output | 13:30 |
| bialix | now it is | 13:30 |
| bialix | Do you think it's good? | 13:30 |
| vila | I don't care | 13:31 |
| bialix | then I withdraw my picky note | 13:31 |
| vila | using multiline values in config files is borderline in my book anyway :D | 13:31 |
| bialix | never heard this phrase | 13:32 |
| vila | And I prefer single quotes as they still scream 'no interpolation' in my head ;) | 13:32 |
| vila | bialix: 'in my book' == 'in my private view of the world' | 13:33 |
| bialix | "borderline in my book" -- does it mean it's out of your desires? | 13:33 |
| bialix | ah | 13:33 |
| vila | bialix: 'borderline' == 'very close to being illegal or bad taste' | 13:33 |
| bialix | now I got it | 13:33 |
| vila | but that's just IMHO of course | 13:33 |
| bialix | I can change the order to pick the triple quotes for simple cases | 13:34 |
| bialix | if you insist to | 13:34 |
| vila | well, I won't ask you to go against your desires, that would be bad for my karma :D | 13:35 |
| vila | bialix: and if the fix has already found its way upstream, we'd better not diverge again | 13:36 |
| lelit` | jelmer: I see | 13:36 |
| vila | bialix: and pqm is 84% done with the 2.3 submission | 13:36 |
| vila | bialix: and.. :-D | 13:36 |
| bialix | vila: ok. let it land | 13:36 |
| bialix | give up, give up | 13:36 |
| vila | move it, move it | 13:37 |
| vila | bialix: landed in 2.3 | 13:50 |
| bialix | \o/ | 13:51 |
| vila | bialix: trunk pqmed | 13:52 |
| bialix | yay | 13:52 |
| bialix | vila: so, do you say there is no tree.conf yet? | 13:55 |
| vila | there is no tree.conf yet | 13:56 |
| vila | I want a tree.conf | 13:56 |
| bialix | it was not clear for me | 13:57 |
| bialix | you said there is too much config | 13:57 |
| bialix | files | 13:57 |
| vila | haha | 13:57 |
| vila | you're right :) | 13:57 |
| vila | I meant that some config files could be merged into existing ones (there cases where we don't want that though) and there are some missing files | 13:58 |
| vila | s/there/there are/ | 13:58 |
| bialix | something like that | 13:58 |
| vila | see ? It's all far clearer with a little hand-waving :D | 13:59 |
| bialix | but without that waving you don't have a magic | 13:59 |
| === zyga is now known as zyga-food | ||
| * jelmer takes a look at lp:udd | 14:23 | |
| vila | jelmer: \o/ | 14:29 |
| * bialix waves at jelmer | 14:35 | |
| bialix | jelmer: any suggestion re http://pastebin.com/k9AeJ1j9 ? | 14:36 |
| Gorkyman | hey guys... | 14:36 |
| Gorkyman | need some guide for setting bzr on server... smth for dummies i gues : ) | 14:36 |
| === zyga-food is now known as zyga | ||
| maxb | List your basic requirements and what you've looked at so far. There is some material in the Bazaar documentation, e.g. http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/index.html | 14:38 |
| jelmer | maxb: did you see 614544: bzr: FTBFS ? | 14:43 |
| maxb | see, yes. | 14:43 |
| * maxb actually reads | 14:43 | |
| jelmer | basically, the launchpad tests require internet access | 14:43 |
| maxb | ah yes. fail | 14:44 |
| maxb | are those new, or why aren't they failing in daily builds?# | 14:44 |
| maxb | jelmer: On a semi-related note, how would you feel about running selftest with -v in debian/rules, so you can see what tests ran in a buildlog? | 14:45 |
| jelmer | the daily builds have access to launchpad I think | 14:45 |
| maxb | oh dear that is comedy fail | 14:45 |
| maxb | I'm pretty sure they're not supposed to | 14:46 |
| jelmer | I'm going to upload a new copy with the launchpad plugin disabled during the tests for the moment | 14:46 |
| maxb | That makes sense - I don't think that plugin does much which doesn't involve network access anywy | 14:46 |
| jelmer | It's only a few of the tests that fail | 14:47 |
| maxb | Maybe just deleting those tests in the packaging branch is the best workaround? | 14:48 |
| maxb | Longer term, I wonder if we could set things up so there is a "feature" of "Can successfully contact Launchpad XMLRPC" | 14:49 |
| jelmer | ideally we would just use a proper mock server | 14:50 |
| maxb | that would be even better | 14:50 |
| jelmer | maxb: s/deleting/skipping/, but yeah | 14:50 |
| === beuno is now known as beuno-lunch | ||
| === jam3 is now known as jam | ||
| jam | morning all | 16:29 |
| jam | vila: I'm trying to review https://code.launchpad.net/~vila/udd/use-new-driver/+merge/50644 | 16:30 |
| jam | but the diff is kind of hard to parse | 16:30 |
| jam | can you describe what you did a bit? | 16:30 |
| vila | sure | 16:30 |
| vila | jam: it will help if you look at the resulting mass_import.py | 16:31 |
| vila | the diff is really obfuscating the refactoring | 16:31 |
| vila | I think it should be far clearer with the script itself on my cover letter | 16:32 |
| vila | Otherwise I'll be rehashing the cover here and that doesn't sound very helpful | 16:32 |
| vila | jam: but in a nutshell, the pre-requisite mp implements a SubprocessMonitor (in a thread) and a ThreadDriver (in a thread, starting/killing/joining a number of threads) | 16:34 |
| vila | and tests | 16:35 |
| vila | this mp uses the tested features to rewrite mass_import | 16:35 |
| vila | so it's just adding the logger calls and the db related calls in the right places and get rid of all the time.sleep calls() in favor of two wait(xxx) calls | 16:36 |
| vila | which should get rid of all the race conditions | 16:36 |
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| vila | jam: thanks for the udd reviews ! | 17:52 |
| === deryck[lunch] is now known as deryck | ||
| jelmer | hey jam | 20:02 |
| jam | hi jelmerr | 21:17 |
| jam | sorry for the delay, had sound off | 21:17 |
| ovnicraft | hello i'm looking for a code review tool integrated with bzr anyone has experience ? | 21:32 |
| jelmer | hi ovnicraft | 21:33 |
| jelmer | ovnicraft: launchpad supports code reviews (and is used by bzr itself), and I believe reviewboard also supports bzr | 21:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!