[00:19] re [00:19] maybe one day, after bzr-gtk gets a pqm, we can add a pqm for bzr-svn as well and make sure it always passes the testsuite... [00:24] yes [00:24] I"m blocked on that as I mentioned :( [00:35] Hi everyone [00:36] I was wanting to get some information about the current status of nested trees [00:41] sminnee: they're partially supported at the moment but still classed as expeirmental [00:41] poolie: it seems as though it's been that way for nearly 2 years? [00:41] do you know what kind of risks there are in using it that make them experimental [00:42] I'm currently on svn and svn:externals are an absolutely critical feature for me. [00:42] abentley could probably give you a more accurate answer [00:42] i think not all merges work across them correctly [00:43] ok, bbiab [00:43] poolie: but if you were keeping your merges restricted to happening within a single subtree, you would be okay? [00:44] for example, i have "projects" and use svn:externals to link the applicable modules into each project [00:44] so if I was branching and merging solely within the context of individual modules, i would be okay? [00:45] i think that would work [00:46] possibly we should just promote this to properly supported and deal with anything else that crops up [01:18] poolie: i would vote for that approach :) it's a very useful feature and has been in-development for some time. [01:18] I might have a play with them and complain when they start breaking, then :P [01:18] that'd be good :) [01:18] spiv, do you want to talk about the unlock exception handling? [01:19] poolie: ok [01:19] here, or on the phone? [01:20] Here's fine, I think. [01:21] I'm still pretty uncomfortable about the suggestion to suppress exceptions during unlock. [01:22] btw i did your tweak regarding the default argument - in fact i removed it [01:22] so i'm not sure if it's simpler and cleaner, or just too careless [01:22] It feels like it moves the complexity of handling unexpected conditions from a single, obvious place (the callsite) to a much broader and harder to determine scope. [01:22] however, unless we can really think of a case where it makes a difference, i think we should do it [01:23] hm [01:23] that's one way to look at it [01:23] So concretely, doing what I propose is clearly correct, and we know how it will behave. [01:23] but another way is doing this just changes the particular cleanup functions, rather than adding something to every caller [01:23] And hiding exceptions from unlock isn't clearly correct, at least not to me :) [01:24] I have another question if you're not sick of noobs: bzr svn-import for an HTTP svn repository doesn't seem to like 401 responses. Does it support authenticated svn repositories over HTTP? [01:24] i thought it did [01:24] if jelmer is still here you could ask him [01:24] yep, I am [01:24] spiv, so i'd cast it as [01:24] sminnee, What's the error you're getting [01:25] jelmer: bzr: ERROR: Invalid http response for http://svn.silverstripe.com/.bzr/branch-format: Unable to handle http code 401: Authorization Required [01:25] clarifying the behaviour of unlock to say "if the transport is closed, unlock will not raise an error" [01:25] ooh I see - it seems to think it's a bzr repos [01:25] So, here's another reason to do it my way: when we shift to requiring Python 2.5, I think we'll want to do it with a "with" statement anyway. [01:25] I executed ~/bzr/test: bzr svn-import http://svn.silverstripe.com/ repos [01:25] sminnee, bzr doesn't support http auth, bug 256612 [01:25] Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612 [01:25] sminnee, you can work around it by using svn+http://svn.silverstripe.com/ [01:26] jelmer: thanks. Now I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("REPORT request failed on '/!svn/bc/64032'", 175002) " which sounds more like an issue with my repos. [01:26] I could use svn: or svn+ssh: however I get a different error ;) bzr: ERROR: exceptions.UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data [01:27] sminnee, are you using bzr-svn 0.4.13 ? [01:27] poolie: Hmm. I'm not sure that just suppressing/avoiding errors due to the transport being closed will actually fix these bugs. [01:27] jelmer: yeah, looks like it. I just downloaded and installed bzr 1.7.1 [01:28] poolie: the underlying exception in at least one of these cases is some form of "revision X not present", i.e. a logic bug in bzr, rather than an environmental problem. [01:29] sminnee, please file a bug [01:29] jelmer: sure thing. [01:29] and then the knock-on effect is that there's already a request pending, or that there's a write group open? [01:30] Right. [01:30] spiv, so the difference in behaviour between these options (as opposed to in the code) [01:30] is just in the case where the unlock fails but there was no earlier failure, right? [01:31] Hmm. I think so. [01:32] So there are four cases, (operation ok, unlock ok), (operation fails, unlock ok), (operation ok, unlock fails), and (operation fails, unlock fails). [01:33] right [01:33] (Which co-incidentally is why there are four test methods for my proposed helper :) [01:33] in the current trunk code, we get case 4 wrong by showing the unlock exception when we want to show the original exception [01:33] We seem to be disagreeing about the (ok, fails) case. [01:33] mm [01:34] i should say i'll be glad to have this fixed whatever solution we decide on [01:34] In (ok, fails) I think I'd rather get the exception immediately. [01:34] hmm, did the API of record_entry_contents() change? [01:35] yes [01:35] * ``CommitBuilder.record_entry_contents`` returns one more element in [01:35] its result tuple - an optional file system hash for the hash cache [01:35] to use. (Robert Collins) [01:36] if i'd reviewed it i might have asked for a new name for the new protocol.... [01:36] jelmer: here you go: https://bugs.launchpad.net/bzr/+bug/281035 there were similar looking bugs reported with the 'ascii' codec but i didn't see a UTF8 one. [01:36] Launchpad bug 281035 in bzr "unicode error on import-svn call." [Undecided,New] [01:36] spiv, so you said in the patch for http://bundlebuggy.aaronbentley.com/project/bzr/request/<20081008054310.GC19754%40steerpike.home.puzzling.org> [01:36] s/patch/letter [01:36] that you can't distinguish those cases from inside the unlock, which is correct as far as i know [01:36] Right. [01:37] i kind of dislike needing to push the contents of these blocks into separate functions just to wrap them this way [01:37] So the advantage of your idea is that unlock doesn't need to distinguish. [01:37] yes, it is [01:38] would anyone care? [01:38] Yeah. I don't much like it either, but I don't think it is actually *bad*, just mildly irritating. [01:38] And in the case of functions like commit, it was probably large enough that it should be broken up somewhat anyway ;) [01:38] with your patch the failure from unlock is totally lost [01:39] Well, we can make that emit a warning. [01:39] (though that is somewhat of a quibble because obviously we could both log it and re-raise) [01:39] right [01:39] I should have mentioned that idea in the patch (similarly we could do that in needs_write_lock) [01:40] So this requires a time machine, but how soon might we require Python 2.5? [01:40] If hypothetically it were tomorrow, then the decision I think would be easy: just start using with blocks. [01:41] sure [01:41] i don't think we should hold our breath [01:41] by making decisions in the hope of switching soon [01:41] because as was pointed out there, some distros are very slow [01:42] Is there are "bzr-noobs" channel I can ask user questions on? I don't want to hassle everyone here with my stupidity [01:42] hello jon! [01:42] you're welcome here [01:42] hey poolie! [01:42] jonoxer: this is it. I just hope noobs don't feel hassled by developers debating patches :) [01:42] spiv, so what would your __exit__ clause do if it hit an exception in unlocking? [01:43] allow it up, but only if there was no previous exception? [01:43] file:///usr/share/doc/python2.5/html/lib/typecontextmanager.html (assuming you have python2.5-doc installed) [01:44] If __exit__ blocks don't return a true value, then they propagate an error from within the block. [01:44] Er, s/__exit__ blocks/__exit__ functions/ [01:45] yes, i see [01:45] so you'd have something like this? [01:45] try: unlock() except e: if orig_exc_type: return False; else: raise [01:46] Well, just simply "try: unlock(); finally: return False" would be fine. [01:46] At least, AIUI. I haven't tried it out yet :) [01:46] really? [01:47] surely that will always hide the unlock execption? [01:47] in other words (ok, fail) -> ok [01:47] The __exit__ function receives the live exception as arguments (or three Nones if there is no exception from within the block). [01:47] Hmm, that's true. [01:47] So, your way is right :) [01:47] lol [01:48] Good thing I'd write tests... ;) [01:49] so, we're all set? ;-) [01:49] If we were using 2.5, sure :) [01:50] so basically, i don't want to put extra work on the callers unless we actually care about seeing exceptions from unlock [01:50] i'm not sure that we do [01:50] Any exceptions at all? [01:51] aside from systemerror [01:51] Also, it just occurred to me, it's harder to write a test for a negative. i.e. how do you write a per-branch test that "br.unlock() never raises"? [01:52] well, you can't, any more than you can write a test for 'foo always does the right thing' [01:52] however, you can test appropriate representative cases [01:55] so... [01:56] in practice i think we'd have a version that does raise exceptions, and we could test that [01:56] Suppressing errors still makes me nervous. How about this: unlock tries not to raise, but if it catches a non-internal error, warns the user [01:56] right [01:56] (And if it catches an internal error, maybe .bzr.log it) [01:56] or even warn in either case [01:56] At least that way if it goes wrong, we'll know why :) [01:57] i guess i just feel like doing otherwise is getting too twisted up about an error for which we can't do anything [01:57] there is another drawback though, which is that often people will get these warnings in addition to another error [01:57] Well, I don't think "Connection lost\nWarning: TooManyConcurrentRequests" is helpful for a user. [01:57] but that's probably reasonable, because it will tell them that the thing was not locked [01:57] no, but if it was [01:58] "Connection lost\nCould not unlock <.........>: smart medium already in use" [01:58] maybe that's more plausible [01:58] But then I find myself thinking "but if it's internal, and there isn't another exception, the user should know about it", i.e. I keep wanting it my way :) [01:58] Maybe I can break that habit ;) [01:59] should know about it in a stronger way than getting a warning? [01:59] A "Could not unlock: $reason" message seems ok, although it's still a bit poor UI-wise to spray internal details to the user. [02:00] Right, that's where my mind was taking me before I realised we'd been down that path already ;) [02:01] so, we can choose to show more or less details as appropriate [02:02] Ideally we'd tell the user "Could not unlock: connection was lost", I think. [02:02] i guess the main difference is that in the (fail, fail) case, your approach would show just the original message, and mine would show both [02:02] actually no, because i think we agreed earlier that it should log the exception too [02:02] Right. [02:02] and i think it is desirable not to ever hide them completely [02:03] so it's just a matter of making them reasonably presentable [02:03] The only significant difference is in the (ok, fail) case. Exception vs. warn-without-interrupting. [02:03] right [02:04] can you think of any particular case that would make it more clear which is better? [02:04] We almost always are just about to finish after an unlock, so the difference is usually minimal. [02:04] I wonder if GUIs have a different requirement? [02:05] i'm not sure [02:05] i think actually they're going to converge on the same behaviour: if an exception occurs during a bzrlib call, log it, but don't stop [02:05] Would LockBroken still be raised if the lock was broken from under us? [02:06] * spiv thinks about what bazaar.launchpad.net needs [02:08] bzr processes that take up a third as much memory :) [02:08] spiv, LockBroken is a good question but it makes me think that actually the higher-level code should be validating the lock earlier [02:08] eg before switching the names file [02:08] OK, time for my noob question. Scenario: migrating a team of devs from SVN to BZR. We have several existing SVN repos of varying sizes. I'm doing trials with a small repo while I figure this out. bzr-svn is installed. For simplicity we'll probably move to a central repo model on bzr so the workflow stays almost the same [02:09] I don't think that's right. [02:09] an exception indicating something bad happened in the paste is not much better than a warning... [02:09] jonoxer: ok [02:09] For SFTP, that would involve lots of round trips. I think it's reasonable to be optimistic that evil hasn't happened. [02:09] So far I've tried a couple of different things to see what happens... [02:10] (this is kind of a digression but surely it would just take one round trip, to read the lock info file?) [02:10] anyhow, yes, i think it's reasonable to be optimistic [02:10] launchpad is an interesting case too [02:10] It does, but you're proposing doing it several times, rather than just once when releasing the lock? [02:10] as is the smart server; what should it do if unlocking fails [02:11] am i? [02:11] Well, I don't know what you mean by "should be validating the lock earlier eg before switching the names files" then. [02:11] i guess my point was, if we want to avoid evil, it's better to check for it at the point where it'll actually help us avoid it [02:12] i was assuming that we rename the names file just once, at the end of the write group [02:12] Because at the moment over vfs transports we do do that one round trip at lock release time already, but it sounds like you're saying we should be doing something else? [02:14] If someone breaks a lock from under an active client, there's not much we can do to stop bad things happening. We can at least notice that it happened and let the user know, and that's what we're doing atm. I'm not sure there's real benefit to doing anything more, but then I'm unclear on what you're suggesting :) [02:14] i think the current behaviour is fine [02:15] 1. Branching off an SVN repo (using "bzr branch file:///home/subversion/repositories/test testbzr"), which gives me a local working copy. That seems fine [02:15] But what I need to do is create a shared repo, so... [02:16] spiv, i'm saying that if the point of it is to say "something bad happened in the past" then a warning may be enough [02:16] Ok. [02:16] on the other hand if we're trying to actively detect the lock being stolen and change the client's behaviour to cope, then it'd have to be checking it earlier than unlock time - but this is probably in vain, because it could be stolen at any time [02:17] Right. [02:17] jml, btw are you coming here for lunch? [02:18] 2. My reading (maybe wrong) of the guide at http://bazaar-vcs.org/SharedRepositoryTutorial is that I need to init a repo, then branch into it, so I tried this: [02:18] jonoxer: "bzr init-repo --rich-root-pack testrepo", then use "testrepo/testbzr" rather than "testbzr" as the destination. [02:18] poolie: sure. was just waiting for your reply on #canonical :P === Spazpaimon is now known as Spaz [02:19] jonoxer: the --rich-root-pack is necessary because bzr-svn requires a non-default format. [02:19] spiv: aha, thanks, trying that now [02:21] aha, seems to be good so far, thanks spiv! I'd tried "--dirstate-with-subtree" and "--subversion" (which I'd come across in some docs) but not --rich-root-pack [02:21] poolie: I think I'm ok with making unlock try not to raise. [02:21] spiv, anyhow, that's what i think, let's not spin on it [02:21] poolie: but... [02:21] poolie: what about fixing this bug for 1.8? :) [02:22] hm [02:22] so 1.8rc1 is already out, 1.8final is meant to be monday [02:22] do you think this should be merged across? [02:22] I think we should merge the initial patch I proposed as-is for 1.8. [02:22] which bug exactly? [02:23] https://bugs.edge.launchpad.net/bzr/+bug/230902 [02:23] 230902 [02:23] Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] [02:23] OK, so now I need to make a branch from the repo, but a simple "branch" command fails ("ERROR: Not a branch...") [02:23] jonoxer: you branch branches, not repos. [02:23] ok, so this is more than just cosmetic [02:23] spiv, that's ok with me for 1.8 [02:23] Right. It'll still fail, but at least we'll know the real reason why :) [02:23] poolie: thanks [02:24] spiv: cool, so what is the equivalent to SVN's "checkout"? That seems synonymous with "branch" in bzr parlance [02:24] jonoxer: you also checkout branches (not repos). Let's see if I can find a good glossary for our terminology... [02:25] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts [02:25] spiv, poolie: did you see the bug I filed yesterday about unlocking? [02:26] jml: that rings a bell, but man, that was a whole day ago! [02:26] spiv: thanks, I think I'm getting closer now. I appreciate the assistance [02:26] * jml pokes around for a link [02:26] https://bugs.edge.launchpad.net/bzr/+bug/280608 [02:26] Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New] [02:27] jonoxer: so if you've created a repository "repo", and have branches inside that repo, e.g. "repo/branch1", "repo/branch2", then you can do "bzr branch repo/branch1 DESTINATION". You can't do "bzr branch repo DESTINATION" because there's no branch at "repo". [02:28] jonoxer: I'm guessing that's the confusion that caused your "Not a branch" error. [02:29] jml: that patch looks highly plausible to me. [02:30] spiv: it's courtesy of lifeless. [02:30] Yeah, I saw. [02:30] oh good. [02:31] I mean, not only does it come from lifeless, it also makes a self-evidently plausible improvement :) [02:31] spiv: heh [02:31] so, I'm not going to get around to turning it into a real patch. [02:32] but it seems related to the discussion you were having earlier. [02:32] speaking of bugs! [02:32] speaking of launchpad deleting leading whitespace sucking [02:33] https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595 [02:33] Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [Undecided,New] [02:33] isn't that particularly ironic for a project written in python? :) [02:33] poolie: heh, I guess so :) [02:33] so that patch does look plausible, and i think it is relevant too [02:34] if unlock did not default to raising exceptions, it would tend to be safer when we need to unlock several things [02:42] poolie: in fact, the leading whitespace is intact, it's the non-leading whitespace that it's collapsed. [02:42] Thus screwing over exactly the most interesting parts of a diff. [02:42] trailing the + [02:42] that's true [02:47] spiv: that explanation made a bunch of things click in my head. Looking good so far [02:47] I now have a repo and a working copy that's branched from a branch in the repo :-) [02:48] bug 281051 [02:48] Launchpad bug 281051 in malone "non-leading whitespace should be preserved" [Undecided,New] https://launchpad.net/bugs/281051 [03:02] spiv: I'm nearly there, problem now is I can't push commits from my local branch back to the repo, so I think I must have stuffed that up somehow [03:02] I get the "This transport does not update the working tree of..." warning [03:03] But I thought it was a repo, not a working tree? [03:04] jonoxer: you can have a repo, a branch, and a working tree co-located in the one directory. [03:04] (or a subset of those) [03:05] Cool, so I'm pretty sure what I have at that end is just a repo, nothing else, hence the "update working tree" warning [03:05] poolie: bug #60730 is a bit more colorful about it [03:05] So what is the procedure for getting my locally committed changes back to the repo? [03:05] Launchpad bug 60730 in malone "Malone breaks patches by messing with whitespace (dup-of: 2627)" [Undecided,New] https://launchpad.net/bugs/60730 [03:05] Launchpad bug 2627 in launchpad-foundations "Bug comment and description whitespacing being munched yet again" [Medium,Confirmed] https://launchpad.net/bugs/2627 [03:06] hee hee [03:06] poolie: also, what about getting accounts on the win32 host [03:06] jonoxer: I would guess you have more :) but you can run "bzr remove-tree" on the remote end [03:06] jonoxer: you get that warning if the branch you're pushing to does have a working tree, and you're pushing over the network. If you don't want a working-tree there, run "bzr remove-tree" on the remote side. [03:07] yeah i thought it must have been reported already [03:07] jam, i'll send you a password soon [03:07] poolie: I reported one of my own a while back, which was already marked "dupe" [03:07] i was trying to work out ssh [03:07] as you can see, 2627 means it has been around for a *long* time [03:08] i won't go into details but for now you need to use rdesktop [03:09] poolie: well, I spend 50% of the time on Vista, which has "Remote Desktop" or whatever, so I think I'm okay there [03:09] also 'apt-get install rdesktop' [03:09] spiv: at the other end it shows a directory called "trunk" (which was what I specified as the destination when I grabbed the data from the svn repo) which is odd, because I thought bzr repos kept everything in the '.bzr' dir. But when I do "bzr remove-tree" I get "bzr: ERROR: No working tree to remove" [03:09] jam, sent [03:09] jonoxer: "trunk" is a branch [03:09] branches also have locations on disk [03:09] not like svn [03:10] you need to do "bzr remove-tree trunk" or "cd trunk; bzr remove-tree" [03:11] jam: groovy, that didn't complain (left the trunk dir there, which I assume is normal), now to test if I can push to the repo [03:12] jonoxer: right, that's normal. [03:13] jonoxer: it's probably better to think of it as "pushing to the branch" rather than to the repo. Having a repo shared between multiple branches is essentially just an optimisation detail that doesn't affect behaviour. [03:13] Woot! We have success, local changes pushed OK, then pulled down to a branch in another location. Thanks spiv and jam! [03:13] jonoxer: you're welcome [03:13] spiv: yes, I think a lot of my problem is getting myself out of the SVN mindset [03:14] I read bzr tutorials and I *think* I get it, then realise I've totally misunderstood the intent behind it because I'm seeing things through SVN-colored glasses [03:15] Yeah, it's surprisingly hard to avoid making those sorts of assumptions. [03:24] poolie: what is the username supposed to be? [03:39] is there cruisecontrol functionality available for bzr? [03:39] (or the other way round) [03:40] there's PQM, which might be a little bit the same [03:40] (i don't know much about cruisecontrol) [03:50] Speaking of PQM, is there a good howto on it somewhere? My google-foo is weak and I can't find one so far, and https://launchpad.net/bzr-pqm doesn't have much on it [03:52] jonoxer: that's question-of-the-day around here. [03:52] Hey AfC! Good to see you [03:53] jonoxer: heya mate :) [03:53] jonoxer: ['fraid I can't help you. We don't use PQM] [03:55] im unable to break the lock i used "bzr break-lock" i also used "bzr break-lock lp-29094736:///~gnomefreak/iceowl/iceowl-0.x/.bzr/repository/lock" [03:56] jonoxer: I don't think your google-fu is particularly weak; I just think PQM's documentation is particularly weak :) [03:57] here is the output of the above commands http://pastebin.mozilla.org/551713 [03:57] RAOF: I've grabbed the package and looking through the code now to figure out what it does, but the package itself is remarkably documentation-free [03:58] gnomefreak: "bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x" should work [03:59] If it does, it's probably worth filing a bug that the URL that error suggests you use is stupid and wrong. [04:00] lp-29094736 ??? [04:01] RAOF: thanks that worked. im not6 getting why its given me a lp-#### [04:02] will file bug as soon as i get done with everything that i started [04:06] file it under package bzr? [04:08] Yeah, that's probably the best place. [04:08] At least to start. [04:09] ok thanks [04:18] gnomefreak: there is already a bug that the suggested url is stupid and wrong [04:18] https://bugs.edge.launchpad.net/bzr/+bug/250451 [04:18] Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed] [04:24] mwhudson: thanks i was reading that [04:36] sminnee: if you're still around, apparently there is another branch that's better for using nested branches [04:36] and that is [04:36] https://code.edge.launchpad.net/~larstiq/bzr/nested-trees [04:37] thanks poolie [04:37] out of interest, how have you found launchpad? [04:38] i just type in 'launchpad.net' and there it is :-) badabing [04:38] *groan* [04:39] actually i think it's quite nice in many ways, though i've also got about 200 bugs i'd like fixed [04:45] is there a different way to push to branches outside of bzr push lp:~gnomefreak/iceowl/iceowl-0.x [04:45] gnomefreak: which part do you want to do differently? [04:45] poolie: the whole command [04:46] poolie: this is a total noob question, but how do I download and install that version of bzr? :) [04:46] that command is hanging [04:46] Well, you could add an alias so you could "bzr gently-suggest" instead... [04:46] gnomefreak: did it say it's waiting for a lock or anything? [04:46] no [04:47] sminnee: there should be a 'bzr branch' command on that page; run it, and then follow the INSTALL instructions in the resulting directory [04:47] give me a minute [04:47] poolie: http://pastebin.mozilla.org/551726 that is all and its benn running close to 30 minutes [04:47] gnomefreak: ah that would be why it's so slow [04:48] iceowl == unbranded thunderbird? [04:48] mwhudson: sunbird [04:48] try running 'bzr upgrade sftp://gnomefreak@bazaar.launchpad.net/%7Egnomefreak/iceowl/iceowl-0.x' [04:48] oh ok [04:48] that's not likely to be so big i guess [04:48] or ask mwhudson to fix it on the server [04:48] mwhudson, jml, we should seriously do something about this ^^ [04:49] poolie: do some kind of mass upgrade to packs? [04:49] i think so [04:49] my kneejerk reaction says "no" [04:49] but i'm willing to be influenced [04:49] poolie: so, we'd very much like to allow users to ask us to do a server-side upgrade. [04:49] iceowl branch is big but never taken this long before. im waiting for lock to break [04:50] what we really do want to do is have a button that says "upgrade this branch" [04:50] right [04:50] poolie: we've got a plan for this, but it's pending some db discussions [04:50] :/ [04:50] I even filed a bug that proposed exactly that, so you can get your fill of bugfixing karma at the same time! [04:51] poolie: what does this command do outside of bzr upgrade (already had done this [04:51] )* [04:52] which command? [04:52] bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x [04:52] rocky: if i wanted karma, i'd actually _use_ blueprints [04:52] it breaks the lock held by the previous process [04:52] RAOF: ^^ [04:52] you should kill the process on your laptop if it's not already [04:52] i had screwed up my branch thats why i was trying to overwrite it [04:53] mwhudson: :P [04:53] mwhudson/jml, is there any chance we could do these one-by-one on request? [04:53] gnomefreak: then it's probably easier to just delete the branch, [04:53] upgrade your local copy, and then push [04:53] that'll actually be faster [04:53] ok try that [04:53] switch machines, biab [04:53] poolie: sure, i can run "bzr upgade lp:whatever" on devpad [05:03] there really is something wrong and im getting tired [05:03] even got trace back [05:03] poolie: traceback [05:04] that's no good [05:04] im gonna run outside for smoke here is the output http://pastebin.mozilla.org/551729 [05:05] gnomefreak: you need to run "bzr launchpad-login gnomefreak" first [05:06] spiv, would that really give a timeout? [05:06] Oh, hmm. [05:06] In that case, don't know :) [05:06] it looks to me like a transient timeotu [05:07] Hmm, that's probably the first network request that "bzr push lp:..." does. [05:09] It *might* be an issue with connecting to the HTTPS port? [05:10] Actually, why does the launchpad plugin need to connect to Launchpad to resolve "lp:~x/y/z"? [05:11] should i try after login? [05:12] spiv, I think to check for permissions [05:12] starting off same way [05:12] ah it did work [05:12] well ill check when its done [05:13] i'd just retry it and see if it gets the same thing, i think it's transient [05:13] im getting the progress bar [05:15] beuno: hmm, surely the way to do that is to just try using it? :) [05:17] spiv, I'm sure there's a reason somewhere. Also, it's a wild guess based off things I read on IRC, so take with a grain of salt [05:17] and, it's 1am [05:17] beuno: go to sleep :) [05:17] you're a wise man [05:17] good night spiv [05:17] have a nice weekend! [05:19] spiv: because the client makes very few assumptions about the structure of urls [05:19] which is a good thing i guess *cough*source package branches* cough [05:19] is there a way to login automagickly? [05:22] gnomefreak: you only need to run "bzr launchpad-login" once, then the userid is saved in your ~/.bazaar config. [05:22]