[00:00] dvheumen: subclassing is a very big hammer [00:00] * lifeless really has to duck out; I'll be back [00:00] lifeless, but otherwise I'm probably implementing almost the same code three times [00:00] (i think) [00:01] also, is it "a very big hammer" in python, or in object oriented languages in general? [00:02] general [00:03] dvheumen: I think Rob also means that changing that now will be a fairly big change with a lot of consequences [00:04] even though most classes derive from 'object'? [00:04] sorry guys, but I'm trying to form a picture here of what the complications are [00:04] they derive from object for hysterical raisins [00:05] it's for backwards compatibility in python 2.x - deriving from object gives you a 'new style' class, which adds some features, but is subtly incompatible with old-style ones [00:06] okay, I'll read up on that [00:06] well, you don't have to, you can just always inherit from object if not inheriting from anything else (for bzr, at least:) [00:07] bob2, true, but I like some background info, helps with the thinking :P [00:07] google descrintro for the whole shabang [00:09] k, tnx [00:11] aha ... I see some other complications with my idea ... okay, back to the drawing board :P [00:15] actually i do think having a common Component class is a good idea [00:15] but we should be very careful what goes in it [00:15] at least saying "there is a common interface" is a good idea [00:16] hey, don't steal my idea now ;) [00:17] any candidates that you want to put in there? [00:19] .bzrdir is probably the most obvious common attribute. [00:20] ah right :P [00:21] back [00:21] caffeined up [00:22] Possibly the logic for opening them (so reading .bzr/$component/format files and finding the right implementation from a registry) and initializing them. But even then some of that is just common to bzr native components, not foreign ones (e.g. SvnRepository)... [00:22] dvheumen: the code in question is something like lock. 'invoke_lock_callback(self)' though [00:23] lifeless, yeah, I know [00:23] it's much easier than I was previously thinking [00:23] note that many external formats *don't have* components [00:23] in fact our older formats aren't split into neat little orthogonal elements [00:24] so while I like the idea of a Component for things that are Components, Branch per se isn't a Component, IMO [00:24] BzrBranch4+ could be [00:26] lifeless, I'm gonna try something in the coming days and then I'll get back to you [00:26] cool [00:27] bye [00:27] oops [00:48] igc: hi! [00:48] hi jelmer! [00:48] poolie: oops? [00:48] igc: lp:bzr-website is pack-0.92 at the moment, is there any reason it's not upgraded yet? [00:49] * maxb has just finished using bzr-rewrite to rebase a branch based on a bzr-hg import of a hgsubversion import of a svn branch onto a bzr-svn import of the svn branch. How's that for a brainteaser :-) [00:49] jelmer: nope. Feel free to upgrade it :-) [00:49] maxb: :-)) [00:49] igc: Ok, thanks! [00:52] I can't 'bzr pump' with bzr 2.1.0 and pipeline 2.1 r157 (the latest on the 2.1 branch). [00:52] bzr: ERROR: exceptions.AttributeError: 'RevisionTree' object has no attribute 'branch' [00:53] wgrant: -Derror please [00:58] lifeless: http://paste.ubuntu.com/392911/ [01:02] ugh, soo many spans [01:02] * lifeless tries without wget [01:04] wgrant: ok, its a bug in the new merge hook facility [01:04] wgrant: and you have a merge hook enabled for your branch - possibly builddeb [01:04] lifeless: You can also add '/plain' [01:04] lifeless: Ahh. [01:04] please file a bug, its something we'll need to do a 2.1.1 for [01:05] lifeless: Summary? [01:05] igc: done [01:06] jelmer: thank-you! [01:07] ConfigurableFileMerger does not support merging with this_tree a revision tree [01:07] or something [01:07] include the backtrace of course [01:07] right. [01:09] lifeless: Bug #537041 [01:09] Launchpad bug 537041 in bzr "ConfigurableFileMerger does not support merging with this_tree a revision tree" [Undecided,New] https://launchpad.net/bugs/537041 [01:10] also please include the output of bzr hooks for the merge_file_content point [01:11] lifeless: Just NEWS, but it's on the bug now. [01:11] thanks [01:11] if you wanted to patch it [01:12] I would, if it's simple. [01:14] minimall would be to guard the attribute access, and if it fails, try for a global config instead [01:14] better still would be a test showing that that works. [01:27] poolie: ping [01:27] lifeless: hi [01:27] hi [01:28] I bumped into a friend I hadn't seen for ages [01:28] he manages a programming team now [01:28] cool [01:28] I asked about what they use for version control [01:28] he said CVS and Subversion [01:28] but they are looking at DVCSs [01:28] I asked if he'd like me to come in and give a talk [01:28] he was very enthusiastic [01:29] so I have something next Tuesday at 10:30 am [01:29] would love some help with a talk outline [01:29] I'm sure there'll be questions about git as they are looking around now [01:29] sure [01:29] so I'd like some bullets [01:29] uhm [01:29] :) [01:29] what language do they use [01:29] what ide if any [01:29] bzr-explorer will be a good one [01:29] perl [01:29] what platform [01:30] thumper: bullets? Don't shoot potential users! :) [01:30] all he asked was "does it work on mac os"? [01:30] ok, cool [01:30] lifeless: heard of AD instruments? [01:30] yeah [01:30] data capture [01:30] analytics [01:30] I suspect I know your friend :) [01:30] john [01:31] mmm, no. But I definitely know *someone* there. I think. [01:31] anyhow, thats not important [01:31] key points are going to be - [01:31] we build and test macos X [01:31] explorer [01:31] python for extensability [01:32] * thumper nods [01:34] single site? [01:35] at this stage as far as I'm aware [01:35] they want good merging :) [01:35] so, you can talk about ease of migration [01:35] stay with the same workflow, ease into distribution [01:35] merging is great [01:36] very very hookable in 2.1 [01:36] * thumper nods some more [02:09] * igc lunch [02:24] hello. regarding bzr-grep bug #536688 i wanted to check if anyone had any opinions. i am ok with either options. [02:24] Launchpad bug 536688 in bzr-grep "Default behaviour should recursively search versioned files" [Undecided,New] https://launchpad.net/bugs/536688 [02:24] --recurse is closer to POSIX grep while recurse by default is similar to hg and git. [02:29] I'd recurse by default [02:29] ls doesn't, but it used to, and I think we made a mistake making it not do it by default [02:30] I agree, recurse by default. [02:31] I always run ls twice since it stopped recursing. [02:31] Plain old grep doesn't have the advantage of knowing 'these files are all part of the one project', but bzr does. [02:31] fullermd: :-) [02:33] sounds fine to me. i will go with recurse as default and add a --no-recurse option. [02:33] there is already a --from-root. [02:34] if we go with recursive grep and user sets 'grep=grep --no-recurse' as an alias, how can (s)he override it from command line. [02:35] do we need an explicit --recurse option or does the option processing framework do some magic? [02:37] parthm: our option stuff automatically does --recurse if you have --no-recurse, I think. [02:38] lifeless: that sounds fantastic. i will go ahead with the --no-recurse. [02:38] thanks everyone for your inputs. [04:17] hi spiv, are you around? [04:17] how are things? [04:19] Yeah, I'm around. [04:20] Things are going pretty well. It's amazing how much easier it is to cope with the email load working 3 days a week rather than 2 :) [04:22] I'm catching up on in-progress work that had started to accumulate. Oh, and I'm glad I'm subscribed to the 'answers' for bzr, it's much more active than I had realised. [04:42] yes it is [04:42] i thought you were all just slack for not answering them ;-) [04:42] i just put up an mp to plot that too [07:17] hi all ! [07:21] Oh, vila's around. Must be bedtime. [07:21] :) [08:40] is there an option to exclude certain filetypes in bazaar? [08:40] when adding [08:40] wait.. im just now seeing ingore list [08:44] wow.. bzr remove actually deletes files doesnt it? [08:46] yes [08:46] unless you ask it not to [08:47] rofl i freaked for a second [08:47] then found revert [08:47] and thanks.. i was just trying to get it to stop VC'ing some files [08:48] so could i just use the --keep flag to do that? [08:48] bzr remove ./lib --keep [08:48] yes [08:49] thanks lifeless [08:58] vila: hey [08:58] vila: I put it to you that 'Conflict: can't delete lptools because it is not empty. Not deleting.' is the largest cause of merge conflicts. [08:58] vila: and there is a bug about it, suggesting a lost+found approach, amongst other things. [08:58] * vila nods [08:58] vila: if you were to fix this, I would be extremely excited. [08:59] It's definitely on the radar [08:59] * lifeless bounces, gently. [08:59] A pretty big spot even [08:59] * lifeless bounces faster. [09:00] I realized yesterday that 'bzr clean-tree' is kind of a workaround in some cases in the mean time [09:01] by the time you know you need it .. [09:01] sure, workaround is an optimistic way to talk of the problem :] [09:01] s/of/about/ [09:02] * lifeless wafts activation energy at vila [09:03] * vila receives that gratefully [10:00] vila: where is the canonical place to download DVC these days? [10:01] quicksilver: I'm not of any change there (I didn't upgrade it for a while though), let me checl [10:01] there was some confusion about which repo to use last time I checked [10:01] which was a while ago, I admit [10:02] http://bzr.xsteve.at/dvc/ [10:02] I currently miss 48 revisions 8-} [10:02] Forbidden [10:02] You don't have permission to access /dvc/ on this server. [10:05] quicksilver: huh ? Where did you get that ? I just pull -v [10:05] oh, OK. [10:05] and you run straight out of the repo? [10:05] or you copy the elisp files somewhere? [10:06] quicksilver: I run from the repo but I have a ++build there where I run make [10:06] quicksilver: I set that up so long ago I'm not even sure I still use it though [10:06] :) [10:06] let me check another install [10:06] ah well I better find a machine I have bzr on. I'm stuck on a temporary windows box :( [10:07] quicksilver: ouch [10:07] windows is the only OS I've yet to address in my versioned setups... [10:08] mostly I just run emacs and putty and firefox and ignore the rest of the system [10:08] I dont' try to program on it (I do that via ssh and a linux box) [10:08] I use the stock emacs there without any customization which has... some surprising results when confronted with my muscle memories :) [10:09] hmm I don't know if I will want to do this after all [10:09] firefox on windows ?? Wow, I don't even make my windows VMs visible on the internet :) [10:09] I just remembered that vc-bzr is really really painful over plink [10:09] I imagine dvc will be as bad. [10:10] branch locally :) [10:10] well new hard disk arriving today. Hopefully won't be long now. [10:11] quicksilver: not running make in ++build seems to work (as in no messages under emacs), but that doesn't mean it used the right versions either... [10:12] quicksilver: anyway, I think to remember you need to compile dvc before using it which require auto and getting that on windows... [10:15] quicksilver: I *had* some instructions about installing/setting up dvc, but I can't find them anymore :-/ [10:16] . o O (Well done for versioning all that setup stuff, well done really :-( ) [10:17] hmm, may be it's because the dvc INSTALL file seems to cover it (including using ++build which is a rather unusual dir name for me) [10:18] quicksilver: so basically: autoconf; cd dvc; mkdir ++build; cd ++build; ./configure ; make [10:18] quicksilver: see the INSTALL file in short :) [10:20] ha, found these notes back, yeah, they are obsolete, I now use instructions from the dvc INSTALL file [10:20] :) [10:38] :) [10:53] bzr diff --using meld seems to be broken [10:53] the diff still ends out mostly on stdout :( [10:59] Keybuk: works ok for me, just the "=== path/of/file ===" lines end up on stdout [11:01] (even with --no-plugins, --using is a builtin feature these days) [11:02] spiv: I get the diff [11:02] in fact, I get some diffs [11:02] then sometimes meld pops up with the diff of just *one file* [11:02] you close it, you get more diff on stdout [11:03] interesting [11:03] the diff is for added files [11:03] (on stdout) [11:06] Huh! [11:06] That sounds like a silly bug. [11:07] It is annoying that it only pops up meld for one file at a time. [11:08] It's rapidly approaching my bedtime, so please file a bug report. === weigon_ is now known as weigon [12:05] Hey, I'm a newbie to version controls, and was wondering if all the code ends up in the trunk folder ? [12:05] I have a live website I'm running, and would like to use that as the main branch. I can access that by FTP [12:39] Hi all, What are the bzr commands to reorder a set of bzr commits while making some modifications to each commit (after a review cycle) [12:42] amitk, bzr-rewrite [12:42] it's a plugin [12:44] beuno: hmm, apparently not in karmic [12:44] what is stored in the "indices" folder of an repository? === xeviox2 is now known as xeviox [12:45] s/an/a [12:49] amitk, http://wiki.bazaar.canonical.com/BzrPlugins [12:49] amitk: it's still named bzr-rebase in karmic [12:49] does bzr use one .pack file for each file in the repository? [12:55] xeviox, no, packs combine many revisions [12:55] jelmer: rebase doesn't seem to do what I want. I don't want to rebase revisions r4..410 to another branch. I want to be able to export r4..r10 separately, fix the problems in each commit and reapply to a new branch. Does that make sense in bzr? [12:55] amitk: Hmm [12:55] amitk: Perhaps fastexport does what you need? [12:56] jelmer: not from it's help [12:56] beuno: ok thanks, as far as I understand there are records stored in the .pack files and each record is compressed using zlib, correct? [12:57] xeviox, yes [12:59] beuno: ok, looking at the records it seems that a blank line is used as a separator between the records. Each record has 3 lines as header. The first is a string showing the compress lib (e. g. gcb1z for zlib), the 2nd and 3rd are numbers, what are they for? [12:59] amitk: is there a particular reason you would like to modify the existing revisions rather than just fix the branch itself? [12:59] xeviox, I don't know that much detail [12:59] lifeless does, not sure if he's still around [13:00] beuno: thanks for the help :D [13:00] lifeless: ping [13:00] xeviox, http://doc.bazaar.canonical.com/latest/developers/packrepo.html [13:01] jelmer: I don't want all the the mistakes I make to go out in the final set of commits that I ask to be merged [13:01] beuno: thanks :D [13:02] jelmer: I wonder if my workflow is unsuited for bzr === mrevell is now known as mrevell-lunch === salgado is now known as salgado-afk [13:13] k, I'll come back later, thanks for the help :D [13:17] bob2: have you seen http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/2010-March/002925.html ? [13:22] hi [13:22] does anyone know where plugins are installed by default in ubuntu? [13:24] there's a bzr-notify running [13:24] Stavros: usually /usr/share/pyshared/bzrlib/plugins/* [13:24] ah, thanks [13:25] hmm, anyone know why bzr-notify would be running? i don't have that plugin as such [13:26] bzr-notify is not a plugin, it's a separate app [13:26] it lives in /usr/bin/bzr-notify [13:26] oh [13:26] Stavros: It is a daemonm, and is started by /etc/xdg/autostart/bzr-notify.desktop [13:27] i don't see it in the packages i installed, how can i remove it? [13:27] Stavros: it's part of bzr-gtk [13:27] ah, thanks [13:29] jelmer: i removed that and it's gone, thanks === mrevell-lunch is now known as mrevell === Chex_ is now known as Chex [15:26] I'm having problems with a "bzr branch" complaining about a publickey permission problem and I can't see what it is (most likely a simple user error). Is there any way to get a debug log message of what is happening? [15:29] what means this? I can't find any info -> bzr --no-plugins [15:35] JamieBennett: Hi; Usually it's easiest to see if you can use sftp to the same host [15:35] Breaking_Pitt: I'm not sure I understand your question? [15:36] jelmer: what can I do to test this? I thought it was a key issue but looking at my launchpad page and doing a gpg --list-keys it seems I have the right key on this system [15:37] JamieBennett: try connecting to launchpad using 'sftp -vv bazaar.launchpad.net' [15:38] is there some tool that can show statistics on who committed what portion of the code? [15:40] loxs: you can use "bzr annotate" (or "bzr qannotate") to see who was responsible for what lines of the code in a particular file [15:40] jelmer, yeah, I know that, but this doesn't solve my problem :) [15:40] loxs: "bzr stats" (from the bzr-stats plugin) will print a list of how many commits every committer has made [15:40] jelmer: seems its trying to log me in as jamie rather than jamiebennett, mmm [15:41] JamieBennett: ah, sorry - you might need "sftp -vv jamiebennette@bazaar.launchpad.net" in that case - bazaar knows your username but sftp doesn't [15:41] hmm, thanks I'll check bzr-stats [15:42] probably can fix that with something in .ssh ? [15:45] Hi [15:45] jelmer: http://pastebin.ubuntu.com/393336/ [15:46] JamieBennett: is any of the ssh keys reported by 'ssh-add -l' listed on your lp page? [15:53] i don't know what means the flag --no-plugins [15:56] Breaking_Pitt: See "bzr help global-options" [15:56] Breaking_Pitt: basically it prevents Bazaar from loading any of the plugins (see "bzr plugins" for a list of available plugins) [15:57] ok jelmer [15:57] tthanks [16:00] Breaking_Pitt: yw [16:11] jpds, that --show-diff has really come in handy lately, thanks for recommending it. [16:12] JFo: No problem. === deryck is now known as deryck[lunch] === IslandUsurper is now known as IslandUsurperAFK === deryck[lunch] is now known as deryck [18:10] maxb: hi === IslandUsurperAFK is now known as IslandUsurper [18:19] * kfogel is away: switching consoles for a bit, back soon === zekopeko_ is now known as zekopeko === radoe_ is now known as radoe === salgado-afk is now known as salgado [20:32] morning folks [20:33] hi speakman [20:33] I don't really get the "loom" thing. And I'm not really sure what's the difference between a SCM and Quilt either. Any tip of documents to read about it? [20:35] (actually I'm a little confused about what's a proper workflow in bzr using launchpad and a random bunch of people in a very-early stage in a new project) [20:39] speakman: a VCS records history - quilt or loom allows you to work with inter-dependent changesets that can be modified [20:41] jelmer: but how does that differ from branching? [20:41] speakman: revisions don't change, quilt patches do [20:42] beuno: ? [20:48] oh... but... patches becomes revisions..? [20:48] I think I might not be the best person to explain this. [20:48] sorry :-/ [20:51] speakman: you're using launchpad and bzr? [20:53] jelmer: it's ok :-D [20:53] lifeless: yes we do [20:54] speakman: great. So, do whateever you like with bzr: it tries to keep out of your way. [20:54] speakman: ignore looms; ignore quilt [20:54] lifeless: yes, I've been using bzr for a couple of years by now :) [20:54] But there are still some workflows I just can't figure how to do "right" [20:54] looms are for distro folk collaborating on won't-be-merged stuff [20:55] speakman: ok, I got the wrong bit of the stick :). Can you tell me about the workflow that isn't working for you? [20:59] First; I'm currently the only one with write permission to the projects primary target branch. Other contributors makes their own branch of that branch and do their work on their branch. But when finished with one feature (with all revisions pushed to ~username/projectname/my-new-feature and a merge requests sent) how do they get on with the next feature? Re-branching the primary target branch once again? [21:00] speakman: sure [21:00] speakman: they could fairly easily do 'bzr pull lp:project --overwrite' [21:00] speakman: or if they have a shared repo setup, 'bzr switch trunk; bzr pull' [21:01] shared repo setup..? [21:01] never heard of "switch"... [21:01] do this somewhere innocuous [21:01] bzr init-repo --no-trees project [21:01] cd project [21:01] bzr branch lp:YOURPROJECT trunk [21:02] bzr checkout --lightweight trunk working [21:02] cd working [21:02] now, to make a feature branch: [21:02] bzr switch -b newfeature [21:02] # hack hack hack, can push etc [21:02] # back to trunk [21:02] bzr switch trunk [21:02] # new feature [21:02] bzr swich -b newfeature2 [21:02] #back to feature1 [21:03] bzr switch feature [21:03] (btw, you can do that in one step: bzr branch --switch trunk newfeature2) [21:03] * speakman is practising as we speak... hold on [21:04] luks: not with the same magic path lookup, last I looked. [21:04] luks: we should get it doing that though [21:04] oh [21:06] is this documented somewhere? it really sounds useful, and I even didn't know about it! [21:06] sure is [21:07] this looks especially useful in python projects, where the path is part of the module namespace [21:08] anyone of you worked with Django? [21:09] not really [21:09] jelmer: how did you go on bug references? [21:11] however -- in general, python projects relies on the current working directory name. Using bzr all branches have their own working dir name. [21:11] jelmer: hey there... any thoughts on when a new bzr-builddeb package is going to be released to the ppa? [21:11] lifeless: for commitfromnews ? Haven't spent any more time on it yet [21:11] mtaylor: hey [21:11] jelmer: I might do a yak shave this morning then. [21:11] mtaylor: No idea, I'm not sure who's doing the PPA uploads - do you know? [21:11] ping john ferlito [21:12] via mail [21:12] lifeless: that'd be awesome - did you see my wip branch? [21:12] jelmer: no [21:12] jelmer: I don't ... I just know that I can't install bzr-builddeb on my debian build machine without it breaking bzr [21:12] jelmer: I was going to start o bzr core with a new hook [21:12] I do _so_ love commitfromnews [21:12] jelmer: should I just install from lp:bzr-builddeb? [21:16] mtaylor: join the bzr packing team and fix the ppa ;) [21:16] lifeless: heh. I'd never thought about doing that :) [21:18] mtaylor: Yeah, I'd either ask johnf for an update or switch to lp:bzr-builddeb [21:19] jelmer: cool [21:19] thanks! [21:20] jelmer: branching bzr-builddeb worked [21:21] * mtaylor now wants a command "bzr branch-plugin" which translates "bzr branch-plugin builddeb" into "bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb" ... [21:23] mtaylor: talk to Beuno :-) [21:24] Is shared repo a way to work around this python issues? [21:26] Or should every python project have a "container" directory (where the setup.py usely exist) [21:27] questionmark... :) [21:28] mtaylor: write it ;) [21:28] speakman: I don't know what your python issues are [21:29] lifeless: I don't want it that badly - I want it sort of in the "I'd really like for someone to walk over and hand me a plate of freshly baked cookies" sort of way [21:30] mtaylor: I've started trying to aggressively yak shave [21:30] how can i revert on a lightweight checkout of a bzr:// ? [21:30] it says Transport operation not possible: readonly transport [21:30] mtaylor: https://code.edge.launchpad.net/~lifeless/lptools/lp-project/+merge/21124 was last nights [21:30] chx: its a bug, its fixed in trunk I believe [21:30] lifeless: wow [21:31] lifeless: BOO YAH [21:31] or if not in trunkm then the patch is getting reviewed at the moment [21:32] checking out bzr/trunk is not fast. [21:36] lifeless: 22:11:23 < speakman> however -- in general, python projects relies on the current working directory name. Using bzr all branches have their own working dir name. [21:37] "from myproject.modules import MyClass" [21:37] chx: have you done lp-login ? [21:37] speakman: most python projects have myproject as a directory at the top of their branch [21:37] lifeless: ok. that's how to solve it? [21:38] (it's a pinax based project I'm currently into btw) [21:39] lifeless: how can i convert my tree into something revertable instead? [21:40] bzr reconfigure --branch should do it [21:44] * beuno hides [21:47] just came to get some help...but a reinstall of the software fixed my problem...so ill just say hi! [21:52] jelmer: so, where is your branch? [21:52] lifeless: https://code.edge.launchpad.net/~jelmer/bzr-commitfromnews/extractbugnumbers [21:53] ok [21:53] I'll see about getting the bzr infrastructure togetherr [21:54] yarrr [22:04] Doing on-the-fly conversion from to (remote). source [22:04] This may take some time. Upgrade the repositories to the same format for better performance. [22:04] what's that? "(remote). source" ? [22:08] launchpad [22:08] how do I upgrade + pushing back? [22:08] you can use bzr info -v to find out mor details [22:08] oh [22:08] there is an upgrade button on the launchpad branch page [22:09] oh! cool :D [22:21]