[00:04] Ah, "bzr missing --theirs :bound" is slightly simpler. [00:13] Oh look, another layer violation... === arjenAU2 is now known as arjenAU [00:20] fullermd: layer violation? [00:23] Oh, it's another log on a long-standing gripe of mine. [02:13] hello folks. my repository has grown. is there a way to have bzr flush the rest of the revisions? from revision 1 to 68 and i want to flush revisions 1 to 30... that'll end my repository to have only from revisions 31 to 68. ? [02:13] nbjayme: why do you want this? [02:13] kind of defeats the purpose of a vcs if you're chucking out history [02:14] okay okay.... probably i worry too much of diskspace. :) he-he [02:15] nbjayme: if you're talking thousands of revs, sure [02:15] although personally that's still pretty small, at least for the repos I deal w/. either way, look into the pack command [02:16] poolie - split inv fetching mysql down to under 1sec/rev [02:16] nbjayme: how big is your tree? [02:18] lifeless: can you please give me permission to set priorities on testresources bugs? [02:18] nbjayme: I'd be bothering with that at the 100's of thousands of files & revisions [02:19] jml: whats the metaproject called? [02:19] lifeless: pyunit-friends [02:19] @ferringb... no not really that large.... i just want to make it minimal to lessen some bandwidth transfer. @lifeless, pretty small i would say.... [02:20] nbjayme: deleting history like that is *possible* but it will not result in a significant bandwidth reduction because texts are delta compressed [02:21] lifeless... okay.... i'm still around 8mb though.. :) [02:21] jml: I've put it in pyunit-friends, that may have done it? [02:21] nbjayme: how are you measuring that? [02:21] i go to nautilus and righ-click on the .bzr directory.... [02:21] nbjayme: that figure doesn't represent what is transferred [02:22] nbjayme: are you often copying the whole repository, or just updates? [02:22] nbjayme: there are transactional details that are not copied, and incremental pulls only copy new content anyway [02:22] lifeless: thanks, let's see. [02:24] the project is small, i'm still going to upload it in launchpad... :-) just wanna be a good netizen... he-he. yes, transfers to repo are faster after the initial commit or push. :) [02:24] lifeless: nope. There's no such thing as a driver or bugs supervisor for super-projects. [02:24] lifeless: the thing to do is make a team with you and I in it and set it as the bugs supervisor (or appoint me project maintainer, whichever works) [02:25] garh [02:25] so complex [02:26] jml: I think I'd like to stay as maintainer :P [02:26] lifeless: de jure at least [02:26] jml: of the day? [02:27] lifeless: "by law". often contrasted with "de facto" [02:28] :P [02:28] oh right [02:28] architecture astronauts R us [02:28] just filed my LP bug for the day [02:28] heh heh [02:29] (bug supervisor field requires a precreated team) [02:30] jml: https://edge.launchpad.net/~testresources [02:31] lifeless: I've joined, moderate me please. [02:33] done, you are now moderate [02:34] lifeless: thanks. [02:34] * jml is born to be mild [02:35] lifeless: we're saying that a commit to trunk is a release, right? [02:35] jml: yes [02:35] jml: 'early and often' [02:35] jml: can't get more early than every commit :P [02:37] * jml spams lifeless with bug mail. [02:37] too late [02:37] you already did [02:37] curious; fixing tracbzr, one thing I did was yoink out the revno in favor of revision_ids (will add revno at some point, but it complicates it); problem being, that's chunks of an email address most of the time. how are others handling the scraping potential there? [02:37] ...aside from just using revnos instead [02:38] lifeless: this is round #2 :) [02:40] ferringb: not sure [02:40] poolie_: I've put the usertest order back - because the numbers are a *lot* easier to read in the order I put together last week [02:42] ok [02:42] did you kill it too? [02:42] poolie_: eys [02:42] poolie_: fingers crossed .inv will be 'fast enough' now [02:43] its about 0.8sec/rev for me now [02:43] did you kill it twice or more? [02:43] on my laptop [02:43] yes [02:43] it looked like it disappeared a while ago i was just trying to work out why :/ [02:43] twice, once when I pushed my branch, and then again when I saw it skip .inv [02:44] sorry for any panic :) [02:56] bbiab [03:17] woo, python compiled the extensions on kerguelen [03:17] and selftest is running [04:17] poolie_: its pulling much faster; 1.7G used so far :P [04:17] poolie_: previously that took a day or so [04:17] great [04:21] spiv: hi [04:21] spiv: tell me where the smart server does error translation. [04:21] I have a bug that needs a-filing. [04:22] * jml finds it manually [04:23] jml: look at the bottom of bzrlib/remote.py [04:24] jml: that's where is mostly happens on the client side (although there's also some in bzrlib/transport/remote.py). [04:27] spiv: I get this when I push to a non-existent product on Launchpad: bzr: ERROR: Generic bzr smart protocol error: Permission denied: "Project 'no-such-product-xxx-flibble-ai-po' does not exist." [04:28] spiv: I have 99% confidence that we are raising an honest-to-goodness PermissionError from the bzr running on the server. [04:28] jml: which verb does -Dhpss reveal that to be in reply to? [04:29] Hmm, maybe BzrDir.open? There's a bug open about that one, I think. [04:30] 5.217 hpss call: 'mkdir', '/~jml/no-such-product-xxx-flibble-ai-po/branch', '' [04:30] 5.217 (to bzr+ssh://bazaar.staging.launchpad.net/%7Ejml/no-such-product-xxx-flibble-ai-po/branch/) [04:30] 5.569 result: ('error', 'Permission denied: "Project \'no-such-product-xxx-flibble-ai-po\' does not exist."') [04:31] jml: (https://bugs.launchpad.net/bzr/+bug/278673 is the bug I was thinking of) [04:31] Launchpad bug 278673 in bzr "Traceback when uploading to an invalid location" [High,Confirmed] [04:31] note that launchpad doesn't need to be involved [04:31] $ bzr push bzr+ssh://localhost/bob [04:31] bzr: ERROR: Generic bzr smart protocol error: Permission denied: "/bob": [Errno 13] Permission denied: '/bob' [04:32] jml: that's not a PermissionDenied error on the wire, that's a generic 'error'. [04:32] spiv: interesting [04:32] jml: so the problem is server-side. [04:32] mwhudson_: also interesting. [04:32] (and quite possibly still in bzrlib) [04:33] jml: bzrlib.smart.request.SmartServerRequest._call_converting_errors is probably the culprit [04:34] spiv: looks plausible. [04:34] jml: in fact, it appears that currently the only place that encodes a PermissionDenied error is an explicit except in bzrlib.smart.vfs.GetRequest [04:35] spiv: how many places does one need to list an error before it gets translated properly? [04:36] * jml finds https://bugs.edge.launchpad.net/bzr/+bug/246792 [04:36] Launchpad bug 246792 in bzr "permissiondenied not translated on creating branch over bzr+ssh" [Undecided,Confirmed] [04:36] jml: Ignoring tests, typically three. [04:36] spiv: that seems like at least one place too many [04:36] jml: server side, client-side vfs, client-side non-vfs. [04:37] The latter two can probably be unified somewhat sanely now. [05:32] I've kinda followed the mini tutorial, but I've got a question. I created a branch on my laptop, and then pushed that to my personal sftp server [05:32] but, none of the files are showing up on the server [05:33] ideas? [05:33] there is a .bzr directory on the server though [05:33] just, no files in the project folder [05:36] Linuturk: pushes to a remote location don't push a working tree too [05:36] Linuturk: the push-and-update or 'upload' plugins might be what you want [05:36] (or maybe you shouldn't care, the .bzr directory contains enough to share the branch) [05:37] hmmm, so, if my laptop died, would the files be safe? [05:38] or, is my laptop considered the primary repo [05:38] and, the other links just point to it? [05:38] no [05:38] the .bzr folder contains the complete history of the branch [05:39] if you go to the server and run 'bzr co' [05:40] Linuturk: the files would be safe. The .bzr directory contains all the data. [05:41] * Linuturk quietly installs bzr on the server first [05:41] lol [05:41] Linuturk: you can do "bzr log" or "bzr branch" or "bzr checkout" etc from that remote location. [05:42] ooo, what's the bzr co ? [05:42] checkout? [05:43] o sweet [05:43] and, that pulled from the local .bzr [05:43] not my laptop [05:43] I'm looking to use bzr to control system configs on my servers [05:44] and, it seems like this will work great [05:45] that sound good? [06:52] it does [07:07] hi all ! [07:08] hello. [07:29] Sometimes I think it'd be nice to be able to make a loom post hoc from a series of commits. So I could just start hacking on a non-loom branch, then go e.g. "loomify --base-from ancestor::submit", and get a loom with a thread per commit. [07:29] Well, by "sometimes" I mean "just now" :) [07:30] A *thread* by commit ? Wow, care to give a bit more context ? [07:30] vila: the use case I have in mind is where I've just started hacking without being sure in advance what shape it'll take, or how far I'll want to go. [07:31] vila: so I do something interesting, commit it, do some more, commit, etc. [07:31] vila: and then I start thinking "this would make a nice series of changes to submit for merging, but I'd like to tweak some of the earlier steps" [07:32] If those steps were already in a loom, then I'd be set, but in this case I didn't have that foresight. [07:32] So certainly you want somme commitS in the same thread no ? [07:32] But if I could trivially make a loom pre-populated with threads based on my commits, then I wouldn't need the foresight. [07:33] Sure, probably. But it's easy to collapse threads. [07:33] It's harder (not impossible, just not as easy) to split a thread. [07:33] I learn recently and with a bit of pain that combine-thread is more detructive than I thought [07:33] That's true, but that's a separate problem :) [07:34] So how do you collapse threads then ? [07:36] vila: "bzr combine-thread" [07:37] vila: e.g. if I have commits r1, r2 and r3, and corresponding threads t1, t2, t3, then from inside t2 "bzr combine-thread" will leave me with t1, t3. [07:37] I'd like at least a warning there when I'm about to shoot in my foot :) [07:38] spiv, sorry, havent been able to get round to the whole bzrssh thing yet... it is on my todo list though [07:41] vila: sure, or at least an easy way to unshoot the foot [07:42] Mmmm. Self-inflicted wounds. [07:42] I think my use case was: r1, r2, r3 in threads t1, t2, t3, then in t2, add r4, combine-threads, boom, r4 is gone [07:46] vila: spiv: patches, appreciated, kthx [07:46] vila: right. I think it ought to require a --force when a combine-thread will lose a revision not merged in later threads. [07:47] lifeless: things would more easier if the loom test suite was passing :-/ [07:47] spiv: bzr create-thread; bzr pull . -r thread: [07:47] be even [07:47] vila: abentley has fixed that [07:47] lifeless: I know, just thinking out loud before I start hacking on a new idea. [07:50] lifeless: huh ? bzr missing lp:~bzr-loom-devs/bzr-loom/trunk : Branches are up to date. [07:51] damn lp:~abentley/bzr-loom/stuff [07:51] why isn't that merged in trunk ? [08:12] hi vila [08:21] vila: wait, you're cursing me for fixing stuff? [08:21] abentley: Surely not !!! I didn't think you were online ! THANKS A TON :_ [08:22] :) [08:22] vila: of course, I *shouldn't* be online. [08:23] But you used my nick, so I'd have seen it in the morning. [08:24] hehe, I didn't realized there was 'damn' and 'abentley' so close :) [08:24] abentley: I was willing to review your user stuff but jam beat me to it :) (let's bring him into this too ;p) [08:25] lol [08:26] spiv: just notice your --force remark, agreed [08:26] abentley, lifeless, spiv: so what's the policy to bring remarkable abentley work merged into trunk ? [08:26] :-) [08:28] spiv: I kinda want that thread-per-commit thing every now and then. But usually I just want to split a thread at a given revision. [08:29] spiv: So given r1, r2, r3 in a thread, I want to create a new thread with r3 and change the existing thread to have r2 as its head. [08:29] spiv: Which is doable, if a bit annoying. [08:52] abentley: yeah, that would be good. [09:32] hi spiv [11:23] i need a nudge in the right direction... i have checkouts via bzr:/localhost working, but want to only be accessible over ssh - any tips / links? === Pilky_ is now known as Pilky [13:17] abentley: ping [13:18] I'm just pushing a trivial branch at lp:~vila/bzr/2843443-docfix [13:18] sudden;y bzr says: Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://vila@bazaar.launchpad.net/%7Evila/bzr/ [13:18] vila: pong [13:18] Hurrah, did I think, automatic stacking ! [13:18] But then the push seems to take as long as usual... [13:18] Should I file a bug ? [13:19] Or did I misunderstood something ? [13:19] vila: Are both the branch and repo in 1.6 format? [13:20] scratch that. Yes, it should be giving you auto stacking, and shouldn't take as long as before. [13:21] bran/format: Bazaar Branch Format 6 (bzr 0.15) [13:21] and the message is strange, what is '/~bzr/bzr/trunk' ? [13:21] *I* suspect it's on launchpad, but yet [13:22] vila: it's a host-relative path. [13:23] what host ? mine ? launchpad ? the target branch's ? [13:23] ohhh, you mean an hpss one and it doesn't know its name ? [13:24] vila: We stack on /~bzr/bzr/trunk rather than bzr+ssh://vila@bazaar.launchpad.net/~bzr/bzr/trunk so that it works over all protocols. [13:24] It is relative to the target branch. [13:24] Ha, some problem than yesterday, or related at least [13:26] for clarity it would be nicer if the host was specified or even the url used internally no ? [13:28] vila: It's basically a question of precision vs accuracy. [13:29] The value we are writing to branch.conf is literally /~bzr/bzr/trunk [13:29] If we change it the way you're suggesting, then we can't tell from that message whether it will work over multiple protocols. [13:29] I see [13:30] How about "Using stacking branch /~bzr/bzr/trunk from branch.conf" or something ? [13:31] and I stop there :) [13:31] vila: You mean "Writing stacking branch /~bzr/bzr/trunk to branch.conf"? [13:32] wow, you mean this message is emitted when writing branch.conf ? [13:32] if that the case, yes [13:32] I will be happy with that, more even as it make it clear that lp is doing it [13:33] it's doing that on the host? If so, I think stating that might be good. [13:34] james_w: No, it's not. [13:35] oh, ok [13:35] vila: lp is not doing it. bzr is doing it. lp is just providing a file that suggests a location. [13:35] vila: the choice to follow lp's suggestion is made by bzr. [13:36] what is the file name you're referring to ? [13:39] vila: bzr+ssh://abentley@bazaar.launchpad.net/%7Ebzr/bzr/.bzr/control.conf [13:41] or for the branch you're pushing, bzr+ssh://bazaar.launchpad.net/%7Evila/bzr/.bzr/control.conf [13:43] Is there a way to set the parent of a branch from the UI, without having to do a ``bzr foo --remember``? [13:46] Odd_Bloke: if you count vim as a UI [13:48] It seems like there should be a way to do it, but I'm not sure to what extent we want to avoid people editing the config files under .bzr... [13:53] It would help if you tell us *why* you feel that need just now [13:54] Because ISTM that you need to do that *before* issuing a bzr command which may be laking the --remember option :) [14:07] vila: You say about AuthenticationConfig._save: "Save the config file, only tests should use it for now." [14:08] vila: Is that because it's not atomic? [14:09] Not more nor less than other config, but the true reason was because bzr never modifies it [14:09] Are you working on that right now ? [14:21] vila: The upstream location has moved, and the user wants to do this while they're doing the move, rather than next time they actually want to perform an operation. [14:21] s/upstream/parent/ [14:23] Odd_Bloke: I see [14:25] vila: Yes. [14:26] abentley: ok, I'll work on something else then, I'm looking at your previous patch anyway [14:28] vila: As I mentioned to jam, we might want to support different authentications for sftp and bzr+ssh eventually. [14:30] I didn't see that, can you explain why, it sounds strange [14:31] vila: Well, we support different authentications for other protocols. [14:31] you can already differentiate on port or on path [14:32] vila: http and ftp can also be differentiated on port. [14:33] sure, all schemes are handled the same [14:33] but sftp and bzr+ssh really use ssh [14:33] and the remote host will handle them with the same authentication [14:33] vila: But is that an implementation detail? Is "sftp" not a more obvious scheme for controlling sftp? [14:34] hmmm [14:35] I know that for launchpad, it will be convenient to specify 'ssh'. [14:35] I don't want users to define the same settings for sftp/bzr+shh or http/bzr+http [14:37] I'm not proposing replacing 'ssh'. [14:37] * vila hopes jam is not around and catch bzr+ssh typo... [14:37] What are you proposing ? [14:37] that sftp and bzr+ssh are handled as ssh aliases ? [14:38] I'm saying that one day, we may want to support "sftp" and "bzr+ssh" as additional schemes in authentication.conf [14:39] I don't understand what that means [14:39] Currently we use auth.get_user('ssh', will that change ? [14:40] vila: Yes, it would change to if auth.get_user('sftp...) is None: auth.get_user('ssh'...) [14:43] Do you have a need to specify, for the same host, different credentials or do you just want to be able to use sftp/ssh/bzr+ssh in the authentication.conf file interchangeably ? [14:44] vila: Neither. [14:44] So what ? >-< [14:44] It would not make sense for bzr+ssh to affect sftp. It would not make sense for sftp to affect bzr+ssh. [14:44] It makes sense to specify only once the credentials that can be used for both [14:45] And you would not *need* to specify different credentials for the same host. You could specify 'ssh' instead. [14:46] And it may even be mandatory to store them in things like OS X keychain or gnome keyring, i.e. sticking to known schemes [14:46] but if I use sftp and connect to bzr+ssh the credentials will not be found ? [14:46] but if I define sftp credentials and connect to bzr+ssh the credentials will not be found ? [14:47] vila: Right. [14:48] Eerk, what's the point then ? [14:55] While writing the spec I *did* use sftp until I realized that it will be a trap for the user because all the remote host knows is users or keys for ssh, users for ftp, users for http, etc [14:55] Hello. I am migrating from CVS. Is there a way to get Bazaar to either preserve mtime, or set the mtime of checked out files to the date of the last file change? [14:59] vila: There are certainly cases where users have multiple accounts on one machine, one for shell access, one for Bazaar. [14:59] vila: I haven't come up with a plausible reason for having two accounts, both used for Bazaar. [15:00] You also need to come up with a way to handle that on the remote host [15:00] but it may be possible with different ports [15:00] abentley: on the way to bed... but you might like to know that the losa's run two accounts on launchpad's code hosting service from one unix account, on a pqm machine [15:01] vila: I don't see what the problem is. It's easy to have multiple ssh accounts. You just specify username. [15:01] abentley: (both accounts are for separate unrelated private branches) [15:01] anyhow, dunno if that matters; gnight everyone [15:02] night lifeless [15:02] vila: does that mean bzr+ssh is the most preferred way. i use bzr sftp. :( [15:02] ? [15:02] gnight lifeless. [15:02] nbjayme: that's totally unrelated but bzr+ssh should gives you better performances :) [15:03] okay... thanks. :) [15:03] nbjayme: we are discussing how to describe credentials in authentication.conf [15:05] abentley: the only problem I have is that declaring sftp credentials leads to bzr+ssh credentials being not found except if use ssh, go explain that to the average user :-) [15:06] vila: Anyhow, as I said, I'm not interested it doing it now. [15:06] ok [15:07] abentley: what is the scope of you modification then ? Writing an authentication.conf file when launchpad-loging is used ? Or more ? [15:09] LOSA: ping, pqm blocked [15:12] vila: Also, writing an authentication.conf entry when it discovers that there is a configured login, but no corresponding authentication.conf entry. [15:13] vila: But I think that's all. [15:13] ok, great, I can work on other parts then [15:21] Bazaar does not set mtime of checkout out files (which I would like), but when doing "bzr diff --using=...", the old/* files it creates have the mtime set (so it is possible). [15:21] Should I submit a patch? [15:22] Any bzr wizards around right now? [15:23] pysquared: Setting the mtime to the stored date messes up build systems. We do not want that. [15:24] I did not realise until I started using bzr how much I used mtime as a visual clue. i want that. [15:24] Perhaps a checkout --restore-mtime option? [15:25] I hate coming back to work on a tree, doing a checkout and all the mtimes are the same. Anyone else find this? [15:26] pysquared: This has been discussed on the mailing list in the past. You should probably read up on it before trying to land such a patch. [15:27] abentley: thanks, I did search a bit but found nothing, so I asked here, you guys are always helpful. I will look again. [15:29] pysquared: http://search.gmane.org/search.php?group=gmane.comp.version-control.bazaar-ng.general&query=mtime [15:30] pysquared: The ones about "revert" would also apply to checkout. [15:30] abentley: fantastic [16:41] Hi. I have a bzr repository that I'm trying to make a svn repo from, for a couple of friends to use. I'm having problems getting things working here. Could anyone tell me how I should do this? I'm probably just doing it wrong, but I'm getting a lot of weird errors (Everything from segfaults to AttributeErrors). I'm using bzr-1.3.1ubuntu0 and bzr-svn 0.4.9-1. [16:46] qebab, please try a more recent version of bzr-svn [16:46] jelmer: okay. As to how to do this, I svnadmin create a repo, svn co it somewhere, and then I bzr push to it? [16:47] or is there further magic I need to work [16:48] qebab, there's no need to svn co it [16:48] just "bzr svn-push /trunk" [16:49] cool :) === cprov is now known as cprov-lunch [16:54] i recently read in the launchpad news about stacked format. and, it's blazingly fast in uploading my large repo but under +junk. now I have a repo associated with a project... i tried --overwrite but it did not update the remote repo's format. must i really delete the project's branch and reupload / push? [16:55] i meant *delete the focus branch in launchpad* and push my local branch? [16:57] nbjayme, yes, I think so [16:58] okay thanks!.... by the way, congrats to the devs for the great feature. :) [16:59] jelmer: when running make for bzr-svn, it gives me this: /bin/sh: rst2html: not found [16:59] jelmer: is that going to be a problem? [17:00] qebab: That's presumably just for docs, but you could just install it? [17:01] Odd_Bloke: the apt package was apparently not recent enough :) [17:08] jelmer, qebab I don't think there's a requirement for the target branch to be in format 1.6. [17:09] abentley: Sorry, I think I'm missing some context [17:10] jelmer: Sorry, I meant nbjayme [17:11] jelmer: I don't think there's a requirement to update the format of focus branches in Launchpad. [17:11] abentley, ah, indeed [17:12] abentley, related to that, it would still be nice to have a 'upgrade' button or "bzr upgrade" on a HPSS connection work a bit better ;-) [17:13] jelmer: Yes, it does, but upgrading is async, and would have to run on a non-web machine. Therefore a job handling framework is required. I have been working on one. [17:14] jelmer: I thought bzr upgrade on hpss was decent now, though. [17:15] abentley, it works, but still does the actual conversion locally, thus it's very slow [17:20] Given a bazaar branch, and and a branch that is based on that branch, yet lacks any common history...is there any way to "graft" the 2nd branch back onto the first? [17:21] "lacks any common history" meaning: an export of the original branch was placed under revision control and development continued from there. [17:22] sohmestra, both versioned with bazaar, only that the second one wasn't branched from the first one? [17:23] sohmestra: You could perhaps regenerate the second one with the "rebase" plugin. jelmer would know more about that. [17:23] beuno: correct [17:24] sohmestra, what abentley said :) [17:24] abentley: I was fiddling with that...but it complained about having no common ancestery, so I figured that I didn't understand what it was supposed to be doing [17:25] anyway, I'll fiddle some more [17:27] rebase doesn't handle the case where there is no common history yet (bug 231674) [17:27] Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674 [17:28] jelmer: what's maptree? Remapping file-ids? [17:28] abentley, yes [17:29] jelmer: I think a PreviewTree would also work for that. [17:30] abentley: MapTree does exist, it's just not hooked up in the bzr-rebase commands [17:30] bzr-svn's upgrade command makes use of it though [17:30] jelmer: Yeah, I see it. [17:31] abentley: I guess it wouldn't be a bad thing to get rid of it in favor of PreviewTree though [17:31] jelmer: All other things being equal, of course :-) [17:34] jelmer: maptree looks like it reimplements the Tree API. Can you use it as a merge source? [17:35] abentley, yes, that's the idea [17:37] Wow, I'd have thought you needed a bigger implementation to support that. Good stuff. [17:39] hmm, it doesn't appear we're doing that yet so it may not be complete anymore === cprov-lunch is now known as cprov [18:47] hey all... if I made a stacked branch and want to replace it with a normal branch ... what's the best way? [18:49] mtaylor, maybe push --overwrite? I'm not sure if that will work [18:49] you can, alternitavely, delete it and push again, of course [18:49] beuno: but locally... if I branch from it, will I get another stacked branch, or one with everything? [18:50] if you branch from a stacked branch, I don't think it defaults to stacked, you would get the full branch, unless you specify otherwise [19:20] beuno: hmm, that would surprise me [19:25] LarstiQ, me too, but, I've been suprised before :) [19:26] :) [19:29] Howdy, seeking help creating an alias from a script. Looks like bzrlib.builtins.cmd_alias.set_alias, but I've not had success using this [19:29] I don't understand the cmd_xxxx stuff in general, is there doc? [19:30] ktenney: the cmd_ stuff is not really meant to be invoked from other python code [19:30] ah, what is recommended for defining an alias? [19:30] ktenney: cmd_ should use other functions, those would be more fit for bzrlib consumers [19:30] * LarstiQ looks at alias [19:31] ktenney: config.GlobalConfig().set_alias(alias_name, alias_command) it looks like [19:31] ktenney: where config is bzrlib.config [19:32] LarstiQ: thx, I'll try that ... [20:02] LarstiQ: works, thanks, bye. [20:02] ok :) [20:03] jam: did you see that if your bzr branches are in a stackable format they should be stacked on lp:bzr now? [20:03] jam: might save your dsl line some stress :) [20:04] mwhudson_: not entirely, I'd have to upgrade all my branches, which would cause LP to re-mirror everything [20:04] so potentially in the future it will help [20:04] but it wouldn't help for me to go do it right now [20:04] :) [20:05] well, if the branch had been merged into lp:bzr it would be a pretty light mirror... [20:05] so i'm not sure i really see that [20:09] jam: Thanks for all the reviewage [20:09] abentley: I'm happy to try and get our queue unstuck from time to time :) [20:09] your's just happen to be at the bottom of my email and thus easiest to find [20:22] Anyone know off the top of their head what bundle buggy matches against when deciding if someone is a voter or not? [20:23] email address [20:23] or, you log in through the webui [20:23] Just the email address, and not the name part? [20:23] yeap, just the email address [20:23] of course, abentley would know 100% for sure [20:23] beuno: thanks. Just trying to debug why it's not working for me. That helps :) [20:24] but I'm 95% sure :) [20:24] pickscrape: The email address and the name part. [20:25] abentley: ah, so if you have two mail clients that have slightly different names set up (though using the same email address), you have to be registered independently for each name? [20:25] pickscrape: Well, each email-id needs to be associated with your account. [20:26] Ah, you mean in submitter.id? [20:26] phew, good thing I stuck with 95% [20:26] abentley, just curious, why do you check the name as well? [20:27] beuno: mostly because it was the fastest thing at the time. [20:28] abentley, heh, ok, makes sense :) [21:09] lifeless: ping === thumper_laptop is now known as thumper [22:19] abentley: hi [22:20] lifeless: nm. PQM was stuck. Isn't now. === thumper_laptop is now known as thumper [22:20] abentley: did a losa intervene, or did it just come good? [22:20] lifeless: herb intervened. [22:20] k; do we know the cause? === TheMuso_ is now known as TheMuso [23:00] What is the meaning/purpose of the "My Pending" and "Mine" tabs in BB? [23:05]