[00:45] hey there, has anyone managed to get pre-commit hooks (such as pep8.py to inspect the code) to work? [00:45] I spent a day and couldn't figure it out [00:48] were you doing a very simple test (ie hook, repository and checkout all on the same machine and owned by the same user)? [00:48] oh for heavens sake [00:49] the hook changes in bzr.dev break launchpad :/ [00:49] is there an api for uninstalling a hook now? [00:51] jelmer: how infeasible would it be for bzr-svn to support creating SVN-format commit bundles ? [00:51] hm, i think this change isn't in 1.13; good [00:52] hmm, wait, that wouldn't work since the SVN user who applied it wouldn't be able to create the BZR merge commit [00:53] bob2: well basically, I would like that before commit, http://svn.browsershots.org/trunk/devtools/pep8/pep8.py gets run over recursively over the .py files in my branch, and if errors arise, it prevents the commit [00:54] nekohayo: i would imagine you'd prefer it only ran against the .py files that were added/modified in the commit [00:54] jelmer: can bzr bundles be merged into plain-old SVN checkouts? [00:54] rocky: right, not a bad idea [00:54] nekohayo: right, but make sure you try the simplest case to begin with [01:00] well, to me there are no simple/hard test cases, they're all hard as a newbie :) === arjenAU2_ is now known as arjenAU [01:01] SamB: well, the question really would be, is there such a thing as a svn-format commit bundle? [01:02] nekohayo: mkdir blah ; cd blah ; bzr init ; do the hook stuff ; bzr commit [01:02] SamB, the svndump format mentions specific revision numbers for example [01:02] SamB: Yes, in theory it should be possible to merge bundles into plain old svn checkouts [01:03] SamB: The infrastructure is there, I've just never tried it [01:03] SamB: If it doesn't work, I'd be interested in hearing about it [01:03] mwhudson: ? [01:03] bob2: did you get a backtrace? [01:04] lifeless: oh never mind, i'll whine about it next week [01:05] mwhudson: what does lp need, I can file a bug for you [01:06] bob2: oh yeah, well that's what I was doing basically. The problem is that pep8.py is a tool that prints the errors to the terminal [01:06] not meant to talk to bazaar directly, from my vague understanding [01:07] nekohayo: sure, so you need to write a hook script to call it [01:07] lifeless: yeah, pastebin or bug report? [01:07] pastebin is a good start [01:08] lifeless: i already did https://bugs.edge.launchpad.net/bzr/+bug/301472 [01:08] Ubuntu bug 301472 in bzr "need a way to uninstall a hook" [Low,Confirmed] [01:09] lifeless: http://pastebin.ubuntu.com/130410/ [01:16] jelmer: I meant more "svn apply" style ... except the command I was thinking of doesn't seem to exist ??? [01:16] wierd [01:24] bob2: hit continue [01:24] bob2: and try again a few seconds later [01:25] lifeless: oneline traceback: -> signal.signal(signal.SIGQUIT, _debug) [01:25] heh [01:25] file a bug, no idea bout how to reproduce though [01:26] do you have something funny in the working tree? [01:26] lifeless: unchanged, just a branch of bzr.dev (--1.9 format) at r4119 [01:29] mwhudson: ah, why do you need that? ['m worried iti will lead to folk trying to use hooks oddly] [01:30] lifeless: well, transform_fallback_location is an odd hook anyway, it arguably should be an argument to Branch.open or something [01:30] lifeless: but for tests, basically: install the hook, run the test, uninstall the hook [01:31] though come to think of it, bzrlib's testcase resets hooks, doesn't it? [01:31] mwhudson: tets run with no hooks anyway, they get reset in setUp [01:31] hmm [01:31] lifeless: ok, will see if we actually need it [01:31] (and put back to before-the-test in runCleanups()) === kiko-afk is now known as kiko-zzz [01:45] vila: thanks for the review. New patch coming soon. [01:50] SamB: yeah, I'm not aware of anything like that either [01:50] SamB: as far as I have seen svn people always work with plain unified diffs [01:50] I wonder how I came to think there was one? [01:50] SamB: never with anything that includes multiple revisions [01:50] SamB: git has an apply commands [01:51] s/commands/command/ [01:51] jelmer: well, it would be posible to bundle together unified diffs ;-P [01:52] SamB: :-) [01:54] Oh hey [01:55] I just noticed that Sourceforge added Bazaar, Git and Mercurial to their list of supported / integrated / provided VCSs [01:55] Good to know bzr didn't get left out :) [01:55] jfroy: ah, neato [01:55] jfroy: cool [01:57] lifeless: speaking of 1.13 blockers.. [01:57] lifeless: a lot of people seem to be hitting the bug about texts with lhs parents that are ghosts [01:58] lifeless: I've tried looking into it, but I'm not really familiar enough with that code [01:59] is there a bug ? [02:00] lifeless: yes, one sec [02:01] lifeless: bug 336749 [02:01] Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749 [02:04] jelmer: you claim to have a fix; is that right? [02:04] lifeless, oh no, that's more a workaround for one of the places where the problem appears [02:05] it makes reconcile happy but then fails later [02:05] jelmer: so the LHS parent should be fine to be a ghost, the _delta_ parent isn't. [02:05] lifeless, right, but I'm not specifying the delta parent unfortunately [02:05] jelmer: you don't, thats internal [02:06] lifeless, so it would be a bug in the pack code right? [02:06] yes, [02:06] there are two vectors of parents [02:06] jelmer: eh, didn't know about that check command. Ran it on my main work svn repository, and it caused bzr-svn to thrown an error :p [02:06] vector[0] is the parents [02:06] vector[1] is the delta parents [02:06] jfroy, please file a bug [02:07] doing just that :p [02:08] lifeless, anyway, the problem isn't really in reconcile, it seems to be because add_lines() stores parents[0] as the delta parent even though it's not present [02:09] jelmer: but I guess it would be hard for them to refer to eachother when the revision numbers aren't known ... [02:09] SamB, right, but a svndump isn't really a patch format [02:13] jelmer: https://bugs.launchpad.net/bzr-svn/+bug/342065 [02:14] Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,New] [02:19] jelmer: are you sure? [02:19] jelmer: if it stores a fulltext the delta parents should be empty [02:19] jelmer: quick details to reproduce [02:21] lifeless, I'm not sure, but that's what the symptoms suggest [02:24] 13:15 < lifeless> jelmer: quick details to reproduce [02:24] lifeless, checking now if there's a public repo I'm aware of that has it but not as big as inkscape [02:29] lifeless, found one I think, I'll put up a tarball of the repo [02:30] jelmer: svn url would do, then I can breakpoint in add_lines [02:30] lifeless, so I think https://mnemosyne-proj.svn.sourceforge.net/svnroot/mnemosyne-proj/trunk should trigger it as well [02:35] hmm, actually [02:35] lifeless, that now fails in a different way [02:39] lifeless: so, the other repo with which it should be reproducable is inkscape [02:40] and some private repositories :-/ [02:41] jelmer: do you pass in the parent_texts dict? [02:42] lifeless, yes [02:43] in this particular case it should be empty though [02:44] jelmer: ok, so - look in knit.py [02:44] at def _add [02:44] I'll walk you through [02:44] ok [02:48] vila: new patch in [02:50] jelmer: so, look in th efunction for present_parents [02:50] and the variable delta [02:50] lifeless, yeah, I've looked at this function before [02:51] if you can see any way that delta = True when the LHS parent is absent, I'd love to know [02:52] if delta is False we won't delta [02:52] and if we don't, we know we write [] as the delta parents, or text reconstruction wouldn't work :P [02:52] lifeless, yes, this bit seems to work ok [02:52] lifeless, A repository created this way is fine [02:52] right, I thought so [02:52] so its a bug/issue in packer [02:53] lifeless: does reconcile use packer as well? [02:53] yes, a subclass [02:58] jelmer: one thing that may help you is to know htat in a non-stacked repo, reconcile will eliminate all references in the per-file graph to texts that are not acessible [02:58] -> you would probably be better not putting them in the first palce [02:59] ah, hmm [02:59] lifeless, so if a text revision had two parents [02:59] test_reconcile explains I think [02:59] one of which would be inaccessible, what would it do? [03:00] store neither? [03:00] text_parents =[inaccessible, acceislbe] => [accessible] [03:00] lunching [03:01] lifeless, so couldn't add_lines() just do that immediately? === bac is now known as bac_afk [03:01] lifeless, and doesn't that cause inconsistent parents errors? [03:06] vila: netrc test patch is now in === cody-somerville_ is now known as cody-somerville [03:19] rockstar: ping, re: bzr autoreview [03:19] lamalex, hi [03:21] rockstar: hey, i get an error when i try and load your plugin, someoneleft a coent on your blog post with the same error [03:22] lamalex, the wadllib one? [03:22] bzr branch lp:wadllib [03:22] ah ok [03:22] thank you [03:23] lamalex, bzr-autoreview is dependent on launchpadlib, and launchpadlib is dependent on wadllib [03:23] can't wait to try it [03:23] lamalex, make sure you're tracking trunk. I made some big changes a few days ago. [03:24] rockstar: yeah, i was planning on playing with it and hopefully contributing [03:24] same with tarmac [03:24] both look like awesome tools [03:24] lamalex, patches are always welcome. [03:35] Um. Question: http://identi.ca/notice/2758847, "have they fixed line-ending handling in #bzr yet?" [03:36] emmajane, I get those alerts. I was just looking into that. [03:37] yay :) [03:37] thanks, rockstar! [03:37] Hey, line endings in #bzr work just fine :p [03:38] fullermd, yeah, I resisted from replying, "I have new lines, what's your problem?" [03:38] Sadly, all my lines are really old... [03:38] heh [03:38] emmajane, after fighting a hellacious bug line ending bug today, I wonder if it's ever really fixed. [03:38] :/ [03:40] Hopefully by the end of the weekend I'll have wrapped my head around a useful way to make this "social" without "flamewar"ish http://www.bzrvsgit.com/ [03:40] emmajane, neato. [03:40] rockstar, Hopefully. :) [03:41] rockstar, I'm curious to know how people make the decision on which VCS is the best for their workflow. I picked based on community and how awesome this channel is. :) [03:41] * fullermd wouldn't bet overly long odds on it... [03:41] fullermd, odds on which? [03:42] I suspect, based purely on sheer mean-spiritedness, that most people don't. They pick which workflow is best based on their VCS, which they ended up with via one of a handful of processes, practically none of which are deep personal comparisons... [03:42] jelmer: no, having the parents when reconcile will strip them -> inconsistent [03:42] emmajane: I think you picked on great things :) [03:42] lifeless, thanks :) [03:43] * emmajane nods to fullermd [03:43] emmajane: Avoiding flaminess. It's possible I guess, but IME those sort of things end up being one of contentious or bland-cum-useless. [03:43] line ending stuff is getting there; the basic stuff is in final review [03:43] (which isn't to say that 'both' doesn't happen too, of course. But ending up with 'neither' is a real eye-of-a-needle) [03:44] fullermd, I want this site to be "what questions should I ask" and then link into the git/bzr/whatever sites. Not the actual answers to the questions. I might be wishing for the moon, of course. ;) [03:44] poolie: I really want a bzr+http server on bazaar-vsc.org [03:44] lifeless, emmajane, about the time of Guadec last year, SOMEONE on Planet Gnome wrote a blog post about picking technology based on community. I'd love to find that post again. [03:44] jfroy: Can't you just make a single patch ? [03:44] lifeless, kay. I'll reply to the dent with pseudo authority now. ;) [03:44] poolie: ok with you if I look into making that happen next week [03:45] vila: thought from your comments you waned 2 [03:45] The questions can get pretty contentious all by themselves. [03:45] one to add a test to netrc to show its bug [03:45] Actually, the difference between Brand X and Brand Y can almost be described as "what questions are important"... [03:45] and one to add the additional keys in AuthenticationConfig [03:45] * emmajane nods. [03:45] emmajane: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49B91135.2070700%40internode.on.net%3E and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C494A0260.5000706%40internode.on.net%3E are the two remaining branches [03:46] fullermd, totally agreed. e.g. I don't care about speed for my work so I really don't care if git is faster or not. [03:46] lifeless, excellent, thanks. [03:47] jfroy: sorry, I wanted you to add a single test, which is enough to exhibit the problem, but as part of your submission (so it can be approved at once) [03:47] vila: I merged the netrc test branch in the AuthConfig branch, so huh... bzr send-ing away :p [03:47] (to test the netrc test :p) [03:48] vila: could you send it up again please, with a clearer message :) [03:52] lifeless: Respect bzrlib.tests.test_osutils.TestWalkDirs.test_walkdirs_os_error intent sounds better ? [03:53] vila: 'restore the test that OSError raised from walkdirs includes the file the error occured on in its str()' [03:53] vila: respect per se isn't the point : [03:53] ) [03:53] jfroy: the review was about reverting your previous changes to the existing tests and adding the new one which covers your fix [03:54] vila: yeah, that was not a good move in retrospect [03:55] New patch sent [03:59] jfroy: ok [04:10] james_w: check IRC logs for 2009-02-10 [04:10] james_w: thats when the chat with oddbloke happened [04:11] james_w: 11:56 #bzr: < lifeless> 11:37 < Odd_Bloke> OK, so go for: '(y)es, (N)o, (a)lways shelve remaining, ne(v)er shelve remaining, (q)uit'? With a '(d)iff' option to come later. [04:13] james_w: ^ that was the end of the discussion [04:15] thanks [04:34] lifeless: got a minute? [04:35] somehwat [04:37] lifeless: I was just wondering if I could have a two line summary of the week ? [04:37] lifeless: going well? [04:37] yup [04:38] lifeless: are we going to have a chk/gc format for 1.14? [04:38] we've finalised the choice of gc with chks [04:38] looking on track for that [04:38] * thumper nods [04:38] Sweet. [04:38] if its not in 1.14 it will be definitely in 1.15; [04:38] what about a unified format for nested trees/rich root/normal? [04:38] as a beta format [04:38] the new chk format will be in only a single flavour [04:39] lifeless: one single flavour that supports nested trees and rich root? [04:39] there is no guarantee that we'll not find further things to change; but it will support the current nested trees data and rich roots; we won't be doing a non-rich-root version [04:39] * thumper nods [04:39] cool [04:41] lifeless: I take it abentley is happy with the format for potential next-gen nested trees? [04:41] yes [04:42] just upgraded to bzr 1.3 ... whats this bzr upgrade --subversion feature? [04:42] a lot of packaging branch stuff has happened too [04:42] 1.13 [04:42] sorry [04:45] has --subversion been added as a latest rich-root alias? [04:45] thumper: no [04:45] ah [04:45] schmichael: I'm not sure, I suspect its autogenerated and not intended [04:45] ! [04:45] schmichael: subversion is one of the formats bzr supports [04:45] via bzr-svn right? [04:45] yes [04:45] k [04:45] which you have installed :) [04:46] whats rich root? [04:47] rich roots are a bit of metadata that makes bzr repositories more capable; its not currently the default and you shouldn't use it unless you have instructions to do so from somewhere [04:47] schmichael: if you want to upgrade your branches and repositories in 1.13, the latest format is still 1.9 [04:48] oh i'm not worried about upgrading [04:48] just wondering what rich roots do [04:48] i've seen them mentioned a lot [04:48] yah, everything will be rich roots eventually [04:48] but couldn't really tell you what they do [04:49] so this magical piece of metadata does what now? :) [04:49] well directories are versioned in bzr [04:49] the root of a tree is a directory [04:50] but in the very early code it was special cased rather than being versioned like the rest [04:50] interesting [04:50] so what does tracking the root allow you to do? [04:50] thanks btw [04:51] join two trees together, so that the root of A becomes a directory in B [04:51] i'm a lone bzr user in a sea of git & hg fanboys here in portland, or :) [04:51] hm [04:51] so you can have a repo of branches? [04:51] roughly yes [04:52] this is the nested trees feature [04:52] ah [04:53] does bzr have or is it planning to add switching branches within a tree? [04:53] like git branches or hg named branches? [04:53] we have that already, via 'bzr switch' and checkouts [04:53] Tracking the root would also allow pivoting it, presumably. [04:53] we'd like to make it more friendly and accessible though [04:54] fullermd: not a useful use case generally though [04:54] Probably not, but it's one of those things that you'll need to do pretty soon if the tool can't (Murphy winz). [04:55] mtn has a special command for it. [04:55] hm, haven't used switched before and only used lightweight checkouts a bit... very interesting [04:55] switch* [04:55] mtn? that still exists?! ;-) [04:55] schmichael: it does :) [04:55] http://upsilon.cc/~zack/stuff/vcs-usage/ [04:55] ^ barely [04:55] fullermd: it does allow it, yes [04:55] schmichael: you should meet up with the ubuntu folk in portland :) [04:55] Well, it did last time I used it. Which should be a lot more recent than it is. freetime--. [04:56] lifeless: i'd love to! active in the python group, but thats it [04:56] new to the area [04:56] well, and i'm a silly old debian user too [04:56] i always recommend ubuntu to others, but for some reason keep using debian myself [04:57] Usage in general matters less than in specific. Frex, I've not yet _had_ to use git, but I have had to use mtn. Funny ol world. [04:57] * schmichael is addicted to debian unstable [04:57] Linux? That still exists?! ;-P [04:58] heh, barely. portland python meetups are 99% macs [04:58] i hear rubys the same [04:58] schmichael: I'm still a DD - nothing silly about it :) [04:58] lifeless: excellent! always dreamed of learning debian packaging but those damned docs always scare me off [04:58] Really? Huh. Is that just 'cuz the techie population is 99% macs, or is there actually a growing affinity there? [04:59] *shrug* [05:00] schmichael: some large number may be running Ubuntu on those macs :) [05:00] lifeless: some do, but afaict not many [05:04] speaking of communities and portland, somebody needs to do a bzr talk at osbridge: http://opensourcebridge.com [05:04] i'm sick of hearing about git ;-) [05:08] emmajane: aren't you giving one? [05:09] james_w, who? what? where? huh? :) [05:09] * emmajane reads up. [05:09] ah. [05:09] schmichael, www.bzrvsgit.com [05:09] You, with the lead pipe, in the study. [05:10] emmajane: ha, i know selena! [05:10] schmichael, selena is 50% of the selection committee. I think we have a good chance of having our talk accepted. ;) [05:10] schmichael, she's made of awesome. [05:10] true [05:11] and good at killing chickens ;) [05:11] omg! [05:11] yes. [05:11] you know stacey and amy too then? [05:11] or maybe you're not actually in PDX. [05:11] just moved here this fall [05:11] i know a stacey [05:11] woo! [05:11] staceyanderson? [05:12] She and I met at DrupalCon. I talked her ear off about how to run a local/sustainable/green conference. There may have been alcohol involved. [05:12] It's a good thing I'm so antisocial, or it might grate on me how all these interesting things happen way the heck away from me :p [05:12] stacey with the purple scarf? I'm sure she has a last name. [05:12] ha [05:13] fullermd, I live in Canada. I assure you I do a LOT of travelling. ;) [05:13] ha, perhaps has a purple scarf, not sure. but the stacey i know uses drupal :) [05:14] schmichael, do you know andy (thesethings) too? [05:14] fraid not [05:14] <--pdxnoob [05:14] she's a sys admin. Also made of awesome. [05:14] and Gab? [05:14] someday :) [05:14] no gabs either [05:14] I don't think I actually know the names of any PDX men. How odd. [05:14] selena took me on the Tour De Coop last summer. [05:15] nice [05:15] stacey ==> http://twitter.com/stacybird [05:15] i think i need the tour :) [05:15] ah that stacey! heard of her, but i haven't met her [05:16] you get a map of pre-approved chicken farmers. And then you get to listen to them talk about how to kill rats. [05:16] it's ... well ... crazy. [05:16] hahaha [05:16] and you know about Flavour Spot? [05:16] god i love this town [05:16] go there for waffles. [05:16] no! [05:16] * schmichael takes notes [05:16] DUDE! [05:16] and the distillery with really good gin? [05:16] dragn something, maybe? [05:16] bah [05:16] Funny, there was a rat-killing discussion at the liquor store a month or so back... [05:16] who has time for gin? [05:16] so much good beer! [05:17] omg. it's LOCAL gin. [05:17] good point [05:17] fullermd, which method won? pillow case? or just beating them? [05:17] but still, i think the local beer could keep me happy for multiple lifetimes [05:17] Apparently there's been a rash of them showing up in attics recently. No chickens, though. I hope. [05:17] I think machete was popular. [05:18] schmichael, http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation <--- has photos of Flavour Spot in PDX [05:18] Of course, farther away from the house shotgun is always popular. [05:18] fullermd, where do you live? [05:18] fullermd, and how far away can I get? ;) [05:18] MS, US [05:18] I think you're probably far enough ;) [05:18] emmajane: so thats the talk you're giving at osbridge? ;) [05:19] schmichael, not those slides, selena and I have been talking about doing a bzr vs git smack down for a while though. [05:19] I completely stole her git slides to do my bzr talk. [05:20] No, that's a backward strategy. You need to _replace_ her git slides with the ones for your bzr talk. That's how you win. [05:20] LOL [05:21] emmajane: the smackdown would be *amazing* [05:21] i'm trying to come up with a talk myself [05:22] schmichael, ultimately she and I don't really care what people choose as long as they choose something. So the talk will just be ... well .. I'm hoping it's as good as her how to kill four chickens in three years talk. [05:23] that will be tough, but i have faith [05:23] :) [05:24] I watched the talk while someone else was giving a talk at SCaLE. Ihadn't realized they'd started. [05:24] I was *howling* with laughter and selena had to tap me on the shoulder. [05:24] (I had ear buds in) [05:24] heh [05:29] james_w, do you think that answered schmichael's question? ;) [05:29] emmajane: I've noticed that some of Matthew Revell's blog posts, like http://blog.launchpad.net/projects/shutter ask why people use bzr and lp [05:29] emmajane: I think it may have been that one where they said [05:29] thumper, thanks for the link! [05:30] emmajane: we looked at git but not all the devs could get their heads around it, but bzr was easy as it fit with the commands they knew from svn [05:30] * emmajane nods. [05:30] emmajane: didn't have to "re-learn" a bunch of stuff [05:30] emmajane: it seems that git is good for those that can think like linus [05:30] yah [05:30] emmajane: but it isn't for everyone [05:30] thumper, nothing is for everyone. [05:30] emmajane: personally I really like bzr [05:30] thumper, except maybe breathing? [05:30] emmajane: except perhaps oxygen [05:31] snap [05:31] emmajane: hey, new name for bzr -- oxygen [05:31] emmajane: although I think that is taken already [05:31] thumper, yeah... [05:32] thumper, for me it's about support and community. Lenz Grimmer gave a really great talk at DrupalCon in Szeged. He was my first non-Ubuntu person that was completely excited about version control. And generally I've found the git people I know what me to be some l33t scripting genius and say "it's easy" a lot. [05:32] Man, we had the discussion the other night about difficulty typing 'bzr'... I don't want to think about where that would end up if it were called oxygen :p [05:33] thumper, maybe people will outgrow bzr and move to git, but i'd rather get people using something than thinking all version control is too hard to bother with. [05:33] emmajane: I'd rather people don't outgrow bzr [05:33] emmajane: why would they? [05:33] thumper, people move on to different projects and the community changes. [05:34] emmajane: it seems we'll have some people at the mysql conf in CA next month [05:34] * thumper nods [05:34] I was thinking for a particular project [05:34] people move and change [05:34] thumper, some say "speed" was a factor for them. But 9/10 it turns out that LP was slow, not bzr. :( [05:34] hopefully people that go from bzr -> git realise what bzr offers them :) [05:35] emmajane: well, speed is a factor [05:35] especially with LP [05:35] I also know a fair number of fence sitters in the drupal community. [05:35] * emmajane nods. [05:35] many people's first exposure is getting a branch [05:35] drizzle was the project that selena brought up. [05:35] this should change greatly soon [05:35] she thought it was bzr being slow, but it was LP. [05:35] lifeless and spiv have done great work recently with the smart server [05:35] emmajane: you can beat me with the LP stick [05:36] * emmajane nods. I think Selena will retry. Of course I'll have to try git so that I can actually comment with some kind of experience instead of just gushing about bzr. ;) [05:36] And many beers to them for that. That's been one of my sore spots for a long time :| [05:36] thumper, yeah, I know. :) I prefer not to beat people though. [05:36] fullermd: agreed [05:36] emmajane: well, how about tickle me with the LP feather then? [05:36] LOL [05:37] that's more likely to get results, I bet. ;) [05:37] * thumper resists getting more lewd [05:37] yes, do resist. [05:37] beer-o-clock [05:37] you'll just end up regretting it. [05:37] I do [05:37] every time [05:38] :) [05:38] The scars fade in 15 or 20 years. Sometimes. [05:38] beer-o-clock at 4? y'all start early down there. [05:38] emmajane: it is 18:38 here [05:38] pizza's are arriving shortly [05:38] emmajane: I'm in NZ [05:38] thumper, not sprinting this week? [05:38] emmajane: not me, we did one last week [05:38] ahhhh [05:39] right. [05:39] fabian pinged me about translation stuff. [05:40] * thumper steps away from the computer [05:41] thumper, enjoy the pizza? :) [05:53] ok. I think it might be sleeping time for the east coast of north america. night all! [05:54] * fullermd waves to emmajane. [06:44] I installed bzr-gtk to get "bzr viz"; I now seem to have something permanently stuck to my gnome panel notification area that pops up balloons when I commit stuff. How do I get rid of that? [06:46] Hmm, I just hit paste in this channel. I wonder what I pasted? [06:46] Nothing, apparently. Anyway, it seems SourceForge now supports bzr, hg and git. :D http://arstechnica.com/open-source/news/2009/03/sourceforge-adds-support-for-new-version-control-systems.ars [06:46] liw: turn it off in options [06:46] lifeless, where are these options? [06:47] lifeless, also, what are they called in Finnish :-P [06:47] Inneresting. I heard about git, but not the other two. [06:47] liw: System->Preferences->Session I believe [06:48] That saves me wondering what to do when I get around to picking back up a project I have on SF that I don't wanna keep using CVS for :) [06:49] james_w, oh, right; let's hope that sticks [07:04] fullermd: hg and bzr are very new on sf [07:09] Well, I only heard about git in their email earlier this week. [08:11] ja1: https://pastebin.canonical.com/14928/ [08:16] ja1: "$0& $0&" [08:50] ah the internets [09:59] jelmer: I had to make some changes to bzr-git to get it to work with bzr.dev [09:59] is that a known issue ? [10:05] I also get: bzr: ERROR: Tags not supported by ; you may be able to use bzr upgrade. === bac_afk is now known as bac [10:50] Is there a workaround for the +x/-x permissions hell of using bzr in cygwin? [10:51] This stuff just adds confusion to my already easily confused brain :) http://pastebin.com/m19743912 [11:06] Also, I don't get why the local copy is renamed to ".OTHER". Surely ".THIS" would make more sense? [11:08] james_w: I have a branch for the shelve stuff somewhere, let me look for it. [11:10] james_w: http://bzr.daniel-watkins.co.uk/bzr/shelf-prompt/ [11:35] I think Windows is the culprit .. it keep setting executable perms on everything, including data files === bac` is now known as bac [11:36] Perhaps I just need a commit script that does:- find -type f -print0 | xargs -0 --no-run-if-empty chmod a-x; bzr commit -m "$@" === sabdfl1 is now known as sabdfl [12:46] Odd_Bloke: thanks, I'll take a look [13:12] james_w: I will _hopefully_ have some time this weekend to look at it. [13:12] But I also have some Debian packaging to do, and a personal project to (hopefully) deploy. [13:12] sounds fun :-) [13:13] As far as I'm aware, it's ready to be merged. [13:13] But I can't remember exactly where it is. [13:13] I'm really a little confused as to where the last month has gone. :p [13:58] hi all, is there an easy to to alter the commit message of the last commit in bzr? [14:04] Only by uncommit / commit [14:07] ok thanks [14:10] Which will have a different revid when it's finished, so it'll look like a branch divergance if other people have used it [14:47] asabil, hmm, that should already be fixed [15:38] Hello, how do I make xmlrpc requests use http_proxy ? === nevans1 is now known as nevans [15:42] BasicOSX: should the rcs be in the bzr-ppa? [15:42] Why didn't I think of coming here first? Heh. Is there any sort of issue tracking system that works with bzr like unfuddle, or even trac? [15:42] trac does [15:42] CrashTest_: trac, but it doesn't match very well. Redmine has a better domain model fit [15:42] CrashTest_: launchpad of course to [15:42] CrashTest_: and Bugs Everywhere [15:43] LarstiQ: Awesome! Are these free? [15:43] launchpad is, as I understand it. [15:43] jelmer: I uploaded 0.5.3, but it's bzr 1.13~ dependency wasn't satisfied, though :) [15:43] hehe, 'bzr branch' takes 200m already [15:43] don't mind me, I will look them up from here, thanks for the pointer! [15:43] CrashTest_: all but launchpad are available right now as Free Software [15:43] CrashTest_: launchpad is free to use, and in the process of being released [15:43] Ah, so I was exactly backwards :) [15:44] domas: from what to what? [15:44] LarstiQ: Thanks! [15:46] LarstiQ: "bzr branch lp:something" connects to some canonical xmlrpc box directly === CrashTest_ is now known as CrashTest_pie [15:46] hold on [15:47] CrashTest_pie: If you're working on Intuit stuff, we should discuss bzr-based deployment strategies for testing, staging, and production for your clusters. [15:47] CrashTest_pie: Or anything serious, Intuit or not. [15:47] davidstrauss: Actually, I am considering this for everything in the future. [15:48] LarstiQ: connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.90.218")}, 16 [15:48] davidstrauss: Intuit wanted their site done in 4 days, and I basically didn't do anything in the way of versioning for their theme job. [15:48] LarstiQ: thats xmlrpc.edge.launchpad.net [15:49] shame on me, I know. I am trying to change my workflow right now, so that everything I do is versioned. [15:49] So yes, davidstrauss, I would VERY much like to talk to you about this. [15:49] but now, pie. [15:49] I will be right back. [15:50] LarstiQ: if I specify https:// paths directly, it works via proxy [15:50] jelmer: not with the latest code from launchpad [15:51] asabil, from my branch? [15:51] what's the bzrlib way of dealing with authentication (e.g. for commits?) [15:51] jelmer: yes [15:51] jelmer: self._lock_count = 0 [15:51] trying to set an unsettable attribute [15:53] hehe, bzr branch taking 500M [15:53] I really need to upgrade my desktop === CrashTest_pie is now known as CrashTest_ [15:54] Tak: commits can have a Testament attached iirc [15:55] davidstrauss: let me tell you that I am super pleased that fourkitchens has the Drupal repo in bzr. And you blog posts have made things nice and easy for me to start picking up bzr. [15:58] asabil: looking at Testament, either I'm misunderstanding you, or I don't see how that will help [15:59] Tak: the testament can be used to prove that a commit has been made by someone [15:59] davidstrauss: if you didn't pick up on this, I am a VCS noob. [16:00] oh - I mean for committing to a repo that requires authentication [16:00] like something on an sftp transport that requires a password === bac` is now known as bac [16:02] Tak: ah ok, this is not really handled by bzr itself, it is generally delegated to a lower level (bzr+ssh for example uses the ssh authentication means) [16:03] Tak: launchpad uses a different approach from what I understood [16:04] so if I wanted to handle the authentication programmatically, I'd have to special-case each transport? [16:04] they have a bzr plugin overriding LocalTransport which does various checks [16:04] Tak: what is the aim you are going for? [16:05] I want to be able to accept authentication details in advance from a gui, then perform a commit(/push/merge/whatever) using bzrlib [16:07] aha [16:07] Tak: have a look at how qbzr does it, and at credential stores [16:07] Tak: the netrc plugin too [16:11] aha, I think AuthenticationConfig may be what I was looking for [16:36] Hi, if someone updates a branch in launchpad, how do I get the updates? [16:37] cd branchfolder -> bzr update?? [16:39] luca: if it is an unbound branch, then use bzr pull [16:40] it's this one https://code.launchpad.net/~pyreved-devtm/pyreved/main [16:41] luca: the fact that it is bound/unbound depends on how you did get the branch in the first place [16:41] I got it using this command: bzr branch lp:~pyreved-devtm/pyreved/main [16:41] luca: if you did a bzr branch lp:pyreved then bzr pull is what you want [16:41] then bzr pull :) [16:42] ok thank you very much! [16:42] you're welcome === DavidLeon|Zzz is now known as DavidLeon [16:48] anyone would change bazaar to C#? [16:48] How do you mean? [16:48] Rewrite it? I doubt it. [16:49] C# crossplatform issue is being solved. mono works on *nix, and C# IDE is much better than python, so the C# performance [16:50] from the maintaining and getting more developers aspect, it's good to move to C# [16:50] LarstiQ: about rcs being in the ppa, good question, since I'm new, I don't know. I'll ask. [16:50] it doesn't solve that fact that C# is a god-awful language [16:50] Toksyuryel: why python is so much non-awful than C#? [16:50] there is no good reason to switch from python to C# [16:51] is it possible to convert a heavyweight checkout into a leightweight checkout [16:51] ? [16:51] DavidLeon: I think implementing bzr in c# could be a good idea [16:52] DavidLeon: at least from an experimentation pov [16:53] yah, a light weight yet user friendly bzr can be developed because the rich .net framework [16:53] .net is horrid [16:54] Toksyuryel: have you ever used C#? "horrid" is probably one of the last things I'd call it [16:54] DavidLeon: do you have any plans on working on it ? [16:55] I mean if robust, typesafe language make you wet your pants, then I can see why you'd call it horrid [16:55] but if you enjoy clean syntax, and a powerful standard library, it should get you wet in other ways [16:55] asabil: not yet [16:56] asabil: just some brainstorm idea [16:56] Why do you come into a channel for a software that is officialy a GNU project, and developed by Canonical, to advertize proprietary microsoft products? [16:56] The language doesn't always matter... [16:56] DavidLeon: other implementations of bzr are fine [16:56] DavidLeon: I am pretty sure many people would like to see a parallel implementation in c# [16:56] I use a window manager written in Scheme, and a file sync daemon written in OCaml [16:56] Neither of these facts bother me. Both programs Just Work [16:56] DavidLeon: but I don't think the current developers will switch to a C# bzr project [16:57] gtg, ttyl [16:58] .net/mono, whatever [16:59] bzr is more a framework than an application, you can't just switch or have parellel implementations [17:00] luks: the data formats, however, can be read and written by others [17:00] as can speaking the bzr protocol [17:00] the data formats change every few months [17:00] how's the bzr protocol compared to mercurial's? [17:00] and you want write better data formats if you are going to write a vcs from scratch [17:00] DavidLeon: I don't know mercurials [17:01] web benchmark seems show more favour of hg than bzr [17:01] luks: "better" ? [17:01] Kinnison: faster to access [17:01] luks: let me put it another way, I have no objection to .net bindings, wether they os.system or implement some things again [17:01] yet i find bzr most comfort to use [17:02] luks: Given what constraints? Under which conditions. It's hard to satisfy "fast to read" "fast to write" "fast to traverse for annotations" "small on disk" and "small in memory" [17:02] LarstiQ: I don't disagree with that, I was just pointing out that bzr can't be simply seen as an "application" [17:03] Kinnison: sorry, I can see where this is leading :) [17:29] the issue with parallel implementations is that there's always lag among the branches [17:30] so they're only ever parallel some (often large) delta behind the edge of development [17:31] that's not a problem in general [17:32] for example the git formats will unlikely change any soon, so the dulwich or jgit guys can safely work on their implemenations [17:32] but bzr it based around it's API, not it's formats [17:32] *is [17:34] sure, it becomes less of a problem if you push the amount of work being done in parallel down to e.g., interpreting a common file format === thekorn_ is now known as thekorn === mark1 is now known as markh [18:44] lifeless: there are times when 1.9 format and bzr 1.12 feel slower... [18:44] lifeless: when pushing a branch to lp, I seem to spend a lot of time in "Transferring:Walking content." now === mthaddon_ is now known as mthaddon [19:39] mtaylor: could you -Dhpss that and look at the log? [19:39] LarstiQ sure [19:39] mtaylor: I think I'm seeing the same thing [19:40] LarstiQ: going to lunch right now - will do when I get back [19:40] mtaylor: np, I just had dinner :) [19:43] oh man [19:43] so does anybody know how I manipulate an AuthenticationConfig with bzr 1.5? [19:43] __dict__ says I only have _filename, _config, and _input [19:45] * LarstiQ looks at the source of 1.13 [19:50] ugh, it looks like I have to directly populate and set the ConfigObj [19:51] Tak: no get_credentials and set_credentials? [19:51] if so, then 1.5 is significantly different from 1.13 [19:51] it has get_credentials, but no set_credentials [19:51] Tak: (for 1.13, construct it with _file=None to the constructor) [19:52] Tak: you can't upgrade? [19:52] I want/need to support what's in debian [19:52] which Debian? [19:52] lenny? [19:52] and no backports? [19:52] sid [19:52] ah, I see. [19:53] jelmer: time to push stuff from experimental to sid now that lenny is released? [19:54] jelmer: ah, you already did [19:54] Tak: packages.qa.debian.org/bzr says 1.13 is in sid [19:54] Tak: which would make your life a bit easier if you can depend on that [19:58] wth, is my mirror out of date? [20:00] huh, I guess this won't be automatically announced: https://bugs.launchpad.net/bzr/+bug/342474 [20:00] Ubuntu bug 342474 in bzr "bzr help push (or bzr push --help) results in a traceback" [Undecided,New] [20:00] Oh [20:00] yay [20:00] I guess it will [20:00] I can't believe I'm the first person to report that bug, I just couldn't find the duplicate :) [20:01] that's weird; it give the help message in my ancient 1.5 package ;-) [20:02] * LarstiQ grins at Tak [20:03] glyph: could yoy try to disable the push-and-update plugin? [20:03] glyph: and try again? [20:03] * Tak give up, make note to try again later with 1.13, go home [20:04] LarstiQ: OK [20:04] Tak: you might be able to do it without an AuthenticationConfig perhaps [20:05] Tak: I'd need to look at the code a bit, but if all calls go through a credential store, you could just plug yours in and make it the default [20:05] Tak: which would save you from dealing with ConfigObjs [20:06] glyph: I'm reasonably sure that plugin is wrapping cmd_push and/but not providing a docstring [20:06] LarstiQ: I don't even need to disable it. I just updated it, and it fixed the bug. [20:06] I guess I'll go close that :) [20:07] glyph: or turn it into "less scary warning on undocumented command" [20:07] glyph: does it actually give a traceback? [20:07] LarstiQ: I dunno [20:07] (by itself) [20:07] LarstiQ: Yes. The traceback's in the bug report [20:08] glyph: I think that should be changed then [20:08] A less scary warning would be good, but it should still list plugins or at least note the responsible plugin or soething [20:08] otherwise it would have been mysterious why I didn't have help for push [20:09] (the traceback itself was completely unhelpful) [20:12] glyph: yeah, setting internal_error=false on the NotImplementedError gets rid of the traceback at least [20:13] glyph: arguably, it shouldn't raise NotImplementedError to begin with [20:23] Howdy. [20:23] I have a workflow question. [20:24] Working on a web project, which will have a document root and is set up in an IDE. How do I use it smoothly with bzr and branching? Read somethign about a switch ? [20:26] thecookie: yes [20:26] thecookie: most IDEs have difficulties with thinking outside of their working directory [20:26] I have everything else working. A checkout from my main server. Branching that checkout. commiting/updating/pushing/pulling. But not sure where to fit in that switch (or any other method) [20:27] thecookie: so with switch, you keep 1 working directory (usually a Bazaar 'lightweight checkout') and `bzr switch` between branches, it then updates that one working directory with the difference [20:28] Yeah, that sounds like the thing I want. Atm I have ~/dev/main and ~/dev/some-branch [20:28] thecookie: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id57 [20:28] Would I have ~/dev/working-branch ? [20:28] thecookie: 5.5.3, Switching a leightweight checkout [20:29] thecookie: it wouldn't be a branch so that's slightly misleading, but yeah [20:29] Yeah, was just about to say that the URL fragment thingy didn't work :) [20:29] What would be a better name? [20:31] I'll test it out [20:33] thecookie: ~/dev/work :) [20:35] Thanks for the insight. :) [20:35] I guess I have to redo my repo then [20:36] with the --no-trees flag [20:40] thecookie: you can use `bzr reconfigure` [20:44] Thanks, I will try that [20:53] asabil, unfortunately that breaks 1.13~rc1 [20:55] jelmer: well I sort of fixed it, but now I am stuck with an error related to tags [20:55] asabil, running my trunk? [20:56] jelmer: yes [20:56] lp:~jelmer/bzr-git/jelmer [20:57] wait I just pulled === UdontKnow is now known as udrunknow [21:00] jelmer: I pulled from your trunk, and reverted the commit in revision 251 [21:00] it works for now, but I will hit a traceback related to tags soon [21:02] LarstiQ: Would the best solution to not having to type tha password on each time using sftp:// to add a key and use ssha? [21:02] Or can bzr store passwords? [21:03] thecookie: ssh keys are a good idea anyway. But with authentication.conf you can configure other credential stores, like .netrc [21:03] jelmer: AttributeError: 'RemoteGitRepository' object has no attribute '_git' [21:03] in File "/home/asabil/.bazaar/plugins/git/branch.py", line 46, in get_tag_dict [21:03] thecookie: seahorse on linux and putty on windows make setting up ssh keys fairly easy [21:03] asabil, what are you trying to deo exactly? [21:04] jelmer: just cloning from a git repository [21:04] I'll check out seahorse [21:04] bzr clone git://github.com/jimweirich/rake.git [21:10] is there a way to have heavyweight checkouts automatically sync to local on commit if no net access and then master when re-connected to the net? [21:11] solarion: instead of doing commit --local, you want `bzr unbind; bzr ci; bzr ci; bzr ci; bzr bind`? [21:11] solarion: `bzr update` then will pivot your local changes [21:47] jelmer: the bzr check KeyError bug I reported yesterday also occurs when I do a bzr diff --old command. [21:48] And it happens for more than one branch stored in that repository, maybe even for all branches stored there (hard to verify that). [21:48] rockstar: how do I set my public branch with bzr-autoreview? [21:49] jfroy, is this a branch on which older versions of bzr-svn were used? [21:49] I've tried with two branches, and in both cases, yes. [21:50] And I've seen the error for 2 different files so far. [21:52] actually this is a generic bzr question, how do i set my public branch? [21:53] lamalex: through branch.conf (inside the branch) or through localtion.conf in ~/.bazaar/localtion.conf [21:53] *location.conf [21:53] jfroy: thank you [21:54] All the details in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html [21:55] And it's locations.conf :p [21:55] Third time's the charm, I guess [22:13] Is there a way to get the size of a commit? [22:13] such as in KB [22:14] I guess for non-binary files getting the size of the diff works, although I may have binary files [22:21] well if anyone sees this and has an answer, please do email me @ubuntu.com :) [22:21] lamalex, did you get your help? [22:22] rockstar: yes thank you :) [22:22] works awesome, but is there a way to change what editor it uses [22:23] lamalex, I think it uses the $EDITOR environment variable. [22:24] lamalex, it uses the bzrlib mechanism for handling all that. [22:26] hm ok [22:26] i set that to emacs, ill keep messing with it === Goundy is now known as CoderFromHell === CoderFromHell is now known as Goundy === cody-somerville_ is now known as cody-somerville === christopher is now known as thecookie