[00:00] lifeless: I think it comes down to two things: in order to do branch management when using a lightweight checkout you have to change directories (since the branches are in a different location, you have to "cd ../branches && bzr branch branch-foo branch-bar && cd ../wt && bzr switch branch-bar" and "bzr switch" is too slow [00:00] jelmer: ok [00:01] so the former - heres what I do [00:01] bzr init-repo --no-trees proj [00:01] cd proj [00:01] bzr branch/init trunk [00:01] bzr checkout --lightweight trunk working [00:01] ln -s $(pwd)/working ~/.bazaar/plugins/proj [00:02] hmm, isn't there a "bzr switch -b" or something lately added? [00:02] SamB: yes [00:02] today though, I use [00:02] bzr push ../new-branch; bzr switch new-branch [00:03] so its not ideal, but it is pretty easy [00:03] not bad [00:03] lifeless: ah, I hadn't considered "bzr push" [00:03] jelmer: well, can also spell 'bzr branch . ../new-branch' [00:03] or bzr branch ../trunk ../new-branch, if I want to be absolutely sure about provenance [00:04] lifeless: but (now that we're talking about UI) I still consider this a big hassle compared to colocated branches [00:04] jelmer: switch _should_ be very fast. please file bugs if its slow [00:05] jelmer: typing .bzr/branches/new-branch would be equally awkward, I should think. [00:05] jelmer: I think the big UI win of colocated branches isn't the colocation, its the search-path and location glue [00:05] this isn't to say I don't like colocated branches/git style branches; just that I'm trying to really understand what makes things good [00:06] lifeless: yeah, perhaps git style branches is a better description than colocated branches. [00:07] lifeless: the setup you did is nontrivial (more than one command) [00:07] lifeless: and the combined action of creating and switching to a new branch is more than one command [00:07] so, we're trying to plan a better UI before making many random changes [00:08] jelmer: but have you seen jam's switch -b feature? [00:09] lifeless: it breaks looms :-/ [00:10] lifeless: please contribute any tips to GitStyleBranches ;-) [00:10] lifeless: but no, I hadn't. That does indeed make the second bit easier [00:11] jelmer: I'll fix looms up monday [00:11] I wonder if perhaps it should be in switch --new or something [00:12] lifeless: Yeah, --new would probably be more intuitive to new users [00:12] did it get into 1.17? [00:12] lifeless: -b does remind me of the git argument, but other than that it doesn't make much sense [00:12] lifeless: as far as I can tell it's only in bzr.dev [00:13] lifeless: it's not in rc1 at least [00:15] jelmer: well, the long name can be meaningful [00:16] short names are often pretty crazy, so probably won't bother people [00:19] I don't think thats a good reason to use a crazy short option [00:20] well, it's not quite crazy either ... [00:20] it actually *does* do a "bzr branch" under the covers, doesn't it? [00:20] bzr branch? [00:20] yes [00:21] so how is -b a crazy short name for the flag? [00:21] branch --branch [00:21] would be the long version, if -b stands for branch [00:21] eh? [00:22] I thought it was "switch" we were talking about, sorry [00:22] for switch I proposed --new [00:22] in a loom you probably want a new thread [00:22] in a pipeline a new pipe at the current place {like looms} [01:11] who should I talk to about bzr-fastimport? [01:17] SamB: ianc [01:23] hmm, is there some command-line equivalent of BZR_PDB=1 ? [01:29] jelmer: yes, branching into a dir inside a git repo [01:33] SamB: not that I'm aware of [01:34] 'twould be useful for running bzr under gud, I think [01:34] bob2: that's the equivalent of trying to push from bzr into git, which doesn't work yet [01:34] SamB: gud? [01:34] jelmer: basically, s/gud/emacs/ [01:35] gud is the bit that integrates debuggers into the UI [01:35] so, like, you'd see stuff in the left margin [01:47] jelmer: cd gitmanageddir/something/somethingelse ; bzr co /brbranch ? [02:08] SamB: what do you mean command-line equivalent? [02:15] lifeless: I mean, an argument [02:15] that is, a flag [02:15] no [02:16] for some reason M-x pdb doesn't like it if I enter an environment-variable setting before the command to run :-( [03:04] lifeless: question on MOTU process... [03:04] lifeless: there are two different processes, one for packages that are in ubuntu already, and one for ones that aren't... do packages that are auto-imported from debian but have no truly ubuntu specific package count as the former or the later? === vxnick is now known as vxnick-AFK [03:17] uhm [03:18] there aren't really two processes [03:18] or I don't know what you mean [03:18] are you talking about new packages, or changes to an existing package [03:32] lifeless: well, that's the question - if the package is in but only via automatic debian import, and I want to upload a version to ubuntu - does that count as changes to an existing package, or as a new package? [03:32] its a change to an existing package [03:33] ok [03:33] but the process is the same [03:33] which is why I don't really know what you mean [03:33] so - there was this place that said changes to existing packages shouldn't use revu, but instead should attach debdiffs to bug reports against the package [03:35] lifeless: https://wiki.ubuntu.com/SponsorshipProcess ... linked to from https://wiki.ubuntu.com/MOTU/Packages/REVU [03:36] ok [03:37] so uhm, I guess thts a different process [03:37] but the basics: review the delta, universe-sponsors-queue, upload, are the same [03:37] regardless of new package or change to existing [03:37] sure... [03:38] but my process to request review as an external-n00b-luser is quite different [03:38] and in fact, REVU is meant to be replaced by lp code reviews eventually ;) [03:38] k [05:39] jelmer: nice, that subunit you uploaded actually works ;-) [05:39] I mean, not only can I use it, but dpkg stops uselessly trying to compile the code for Python 2.3 and is now *aware* that it works ;-) [05:40] (oddly enough, I could actually use it even before that :-) [06:05] jelmer, http://code.mumak.net/2009/07/unittest-it-aint-broke-lets-fix-it.html [08:10] Anyone know how to use the bzr pager plugin? [08:10] I figured I could just install it and then a command like "bzr cdiff" would just do the right thing and go to less with more than a screen of output [08:10] But apparently that isn't right. [10:22] hi [10:22] hi jml [10:22] hi Jesse1 I mean :-) [10:22] jelmer, hello :) [10:22] I'll take your greeting as it stands. [10:22] i'm new to irc [10:22] and bzr [10:23] i'm thinking of using bzr to track wikipedia entries [10:23] so as to reduce the load on wikipedia servers [10:23] but i don't know how i can manipulate the revision ids a la bzr-svn [10:25] i'm not a registered freenode user, so i'm not sure if what i said was heard at all... [10:25] We hear you :-) [10:26] sweet [10:27] as i understand, bzr-svn does the rev-id manipulation at SvnBranch level, so branching from a svn repo already gets the cooked rev-id's [10:28] but what i want to do doesn't sound as complicated as that [10:29] s/what/what if/ [10:29] ouch that was wrong [10:30] so i'm thinking if i can generate revision ids for wikipedia entries e.w.o/w/foo&oldid=1234 [10:30] as en.wikipedia.org-foo:1234 [10:30] and stuff such a revision in the repo? [10:31] Jesse1: yes, but you'll probably have to do the same sort of thing as bzr-svn to do so [10:31] they subclassed bzrlib.branch.Branch [10:31] wait, "they" is actually you [10:32] Jesse1: alternatively, you could create a Python script that just does an import from wikipedia into a bzr branch [10:32] a silly etiquette question: shall i prefix my messages with the intended recipient? [10:32] and how do i massage the revision ids? [10:33] Jesse1: you can't change revision ids after the revision has been added, but when creating a new revision from within the bzr API you cna specify the new revision id [10:33] Jesse1: perhap you can generate a fast-import file of your data and import that? [10:33] * spiv isn't really here... [10:34] i recalled parent revisions can be changed? [10:36] jelmer: so i can specify the new revision id when creating new revision? [10:36] Jesse1: parent revision ids can't be changed either [10:36] Jesse1: yes, when creating a new revision you can specify the new revision id (but only from the API, this is not exposed on the command-line) [10:36] suer i understand [10:37] WorkingTree.commit() doesn't seem to have a place for revision id? [10:39] Jesse1: it does, IIRC it's called "rev_id" [10:39] since bzrlib.workingtree.WorkingTree doesn't have docstring on commit() [10:39] i can only guess from the argument names [10:39] and i guess rev_id is parceled in *args? [10:40] * jelmer nods [10:40] what's the triple star in front of your name? (sorry i'm such a newbie) [10:41] oh, it indicates an action [10:41] oic [10:41] thx [10:42] undocumented *args is eveil... [10:43] moin [10:43] thanks jelmer jml & spiv [10:43] moin ronny [10:43] i'll look more into the docs and try [10:44] Jesse1, I didn't do anything :) [10:44] oh really [10:44] there's never too much gracias [10:45] bye === vxnick-AFK is now known as vxnick [13:43] hi, I'm using bzr-svn to push my bzr branch up to the wordpress svn server and I've just realised it's trying to download the revision info for the entire repository [13:44] did i screw up somewhere or is that just how it works [13:44] fsvo download, that is how it works [13:45] basically I had my bzr branch that I work in and just did: bzr push http://svn.wp-plugins.org/myplugin/trunk/ [13:45] but the revision info getting of the entire repository bzr-svn needs to do, it caches, and is pretty fast [13:45] Muttley: which version of bzr and bzr-svn? [13:46] it's windows release (don't hate me) 1.16.1 [13:46] not sure the plugin version [13:46] Muttley: don't worry, we won't hate you fot using Windows. [13:47] Muttley: `bzr plugins` will tell you, but bzr-svn is pretty strict in which versions of bzr it works with [13:47] hehe, I'm actually a linux guy but I've been doing this dev in windows [13:47] so that is probably 0.6.2 [13:47] Muttley: don't hate yourself then? ;) [13:47] 0.6.3dev [13:47] LarstiQ: hehe [13:48] Muttley: I imagine the wp-plugins repository is huge? (Ie, where is bzr-svn's progress bar at?) [13:48] just the wordpress plugin repository is quite big [13:48] progress bar about 25% [13:48] been going about an hour [13:49] I'm out in asia at the moment so it's going between 5 and 10 K/sec [13:49] up to 20meg so far [13:50] is there anyway around it or am I just in for a long night? :) [13:52] Muttley: could you paste the line it is showing? It has multiple phases and I'd like to be sure it is at the phase I think it is at [13:53] [####/ ] http 20435KB 13KB/s | fetching svn revision info 3 [13:53] I think that 3 is actually more like 3xx or 3xxx [13:53] just it cut of at the useful 80 char cmd promt limit [13:54] my plugin trunk was created a few hours ago and was revision 136629 [13:54] ah [13:54] so it could be 3xxxx that it's currently on [13:55] Muttley: no way around this fetching svn revision info, but it is resumable, and will happen with any operation against that repository [13:55] evening AfC [13:55] ok, so if I kill it and start again tomorrow it'll at least continue from where it left off? [13:55] Muttley: yes [13:56] ok [13:56] thanks [13:56] Muttley: do you know if you have tdb or sqlite? [13:56] umm, pass [13:56] Muttley: bzr-svn grew a capability to use tdb for caching this info, which is way way faster [13:56] * LarstiQ wonders what the installer uses [13:56] Muttley: ok :) [13:57] yeah, I was tempted to go the whole route of grabbing the dependences and source but in the end it seemed easier to just get the all-in-one installer ;) [13:57] aye [13:57] thanks for the help [13:57] np [13:58] * AfC waves to LarstiQ [14:15] jelmer: do you know if python-tdb is available on windows? [14:15] LarstiQ: No, tdb hasn't been ported to windows (yet) [14:16] jelmer: ok, so Windows users are stuck with sqlite then [14:16] LarstiQ: yep, at least for now [14:16] k [14:33] can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder [14:36] alex-weej: you need to have python-nautilus installed [14:38] jelmer: i do have it installed [14:38] on ubuntu 9.04 btw === asabil_ is now known as asabil [15:58] how can I let bzr forget my lp-login? already deleted ~/.bazaar/authentication.conf, but it seems like it gets it again from somewhere else [15:58] Raim: ~/.bazaar/bazaar.conf [15:59] james_w: ah... thanks, too obvious ;) [16:24] how do i checkout a specific revision from bzr [16:25] thewrath: -r [16:25] bzr -r ? [16:26] -r to the bzr command [16:26] thewrath: say, `bzr branch url/to/source -r destination` [16:26] thewrath: could you elaborate on the task at hand a bit more? [16:27] just trying to copy a certain revision to another location [16:27] thewrath: for what purpose? [16:27] thewrath: for say making a tarball, you'd want `bzr export` [16:28] i am modifiying a joomla education build and i want to have two locations to have the same stuff [16:28] one like for hte live site and one for the dev site [16:30] thewrath: if I interpet that correctly, your original question was for how to deploy to the live site, right? [16:30] does that make ense [16:31] i wanted to createe another directory with the information from a certain revision [16:31] so i guess yes [16:32] thewrath: that sounds like something I would do with the bzr-upload plugin [16:32] thewrath: as I wouldn't do any development on the live site, only deploy [16:36] right [16:36] i had my dev site set up as i wanted to do for my live site so all i had to do was essentially move it over [16:36] right [16:36] wat does the bzr-upload-plugin do, does it come standard with bzr? [16:37] it doesn't come standard with bazaar, but is easy to install (will go over that in a bit) [16:38] thewrath: it creates the files in your working tree in a remote location, but doesn't store all the history [16:38] thewrath: and it is smart enough to only update it with the changes [16:38] thewrath: not the entire set of files again each time [16:39] thewrath: it is designed to work well for deployment on web application development [16:39] nbice [16:40] thewrath: you can either run `bzr upload` manually when you want to deploy something (optionally with -r to select a specific revision) [16:40] thewrath: or turn on automatic mode where it will upload on each commit [16:40] thewrath: how did you install your copy of bzr? [16:42] i am in windows so the msi beileve [16:42] *msi installer [16:42] ok [16:42] thewrath: does `bzr plugins` list the upload plugin? [16:43] no it does not when i run bzr plugins [16:43] ok [16:44] * LarstiQ isn't too experienced with the windows installer, so let's see how it goes [16:44] ok, [16:45] worst comes to worst i can just reinstll it [16:45] thewrath: `bzr --version` should have a 'Bazaar configuration' directory listed [16:45] thewrath: sure [16:45] ok yes it does along with others [16:48] thewrath: right, so if you cd there [16:49] thewrath: and then `bzr branch lp:bzr-upload upload` [16:49] thewrath: you'll get a copy of the upload plugin from Launchpad [16:49] thewrath: after which it should show up in `bzr plugins` [16:52] yeap its there now [16:54] thewrath: ok, so the usage is, for the first time, `bzr upload LOCATION`, and afterwards just `bzr upload` [16:54] thewrath: see `bzr help plugins/upload` and `bzr help upload` [16:54] thewrath: and/or the README file inside the plugin dir [16:55] ok [16:55] can i change that for each different bzr project? [16:56] thewrath: ah right, sorry, it remembers it for a specific branch [16:56] thewrath: so yeah, each different bzr project is independent in its upload location [16:58] so each bzr init remembers its own? [16:59] thewrath: `bzr init` is only used to start a new project, but if you mean each branch, yes [17:00] though you should be able to configure it for multiple branches in one sweep with locations.conf [17:04] hi, I've written a "patch" (it's childishly simple, but at least to learn something about python and bzr), how should I proceed to upload it? Just add it in a message to the bug? (https://bugs.launchpad.net/bzr/+bug/84659) [17:04] Ubuntu bug 84659 in bzr ""serve --allow-writes" allows more than you might think" [Medium,Triaged] [17:05] yea LarstiQ that is wat i meant [17:08] dvheumen: do you intend for it to be merged? Then `bzr send`ing it to merge@code.launchpad.net would be the thing to do [17:08] dvheumen: attaching it to a bug is possible but not something we do often [17:09] LarstiQ: well it's a first for me, so I'll do what's the most common practice [17:09] LarstiQ: so if you say that bzr sending is the best, i'll do that [17:09] dvheumen: it is [17:09] LarstiQ: okay, thanks for the info [17:10] dvheumen: if you expect a lot of discussion, you could also send it to the mailing list with a subject prefixed with [RFC] [17:11] but if it is childishly simple, probably not :) [17:11] LarstiQ: Well, it's basically a call to 'note' with a warning message, so I doubt it actually :D [17:11] (tagged as 'easy') [17:11] dvheumen: good :) [17:14] dvheumen: as a result of your `bzr send`, it should show up in https://code.launchpad.net/bzr/+activereviews [17:14] LarstiQ: ah, thanks, that's a good remark, I didn't know [17:21] LarstiQ: I'm curious, how do they match my patch with the bug report? [17:22] because I made this patch based on lp:bzr [17:23] dvheumen: ah, maybe I should have instructed you more carefully :) [17:24] If there's some FAQ to read, just point me to it ... I don't mind ... but I have no idea of how to approach submitting a patch to bazaar/launchpad [17:24] I expected to just post the patch file with a comment in the bug report [17:24] until I heard your approach :P [17:24] dvheumen: mention the bug in the subject, say 'add a warning for foo (#84659)' [17:26] can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder [17:26] okay, I'll be back in about half an hour and I'll give it a try, tnx [17:26] alex-weej: does the README of bzr-gtk mention anything? [17:27] dvheumen: k, see you then [17:27] LarstiQ: probably? [17:27] alex-weej: sooo? [17:27] * LarstiQ doesn't use a desktop environment [17:27] hardcore [17:27] it just said i need to install python-nautilus to use nautilus integration [17:27] i already have that [17:28] not really, I just am hopelessly ineffective in them [17:28] oh wait there is more actually, i need to symlink something to enable it [17:28] alex-weej: right [17:28] hm, nautilus needs proper plugin management :/ [17:28] thanks [17:30] LarstiQ: actually, turns out the plugin is just missing from the deb :/ [17:31] alex-weej: d'oh [17:31] alex-weej: which deb/distro is that? [17:31] ubuntu 9.04 [17:32] ho hum [17:32] no wait, i found it! it's bundled in with the rest of the bzrlib for some reason [17:32] even though it's a nautilus plugin [17:32] :F [17:32] alex-weej: mind filing some bugs on Ubuntu? :) [17:33] packaging error, yeah will do [17:35] nah still doesn't work, ImportError: cannot import name cmd_gannotate [17:37] i guess it has bitrotten :( [17:40] alex-weej: that is possible. Where does it try to import gannotate from? It is, or used to be, part of bzr-gtk [17:40] bzrlib.plugins.gtk [17:41] alex-weej: that's fixed in bzr-gtk trunk [17:44] hey all, anyone around who's pretty well versed with how bzrlib works? [17:45] I'm trying to understand how authentication works when accessing servers. I've found the code to do various commands in bzr, found the code that seems to get the password or prompt the user but I can't find the code that links the two [17:46] if anyone could point me in the right direction it'd be much appreciated :) [17:49] Pilky: have you found credential stores? [17:50] yeah, I've found the stuff in config.py [17:50] good [17:51] it's more a case of I can't find where commands like push and commit etc access those [17:52] Pilky: bzrlib/transport/ [17:54] Pilky: that is, commands don't do that, they try to connect to a location, and the underlying transport takes care of authentication [17:55] right [17:56] what I'm wanting to do is hijack the authentication prompt really [17:56] Pilky: for comparison, have a look at lp:hitchhiker, which builds on bzr transports [17:57] so instead of prompting for a password on the command line, I can pass in a password given to me by the user in a GUI [17:57] Pilky: in what way? Is it just because you want to prevent a UI.. right [17:57] yeah [17:57] Pilky: look at bzrlib/ui [17:58] Pilky: you want a UIFactory implementing get_password [17:58] Pilky: for a comparison of _that_ you could look at qbzr for a Qt UIFactory [17:58] ok cool [17:59] so that would allow me to stop it from prompting the user in the UI and I can just return my own password [17:59] Pilky: how you phrased your question at first I didn't know if I knew enough bzrlib, but I'm glad you just asked your question :) [17:59] heh [18:00] Pilky: if you so wish, though that might not be the right approach if I understand you correctly [18:00] Pilky: it is the way to not get prompting on the cli [18:00] well basically I'm building an Objective-C API [18:00] Pilky: but if you have something more of a CredentialStore, that api would be better [18:00] Pilky: I know :) [18:01] I want to be able to get the password from the Mac's keychain [18:01] authentication is the one thing that kills any project trying to tie into bzr using the CLI interface [18:01] Pilky: bzr-svn might already do something like that [18:01] well I'll have a look into bzr-svn and qbzr [18:03] Pilky: iirc jfroy added support for keychain authentication [18:04] Indeed [18:05] onnnne second [18:05] ah that would be useful [18:06] it is :) [18:06] if I can just write to keychain to set up authentication and get bzr to read from there it'd make things a LOT easier [18:06] at least for bzr-svn [18:09] jfroy: is it in your branch of bzr-svn or in the trunk? [18:10] neither [18:10] where is it then? [18:15] jfroy: ? [18:15] working on it :p [18:17] Cleaned it up a bit, pushing to LP [18:20] ah cool [18:22] hey, how can I "update" (in svn terms) to a previous revision? I've found 'revert -r #' but it leaves modifications (of newer revisions) behind. [18:23] dvheumen: you can't [18:23] bzr doesn't support doing that [18:23] your only option is to lightweight checkout to the revision you want [18:23] hmmmm... [18:23] e.g. bzr co --lightweight -r FOO some_directory [18:23] dvheumen: you can try clean-tree [18:23] but I probably could do: bzr remove-tree; bzr co -r # [18:23] And yes it's silly, and the bzr developers don't seem to think so [18:23] dvheumen: yes, that should also work [18:23] Pilky: nothing to delete [18:23] that should remove unknown files [18:24] dvheumen: try bzr clean-tree --detritus [18:25] Huh, hitting a ERROR: bzrlib.errors.IllegalUseOfScopeReplacer exception [18:25] Pilky: hold on :p [18:25] lol [18:25] I swear I'm going to regret taking this project on :p [18:25] at least I'm only committing a day a week to it at the moment [18:26] apparently, this is bad: from bzrlib.plugins.keychain import _keychain [18:26] (_keychain is an extension module in the plug-in, the plug-in itself is bzr-keychain (and the package name is keychain)) [18:26] Pilky: thanks, but it's too late :P [18:27] wasn't giving plugin names a bzr- prefix deprecated? [18:29] is it possible to tell bzr svn to do a branch from a certain revision (like git svn does?), without importing whole history [18:30] jfroy: if you have a project named bzr-xxx, it's directory in ~/.bazaar/plugins should just be xxx [18:30] garyvdm: that's what I have [18:30] I think the lazy imporer is using _foo for import foo [18:30] and so dies if trying to import a module actually named _foo [18:31] jfroy: Ok - sorry - I miss understood you [18:32] jfroy: you know if this works then it could simplify my code a huge amount [18:32] I could do it all using NSTask and NSXML* [18:32] oh it does work [18:32] which also simplifies the licencing [18:33] I use it all the time at work to interface with svn repositories [18:33] I licensed it under BSD [18:33] cool [18:33] garyvdm: urg no that's not it [18:33] what the heck is going on :| [18:34] my issue before was I'd have to hook into bzrlib directly so I'd need to make part of my code GPL licensed, but then the developer facing API would be MIT licensed and talk to the backend via distributed objects [18:34] basically, not very pretty :P [18:34] Is this valid inside lazy_import.lazy_import? [18:34]