pooliehi spiv00:22
spivHi poolie00:27
pooliehi there00:41
pooliehi spiv00:44
pooliei'm just about to confirm the sprint on the 16th may00:44
pooliethat's still ok with you?00:44
spivI'll double-check, just a sec01:05
spivYep, that's fine.01:05
=== marienz_ is now known as marienz
maxbpoolie: whereabouts in London are you going to be?02:52
pooliedo you want to come by?02:53
maxbnice, I could probably even come by bike :-)02:54
fullermdBlah.  I wish revert took globs...05:22
fullermdWould be handy in resurrecting piles of files.05:23
pooliehuh, nice idea05:23
quotemstrDown that road lies madness.05:27
fullermdNah, I'm right here.05:27
chxhi. 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
pooliehi chk06:21
chxpoolie: hi06:21
chxpoolie: i am in a panic pretty much.06:21
poolieit's ok06:21
pooliei'm not sure how the tags come into this y06:21
poolieso you merged trunk, and pushed your branch on top of trunk, and now you wish you hadn't?06:22
poolieare we talking about a push --overwrite, or something else?06:22
chxjust 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 mess06:23
poolieso if you do 'bzr log -n0 -r -1' does that show you all your trunk revisions?06:23
chxit does but not with the original commit numbers06:25
chxit says     revno: 18091.1.25 and it was 1811606:25
chx(I must note that 18091+25 is 116)06:25
PengRight. The revision numbers are irrelevant and depend on your point of view; the revisions are still the same.06:26
chxWell, 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
poolieso can you tell me, in order, what you did?06:26
pooliemaybe if you temporarily subscribe me (~mbp) to that branch it will help06:27
chxpoolie: http://ex.privatepaste.com/8e40d70b5e06:28
chxpoolie: added06:29
chxpoolie: in short i did everything to make sure i am messed up.06:30
chxI also failed because the Drupal community after all migrates to git not bzr on Thursday :(06:33
fullermdSo 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
fullermdWhich it does, of course.  But still, so sad, the lack of effort...06:34
chxfullermd: i think i went the extra mile by pushing committing and uncommitting.06:35
chxfullermd: even i have no idea where the hell i am.06:35
fullermdSee?  True artistry.  I doff my cap, sir.06:36
Pengchx: You made a good effort, but I've seen better.06:37
chxShould I laugh or cry?06:37
fullermdI think the only honest answer is "yes".06:38
chxpoolie: is it very bad :( ?06:42
poolieno i think your revision is still there06:43
pooliewhy did you reconfigure then uncommit?06:43
poolieif 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 it06:43
chxbecause... 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 out06:43
pooliei'm not sure if that's what you're already trying to do in the last line?06:44
chxi pulled the uncomitted revision back yes06:44
chxi have the lost revisions there yes but if i commit that again then i will have all the "newer" revisions under that one id06:44
chxie the 'official' number will be  18091.1.25 instead of 18116 :(06:45
pooliehm, you don't need to commit after a pull06:45
chxa 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
fullermdThat would be really hatchetish...06:47
fullermdFrom 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
pooliejust looking at it06:48
poolieyes, it seems like what fullermd says is correct06:48
chxfullermd: as it was? but how can i get trunk as it was???06:48
fullermdCreate a new tmp branch from 18091.1.25 (or whatever the latest that was trunk is), and push --overwrite that over turnk.06:49
fullermdThe 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
poolielet's just make sure we have the right thing before we overwrite it06:49
chx18091.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
chxooooh pretty!06:51
chxit does.06:51
* chx dances06:51
chxrevno: 18117 [merge]06:52
chxbzr push --overwrite lp:examiner?06:53
fullermdYes, that should stuff it back to where you were beforehand.06:53
chxand then what i should rtfm about these X.Y.Z revision numbers? Saw them during merging before, but honestly never understood 'em.06:53
fullermdThen 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
chxpoolie: hm, so all i can do is deactivate you, can't delete? oh well.06:55
fullermdTry 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
chxcatastrophe averted. thanks fullermd and poolie.06:57
fullermdSweet.  Now I can go _cause_ a catastrophe, and the scales will balance out.06:58
chxso 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
poolieit sounds like you crafted a branch which was trunk merged into you, and pushed that over trunk07:00
chxpoolie: how did i manage to do that without push --overwrite?07:00
fullermdBecause you weren't overwriting anything; the revision tree you were pushing was a superset of the one already existing.07:02
fullermdIt just happened to be one where some of the revs previously on the mainline were "off to the side".07:02
chxso is this a bug, a misfeature or should i just buzz off?07:05
fullermdWell, it's neither of the prior...   maybe it's a 'gotcha'.07:06
fullermdThink of it as an emergent property of the nonlinearity of history.07:07
chxlol, i come from a socialist country even those had a linear history it was just changing in time :p07: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 mainline07:09
* chx digs where those things are set07:09
fullermdThere's a 'config' command (new in 2.3, I think?).  I don't know if it works remotely.07:09
poolieyeah, i was going to suggest that07:10
fullermdIf 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 remotely07:10
chxfullermd: questions. if i just change branch.conf and commit -- works?07:10
fullermdWell, you need to change the branch.conf on LP, since that's where somebody might be push'ing too.07:10
chxif i set append_revisions_only then uncommit will stop working?07:11
fullermdYes, 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
chxi want this it seems.07:12
chxprobably last question, can bzr push --overwrite cause data loss?07:15
fullermdSemantic quibbles aside, yes.07:16
fullermdpush 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
poolieyou can normally get back from that by using 'bzr heads' but it is basically a --force type option07:17
* fullermd crams a couple more 'result's in that sentence, just for fun.07:17
fullermdYeah.  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
chxpoolie: that was an answer to push --overwrite?07:19
chxpoolie: i feel much safer if yes.07:19
fullermdSo, technically speaking, they're not quite really disappeared from existence, but it's the next best (worst?) thing.07:20
chxso there is bascailly no 'nuclear' option that would remove a revision for good from the repo?07:21
fullermdIt'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
fullermdNot at the UI level currently.07:22
fullermdActually, 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
chxYou know? I am glad.07:24
fullermdPbbt.  You just wait'll the next time you commit a 10 gig coredump   :p07:25
chxWe are PHP developers...07:25
chxWe commit PHP files and puppet config files.07:26
chxso hopefully no 10gigs.07:26
fullermdI was doing a data import thing some years back (in PHP).07:27
fullermdWorking 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
fullermdI 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
fullermdTurned into about an 80 meg .php script for testing; just a $foo = "longassstring"; $foo_a = unserialize($foo); basically.07:28
* chx hands include to fullermd07:29
fullermdSo 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
fullermdIt ran for 4.5 hours, then blew out the 512 meg memory limit.07:29
chxif my memory is correct it takes three times as much memory as the original structure07:29
fullermd... so I went back to blowing a couple minutes every test run.07:30
chx4.5 hours????? that was one particularly speedy machine. did you run it on a 386 :P ?07:30
fullermdNot especially speedy, but it was a dual Athlon TBird.  Not quite pokey.07:30
fullermdYeah.  I was floored.  Obviously unserialize had some minor pessimizations somewhere along the line...07:30
vilachx: don't blame his OS, it gets things done ;)07:31
chxpessimization rotflmao07:31
fullermdAfter 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
chxfullermd: you do not need to praise php to me -- after all i run the blog phpwtf.org07:31
fullermdIn 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
lifelessbecause why have one problem when you can have two?07:32
fullermdPiffle.  All problems can be solved by creating another layer of abstraction.07:33
chxhttp://www.phpwtf.org/numeric-and-integer-keys i think this is my favorite php feature.07:33
fullermdI've had its confusing of reference and referent bite me once or twice.07:34
pooliehi vila07:34
poolienice answer there07:34
chxcreating an array which has inacessible values with [] that's classy even for php.07:35
vilapoolie: hey ! Pfew, thanks, I wasn't sure about the tone ;)07:44
vilapoolie: err, your were referring to the OOM bug right ?07:45
vilajust checking :) Sometime telepathy doesn't work *that* well online...07:46
* fullermd knew you were going to say that...07:46
bialixbonjour vila08:04
vilabialix: !!! hey !08:04
* fullermd waves at bialix.08:04
vilaI was hoping to catch you here yesterday08:04
* bialix warmly waves back08:04
vilabialix: can you find a couple of minutes to speak about the configobj fix ?08:04
pooliehi bialix08:05
bialixvila: I had business trip yesterday08:05
bialixhi poolie08:05
bialixpoolie: the big island is okay?08:05
* bialix saw the bad news from New Zealand08:05
pooliewell, if you don't count the fires, floods, and cyclones, yes08:06
bialixvila: yes, I'd like to talk with you about configobj08:06
bialixvila: I'm not quite get your comment on MP08:06
poolieit's ok though :-) http://en.wikipedia.org/wiki/Severe_Tropical_Cyclone_Yasi08:06
vilabialix: 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
poolieok, i should go08:07
vilapoolie: enjoy your evening !08:08
pooliei'm going to be offline for a week08:08
vilapoolie: and your riding :)08:08
lifelesspoolie: your pqm is whinging08:08
lifelessWARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not fetchable due to <class 'urllib2.URLError'>: <urlopen error [Errno 101] Network is unreachable>08:08
lifelessno not yours08:09
lifelesslp's is08:09
pooliethat's a bit naughty08:09
lifelessI saw the sphinx bit and leapt to a conclusion08:09
pooliejml(?) is trying to use it in lp too08:09
fullermdI think that means you incorrectly answered the Riddle, and it gets to eat you now...08:10
vilabialix: 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 place08:10
vilafullermd: hehe08:10
bialixvila: the comment about not splitting the lines there because it bites me08:12
bialixvila: it bites me while I've been coding that test08:12
vilabialix: but is it triggered only in this test or can it *also* occur in bzr ?08:13
bialixI think I can use just another StringIO() wrapper instead of lines to read the config back08:13
bialixvila: one sec08:13
bialixvila: look at bzrlib/util/configobj/cobfigobj.py line 197508:14
vilaclose, I was at 1971 :D08:15
bialixvila: this is only affects test08:15
vilabut yeah I noticed this comment after you said you could use a StringIO08:15
vilaha good !08:15
vilabialix: and is it still there if you use a StringIO ?08:15
bialixvila: no of course08:16
vilaI remember configobj being so helpful sometimes with accepting different inputs transparently it hurt :)08:16
bialixI've been meaning to use lines for self.assertEquals08:16
bialixbut then I did not08:16
bialixvila: what should I do?08:17
bialixdo you want me to fix this part to use StringIO instead? And send bug report to mfoord?08:17
vilaideally: 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
vilabreak the circle: just say the test bug will reported upstream and do a followup submission against trunk once the fix get there08:19
vilas/will/will be/08:19
vilabialix: 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 goal08:20
vilabialix: that may includes support for commit data in branch.conf08:21
vilabialix: and if you could stop using dict values for config options I won't ask for a ponny :D08:21
bialixI can't08:21
bialixdict values provide me atomic transaction08:22
vilanever say I can't :D08:22
vilait's the other way around: you could if...08:22
vilabialix: 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 :D08:24
bialixwell, let's don't talk about qbzr right now08:24
bialixbecause 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.conf08:25
vilawell, 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
bialixif we talk about qbzr then I have to say that using branch.conf was/is horribly bad idea08:26
vilathe 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
bialixbecause commit_data should be stored in the tree.conf08:26
vilaas opposed to read for each option and written for each option08:27
bialixor at least inside .bzr/checkout08:27
vilatree.conf ftw08:27
bialixbut when we did what we did there was no tree.conf08:27
vilaindeed, not throwing stones (or I should throw them at bzrlib.config)08:28
bialixwhat is best strategy for qbzr?08:28
vila(and I dislike working on code under a stone rain)08:28
bialixcan we use tree.conf now, or we should store our data in the different file?08:28
vilabialix: try to converge to bzrlib.config and nag me when you encounter bugs08:28
bialixthat part of code is already using bzrlib.config08:29
vilamigrating from one file to another will *most* probably involve some kind of migration, so let's try to have a single migration08:29
vilabialix: oh, when I say use bzrlib.config I imply do not touch configobj *at all*08:30
vilano _get_parser() calls either08: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            return08:31
bialix        try:08:32
bialix            config.set_user_option('commit_data', new_data)08:32
bialix        except AttributeError:08:32
bialix            pass08:32
bialixvila: there is no _get_parser() calls!08:32
bialixvila: qbzr/lib/commit_data.py08:32
vilabialix: right08:34
bialixtoo bad we have not reached any agreement with bzr-gtk about joining our efforts re commit-data08:34
bialixI'd be happy to see some common code, even inside bzrlib, to support that08:34
vilabialix: 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
bialixI don't remember any bzr-gtk dev ever commented on my proposal08:35
vilabialix: the problem with _set_new_commit_data is that it's using a dict value for an option08:35
bialixbzr-gtk uses bencoded value08:35
bialixusing dict was abentley idea08:35
vilabialix: huh ? I discussed this with Gary back in.... Barcelona ? (Or am I mixing sprints here ?)08:35
bialixvila: I'd like to have atomic write of all commit_data options08:36
vilabialix: 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
bialixonly using dict I can get atomic08:36
vilabialix: they are supported by configobj08:36
bialixwe want to get rid of configobj?08:37
bialixI won't be upset is yes08:37
vilabialix: atomicity should be provided by bzrlib.config, it isn't right now08:37
bialixI won't be upset if yes08:37
vilano, 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 features08:38
vilaof it08:38
vilabialix: 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 them08:40
bialixvila: do you want me to use bencoded dict as bzr-gtk does?08:40
vilabialix: that would indeed be better (if you manage to find a suitable migration strategy for it)08:41
bialixvila: commit_data already has migration strategy08:41
vilabialix: but if it means migrating for that now and migrating again later for something else, then no, not a good use of your time08:41
vilahuh ? Which one ?08:41
bialixscroll down the file08:42
vilaoh, you mean moving it into core ?08:42
bialixno, in the past we had different option named commit_message08:42
bialixthen I've extended it to more rich dict08:42
vilahmm, interesting08:43
bialixso, it's not problem to make another change08:43
bialixbut I'd like to migrate into tree.conf as well08:44
vilabialix: 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 there08:45
vilathe 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 option08:46
vilaaka atomic modifications08:46
vilaall right, I've got enough feedback from you for the long term plans, thanks08:46
vilabialix: if you can add the comments and push, I'll take care of landing the fix in 2.2 and up to trunk08:47
bialixvila: to clarify: I'll change lines to pure StringIO and send bug report to mfoord, and keep the comment in the test08:48
vilayup, and add one above the fix for future merges08:48
bialixvila: do you want me to add corresponding comment about the fix in configobj.py as well?08:48
bialixok, got now08:49
bialixdoing now08:49
montywipoolie: 'bzr check' still running, after 12 hours...09:16
vilamontywi: not unsurprising, the emphasis is on making sure all data relationships are valid, not on speed09:17
vilamontywi: it's unfortuante in your case that there aren't options for quicker and more focused checks though09:17
montywistill, no it's so slow that it's unusuable09:17
montywiI am sure that with a little bit of caching one could make this 1000x faster09:18
vilamontywi: s/no/now/ ?09:18
vilamontywi: sure09:18
vilamontywi: hence my remark09:18
montywiyes, now09:18
montywistill, a full check is very useful when you suspect something is wrong09:18
vilamontywi: check is targeted at corrupted data in *unknown* ways, caching may be tricky and should be done with care09:19
vilamontywi: exactly09:19
vilamontywi: 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
montywihaving a simple cache where you store 'file name' + file block of 8K' would save you millons of open + seek + read+close09:20
vilamontywi: patches welcome :D09:20
montywiI know ;)09:20
montywiStill, mariadb development takes much of my time and it's better to code the things you know most about...09:21
vilamontywi: 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
montywibut if I get a pause, I may look at this as the fix should be relatively easy09:22
montywiand 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 finnish09:23
vilamontywi: I think lifeless was the last one working on that and he did put in place some infrastructure to enable that kind of focused checks09:23
vilamontywi: urgh, can't you duplicate it ?09:23
vilahmm, too late for that I suspect...09:24
montywiYes, I am considering moving the repro to another computer to run thecheck09:24
montywinow running bzr check on another computer that I don't need for the next 2-3 days. Hope it finishes...09:27
vilamontywi: hehe, oh, it should finish... or crash :)09:31
vilamontywi: but back to your original issue, did you try to commit from the command line instead of gcommit ?09:31
bialixvila: 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 well09:32
montywiafter it failed onces, I tried bzr commit and bzr gcommit and both worked09:32
montywii 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 it09:32
vilamontywi: 8-/ The error message was quite obscure, but now if it was spurious on top of that...09:33
vilamontywi: good, thanks09:33
vilabialix: p-e-r-f-e-c-t09:34
bialixyou're too kind to me09:34
vilabialix: 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 know09:35
bialixone sec09:35
bialixvila: 2.3 done too09:49
vilacool, 2.2 one pqmed, I'll wait for it to aggregate up to trunk09:50
bialixvila: merci10:10
cbzIs bzr-eclipse the only eclipse plugin for bzr?10:11
vilacbz: no I think there is a qbzr-based variant which is better10:12
vila. o O (I could swear someone nicked cb??? asked this same question less than a week ago...)10:12
cbzvila: it looks like it hasn't been developed in a while ..10:13
vilawhich one ?10:14
cbzhttps://launchpad.net/qbzr-eclipse/ ?10:14
vilathen it works reaaally well or is not maintained, I can't answer that one ;)10:16
vilabut 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 feedback10:17
vilaand 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
vilacbz: finally, from the url you gave above: https://answers.launchpad.net/qbzr-eclipse/+question/14574610:19
vilajelmer: pingeling about babune and reviews ;)10:24
amanicacbz: I use qbzr-eclipse every day and it works fine. bzr-eclipse stopped working for me some time ago then I switched.10:26
vilaamanica: wow, hey guy ! Long time not seen !10:27
cbzamanica: thanks10:27
amanicavila: hi! have been busy :)10:27
cbzamanica: bzr-eclipse seems to work for me, it's just that it doesn't integrate very well into eclipse10:28
vilaI sure hope so :)10:28
amanicacbz: yes I understad, I liked the other one too, but on the other hand, I like the qbzr dialogs10:29
pfarrellhi. 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
cbzamanica: thats odd - i installed it, but it doesn't seem to add bazaar to the 'share project' vcs options10:32
vilapfarrell: 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 there10:33
cbzah - orythogonal10:34
amanicacbz: where are those options?  I mainly use commit, diff, push, pull etc.10:34
pfarrellvila: ok, thanks10:35
vilawrong url, https://launchpad.net/bzr-dbus exists though, so the notification thing should come from.. bzr-gtk maybe ?10:35
amanicacbz: normally I set up everything on the commandline, but its nice to commit straight from the ide10:35
pfarrellI do have bzr-gtk installed, maybe that's it10:35
vilapfarrell: and bzr-dbus ?10:35
pfarrellyep, bzr-dbus too10:35
vilaI thought you needed some config to activate it, I should look into that.... when time permits ;-/10:36
vilapfarrell: now, you should also be able to subscribe to your mate branch at lp, but the notification will be mail based instead...10:37
pfarrelloh, we're not using launchpad10:43
pfarrellbut thanks for the tip10:43
vilapfarrell: oh, ok10:43
vilapfarrell: 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 goal10:44
vilapfarrell: so exposing your use case on lp:bzr-dbus is the best you can do to help making it supported ;)10:45
lifelessbzr-dbus + bzr-gtk can do lan notificaitons10:46
lifelessbroadcast pickup and transmit10:47
vilapfarrell: ha ! listen to lifeless :D11:03
pfarrelllifeless: is there an example anywhere?11:04
cdbsI am having a wierd problem with bzr. http://paste.ubuntu.com/570524/ Please see this11:33
cdbsI tried everything, but bzr add simply doesn't work on those two folders11:33
cdbsit works on other files. I created a dummy file, bzr added it and it worked11:33
cdbsbut not those two folders11:33
cdbsI don't have a .bzrignore11:34
vilacdbs: what does 'bzr ignored' says11:34
cdbsvila: well, I do have a bzrignore, this is bzr ignored output: http://paste.ubuntu.com/570527/11:35
cdbsvila: bzrignore is a small 2 line file which I wrote myself. None of it is currently mathing those 2 folders11:35
cdbsI am using Ubuntu Natty, so could python 2.7 be a problem causer?11:36
cdbsjust tried running bzr with python 2.6, same problem11:36
cdbscan't find a bug with a similar problem11:37
vilabut are there files to be added below these dirs ?11:37
cdbsI also tried bzr pack , and tried again11:37
vilabzr pack is totally unrelated ;)11:37
cdbsvila: no, all the other files below these DIRs have been added11:37
vilahuh ?11:38
cdbsvila: I mean, all the files below these directories were already added in previous commits11:38
vilaif some files are versioned *below* these dirs, they shouldn't be unknown11:38
vilawhat does 'bzr ls' says11:38
vilabzr ls -R that is11:39
vilaor just 'bzr ls' but inside these dirs11:39
cdbsvila: https://code.launchpad.net/~bilalakhtar/hall-of-fame/my-work/ is the repo on Launchpad, pushed uptil the latest commit11:39
cdbsvila: okay, pasting that now11:39
cdbsvila: http://paste.ubuntu.com/570530/11:40
cdbsI also did bzr add src/ubuntu_website/*11:40
cdbsno change11:41
vilaand what does a regular 'ls -al' says in ubuntu_website ?11:41
cdbsvila: aha!11:42
cdbsvila: there is a .bzr directory in ubuntu_website!11:42
cdbsgot it!11:42
vilayou're welcome ;)11:42
cdbswierd, when I did ls -R | grep bzr earlier, there was no output11:42
cdbsexcept for the usual dirs11:42
* vila lunch now11:43
lelit`hi all, I'm facing a problem with a bzr repository, where "bzr annotate" gives me a KeyError on a very old commit12: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 svn12:15
maxbIf 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 diagnose12:15
lelit`here is a summary, done on a fresh clone of my master repo: http://pastebin.com/t2Yd4mWX12:24
lelit`as said, it may be that at that time (that is, december 2009) I used bzr-svn for a while on this repo12:26
jelmerlelit`: it might be a bug in annotate dealing with ghosts12: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, later12:36
vilamaxb, jelmer: I've lost track: do we still carry our own configobj in bzrlib.util for ubuntu or not ?12:43
jelmerlelit`: bug 43895912:43
ubot5Launchpad bug 438959 in Bazaar "annotate breaks on ghost text revisions" [Medium,Confirmed] https://launchpad.net/bugs/43895912:43
jelmervila: we do12:43
maxbWe do?12:43
maxbjelmer: But you deleted it?12:43
jelmeruhm, sorry12:44
jelmerwe do still patch it12:44
=== Kraln- is now known as Kraln
vilabialix fixed an issue there that has a fallout for 2 tests12:44
maxbYes, but on ubuntu, we delete our patched version and use the system :-/12:44
vilaerr, you lost me there12:44
jelmervila: so we no longer include bzrlib.util.configobj12:44
jelmermaxb: we patch bzrlib to use the system configobj is what I meant12:45
jelmersorry for all the confusion12:45
maxbI am tempted to suggest reintroducing our private and fending off complaints about embedded libraries by explaining it's a fork12:45
vilaI'm currently blocked otherwise12:45
jelmervila: in what way is ours patched?12:46
vilawe run the tests for Ubuntu only and they will fail for bzr >= 2.3.112:46
maxbI recall there being a comment noting that we've cut bits out we didn't need to optimize startup time12:46
vilasee  https://code.edge.launchpad.net/~bialix/bzr/2.3-configobj/+merge/5051112:46
vilamaxb: the new fix is not available upstream (yet) AIUI but has been devised with upstream input12:47
jelmervila: that fix seems like it should make it into upstream configobj as well12:47
maxbeven without this fix, there's still the issue that our configobj has bits cut out to optimize startup time12:48
vilabut I can't land it in bzr/2.312:48
vilamaxb: less problematic than FTBS no ?12:48
maxbvila: Presumably you can land it, but we need to decide what to do about the debuntu packaging before 2.3.1 ?12:49
jelmermaxb: when profiling I haven't seen anything to indicate that optimization actually matters12:49
vilapqm rejected it because two tests failed (''' and """ are toggled in configobj output)12:49
jelmerfor natty, I think we should get upstream configobj patched12:49
maxbjelmer: Fair enough - if so, we should back out the customization from our local configobj copy12:49
vilaI can trivially fix the tests but they would fail again if an unpatched configobj is used during the build tests12:49
vilajelmer: I would prefer to get the patched configobj available everywhere we need it *before* removing util.configobj from our packages12:51
vilaand even better get our other fixes upstreamed and be able to rely on the upstream version once and for all12:52
jelmervila: the debian/ubuntu packages have used the system configobj since 2.1.0~rc2-1, though they still shipped the bzr copy of it12:53
jelmervila: this fix is new, and I think we should get it upstreamed for the natty/sid packages12:55
vilajelmer: 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 tests12:55
jelmervila: Do you mean the packaging of 2.3.1 build ?12:56
vilajelmer: sent: https://bugs.edge.launchpad.net/bzr/+bug/710410/comments/9 but no url...12:56
vilajelmer: yeah sorry12:56
jelmervila: 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
vilahmm, so you mean I should land with fixed tests then, right, wfm12:58
vilajelmer: right and since I will then merge that into trunk, expect the daily build to fail too13:00
jelmervila: that's fine, it's what packaging is about :)13:01
vilajelmer: 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
bialixvila: what's wrong with my test?13:20
vilahmm, still, qbzr may continue to encounter bug #710410 if bzr doesn't use a patched configobj13:21
ubot5Launchpad 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/71041013:21
vilabialix: not yours, other ones13:21
vilabialix: 2.3 added some tests for multi-lines values13:21
bialixpoint me please13:21
vilabialix: and your patch toggles the quotes used in this case (''' <-> """)13:21
bialixoops, sorry13:22
vilabialix: lp:~vila/bzr/2.3-integration13:22
bialixI think I've ran all test_config tests13:22
bialixbut maybe I did not13:22
vilabialix: hehe, blackbox ones :)13:22
vila-s bt.test_config -s bb.test_config13:22
vilabialix: no worries, I fall in this trap *very* often even when working on config myself...13:23
vilabialix: that's why we have pqm :D13:23
vilaand babune13:23
vilaof course it will help if I was receiving pqm emails...13:23
bialixbabune rocks13:23
vilabialix: and windows stay blue !13:24
bialixthe hard working monkey13:24
vilabialix: the only regression there have been related to bash completion and even there it started running tests it shouldn't have ;)13:25
vilas/there have been/there, have been/13:26
bialixvila: I don't like that change13:27
bialixI think I can fix the configobj to preserve the old behavior, so you don't need to patch your tests13:28
bialixI think double quotes is more appropriate for Human Beings by defauklt13:28
bialixI think double quotes is more appropriate for Human Beings by default13:28
bialixvila: what's your mind?13:28
bialixvila: oops, sorry13:29
bialixI've mixed those13:29
vilabialix: 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 wfm13:29
vilayou mean between triple double quotes or single ones ? :D13:30
bialixI meant: it will be nice to have double quotes in the user output13:30
bialixnow it is13:30
bialixDo you think it's good?13:30
vilaI don't care13:31
bialixthen I withdraw my picky note13:31
vilausing multiline values in config files is borderline in my book anyway :D13:31
bialixnever heard this phrase13:32
vilaAnd I prefer single quotes as they still scream 'no interpolation' in my head ;)13:32
vilabialix: '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
vilabialix: 'borderline' == 'very close to being illegal or bad taste'13:33
bialixnow I got it13:33
vilabut that's just IMHO of course13:33
bialixI can change the order to pick the triple quotes for simple cases13:34
bialixif you insist to13:34
vilawell, I won't ask you to go against your desires, that would be bad for my karma :D13:35
vilabialix: and if the fix has already found its way upstream, we'd better not diverge again13:36
lelit`jelmer: I see13:36
vilabialix: and pqm is 84% done with the 2.3 submission13:36
vilabialix: and.. :-D13:36
bialixvila: ok. let it land13:36
bialixgive up, give up13:36
vilamove it, move it13:37
vilabialix: landed in 2.313:50
vilabialix: trunk pqmed13:52
bialixvila: so, do you say there is no tree.conf yet?13:55
vilathere is no tree.conf yet13:56
vilaI want a tree.conf13:56
bialixit was not clear for me13:57
bialixyou said there is too much config13:57
vilayou're right :)13:57
vilaI 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 files13:58
vilas/there/there are/13:58
bialixsomething like that13:58
vilasee ? It's all far clearer with a little hand-waving :D13:59
bialixbut without that waving you don't have a magic13:59
=== zyga is now known as zyga-food
* jelmer takes a look at lp:udd14:23
vilajelmer: \o/14:29
* bialix waves at jelmer14:35
bialixjelmer: any suggestion re http://pastebin.com/k9AeJ1j9 ?14:36
Gorkymanhey guys...14:36
Gorkymanneed some guide for setting bzr on server... smth for dummies i gues : )14:36
=== zyga-food is now known as zyga
maxbList 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.html14:38
jelmermaxb: did you see 614544: bzr: FTBFS ?14:43
maxbsee, yes.14:43
* maxb actually reads14:43
jelmerbasically, the launchpad tests require internet access14:43
maxbah yes. fail14:44
maxbare those new, or why aren't they failing in daily builds?#14:44
maxbjelmer: 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
jelmerthe daily builds have access to launchpad I think14:45
maxboh dear that is comedy fail14:45
maxbI'm pretty sure they're not supposed to14:46
jelmerI'm going to upload a new copy with the launchpad plugin disabled during the tests for the moment14:46
maxbThat makes sense - I don't think that plugin does much which doesn't involve network access anywy14:46
jelmerIt's only a few of the tests that fail14:47
maxbMaybe just deleting those tests in the packaging branch is the best workaround?14:48
maxbLonger term, I wonder if we could set things up so there is a "feature" of "Can successfully contact Launchpad XMLRPC"14:49
jelmerideally we would just use a proper mock server14:50
maxbthat would be even better14:50
jelmermaxb: s/deleting/skipping/, but yeah14:50
=== beuno is now known as beuno-lunch
=== jam3 is now known as jam
jammorning all16:29
jamvila: I'm trying to review https://code.launchpad.net/~vila/udd/use-new-driver/+merge/5064416:30
jambut the diff is kind of hard to parse16:30
jamcan you describe what you did a bit?16:30
vilajam: it will help if you look at the resulting mass_import.py16:31
vilathe diff is really obfuscating the refactoring16:31
vilaI think it should be far clearer with the script itself on my cover letter16:32
vilaOtherwise I'll be rehashing the cover here and that doesn't sound very helpful16:32
vilajam: 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
vilaand tests16:35
vilathis mp uses the tested features to rewrite mass_import16:35
vilaso 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) calls16:36
vilawhich should get rid of all the race conditions16:36
=== deryck is now known as deryck[lunch]
=== beuno-lunch is now known as beuno
vilajam: thanks for the udd reviews !17:52
=== deryck[lunch] is now known as deryck
jelmerhey jam20:02
jamhi jelmerr21:17
jamsorry for the delay, had sound off21:17
ovnicrafthello i'm looking for a code review tool integrated with bzr anyone has experience ?21:32
jelmerhi ovnicraft21:33
jelmerovnicraft: launchpad supports code reviews (and is used by bzr itself), and I believe reviewboard also supports bzr21:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!