| ScottK | poolie: I didn't know about bzr remove-branch when I filed the bug. Apparently lifeless didn't either as he didn't suggest it ... | 00:00 |
|---|---|---|
| ScottK | So if that had worked, I'd have been happy. | 00:01 |
| ScottK | It may just be that bzr on alioth is too old (2.1.5.) | 00:02 |
| ScottK | poolie: Does that clarify it? | 00:02 |
| poolie | yep | 00:04 |
| poolie | actually i answered, and i had forgotten it was now built in | 00:04 |
| poolie | maybe robert did too | 00:04 |
| poolie | given all this i think it's not an upstream bug | 00:04 |
| poolie | do you agree? | 00:06 |
| poolie | it's probably not something we would put back into the 2.1 series | 00:06 |
| ScottK | I agree it shouldn't be backported. | 01:23 |
| lifeless | poolie: hi, https://bugs.launchpad.net/launchpad/+bug/717094 - may benefit from a bzr person eyeballing it | 01:31 |
| ubot5 | Ubuntu bug 717094 in Launchpad itself "InvalidURL OOPS in translatePath because of URL containing non-ascii chars, again" [Critical,Triaged] | 01:31 |
| poolie | hi lifeless | 01:31 |
| lifeless | poolie: hi :) | 01:32 |
| mgz | that bug description sounds like it's my kind of thing. | 01:33 |
| lifeless | mgz: its in the lp bzr codehosting stack | 01:33 |
| mwhudson | oh what, i thought i fixed all of them | 01:34 |
| lifeless | tada | 01:34 |
| mwhudson | oh | 01:35 |
| * mwhudson preemptively hates mod_rewrite a bit | 01:37 | |
| poolie | i'm happy to hand it to either of you | 01:37 |
| mgz | ...maybe I'll get a copy of launchpad in may, I've never succeeded in branching it. | 01:39 |
| mwhudson | poolie: i think you can keep it :) | 01:41 |
| mgz | the bzrlib side seems too strict for urls that might just get entered by hand, I don't see a mod_rewrite fix unless you do something like surrogate-escape does. | 01:41 |
| jam | mwhudson, lifeless: sorry I didn't make it back before. Fell asleep while putting my son to sleep. | 01:42 |
| jam | Note that the fix for loggerhead (mentioned elsewhere) should probably be using urllib.quote(path.encode('utf-8')) | 01:42 |
| mwhudson | poolie: strange that clicking download on the file with chinese characters on http://bazaar.launchpad.net/~czhedu/+junk/hi_baidu_com_xxai/files works though | 01:42 |
| jam | rather than cgi.escape() | 01:42 |
| jam | since it is URL stuff, rather than HTML content stuff. | 01:42 |
| jam | and I wonder if this isn't something similar | 01:42 |
| jam | where we are generating a url and escaping it via the wrong transformation | 01:43 |
| lifeless | jam: mwhudson: ECHANNEL | 01:43 |
| poolie | go to bed jam! :) | 02:06 |
| jam | poolie: well, I slept a little bit already | 02:08 |
| mr-russ | spiv: are you online? | 06:51 |
| spiv | mr-russ: I am | 06:52 |
| mr-russ | cool. I'm the bzr as single user doc patch guy. | 06:53 |
| spiv | I just figured that out :) | 06:53 |
| spiv | Did my review make sense? | 06:53 |
| mr-russ | The reason I wrote the doc is I was one of the users you mention and I couldn't find how to do it. | 06:53 |
| mr-russ | Your review makes sense. However my bzr doc skillz are basically zero. | 06:54 |
| spiv | Apparently better than that! | 06:54 |
| mr-russ | I get the idea, but I don't know how to build the docs, or view the tags. | 06:54 |
| mr-russ | and the :: type stuff, I don't know where I might find out more about that. | 06:54 |
| mr-russ | So I'm happy to give it a try, but I feel like I might need a bit of formatting help. | 06:54 |
| spiv | 'make docs-sphinx' | 06:55 |
| spiv | That should build the docs, you probably need to install some dependencies to have that work | 06:55 |
| mr-russ | package hunting now. | 06:55 |
| poolie | thanks for adding that mr-russ | 06:56 |
| spiv | The format is called restructured text | 06:56 |
| mr-russ | It's probably the biggest barrier to switching from svn. How to do an svn type setup easily on bzr. | 06:56 |
| mr-russ | I tried apache route but too hard, danger. But it was documented mostly :) | 06:57 |
| spiv | http://sphinx.pocoo.org/rest.html is a good intro, and http://sphinx.pocoo.org/contents.html in general for the overall documentation tool we're using (sphinx) | 06:58 |
| mr-russ | my question/concern about the bzr_ssh_path_limiter is that it's not installed by default. So it's more work to make it all go. | 06:59 |
| mr-russ | I don't even know how to install it under ubuntu. | 06:59 |
| spiv | mr-russ: fwiw, the only svn repo I interact with regularly is via a regular ssh account with a real user and home dir etc :) | 06:59 |
| spiv | Yeah, that's a good point. | 06:59 |
| spiv | I guess the obvious question is where should it be installed? I suppose /usr/bin would be reasonable | 06:59 |
| spiv | (for the Ubuntu package at least) | 07:00 |
| mr-russ | /usr/bin is obvious. lots of debian packages just put contrib in a /usr/share/bzr/contrib type area. | 07:00 |
| spiv | But you could install it anywhere, really | 07:00 |
| spiv | And just adjust the command="..." config to give the full path to it | 07:00 |
| mr-russ | But for this kind of documentation, having it easy for a new user is key from my perspective. | 07:01 |
| mr-russ | so if it gets installed by default for 2.4.x, then we can change the command. | 07:01 |
| spiv | /usr/share/doc/bzr/contrib would be better than nothing, but not great. | 07:01 |
| spiv | I'm happy to avoid mentioning bzr_ssh_path_limiter for now until it genuinely becomes easy | 07:02 |
| spiv | (i.e. have it installed somewhere by default) | 07:02 |
| spiv | You should definitely fix the missing --inet though :) | 07:02 |
| mr-russ | yeah, waiting for doc build to finish. | 07:03 |
| mr-russ | My 5 year old laptop is okay, not brilliant. | 07:04 |
| mr-russ | how can I improve my markup knowledge? | 07:04 |
| mr-russ | :: is an example, is there a reference file, or anything else basic to know. | 07:04 |
| mr-russ | spiv: thanks for the review though. Very helpful. As you can see I'd like to get this completed :) | 07:05 |
| spiv | The links to sphinx.pocoo.org I gave above are probably the best source for docs about the doc system | 07:05 |
| spiv | Heh, although their ReST primer doesn't mention :: | 07:06 |
| spiv | http://docutils.sourceforge.net/docs/user/rst/cheatsheet.txt, http://docutils.sourceforge.net/docs/user/rst/quickstart.html | 07:07 |
| spiv | Specifically for preformatted text with :: -> http://docutils.sourceforge.net/docs/user/rst/quickstart.html#preformatting-code-samples | 07:07 |
| spiv | Ok, I'm off for a little bit | 07:08 |
| poolie | cheerio spiv, see you in a bit | 07:10 |
| vila | hi all ! | 07:37 |
| mr-russ | my bzr newbieness has got me again. | 07:39 |
| mr-russ | I bzr pulled from the bzr branch. | 07:39 |
| mr-russ | It says I've diverged and need to merge. I ran bzr merge and there are all these files for me to commit. | 07:39 |
| mr-russ | Should I commit them, but what message do I put? is there a default merged commit message? | 07:40 |
| spiv | mr-russ: "Merge trunk." or similar | 07:42 |
| spiv | A commit message is generally used to describe what you did, and that's what you did :) | 07:43 |
| mr-russ | thanks. | 07:43 |
| mr-russ | my first use of shelving my changes, merge and unshelve. | 07:43 |
| poolie | spiv, jam, vila, want to chat in a couple of minutes? | 07:43 |
| vila | sure | 07:43 |
| jam | poolie: sure | 07:43 |
| spiv | Yes, let's :) | 07:43 |
| vila | here or mumble ? | 07:44 |
| poolie | let's mumble? | 07:44 |
| jam | I'm on mumble with spiv | 07:45 |
| vila | <shudder> | 07:47 |
| jam | vila: same problems today? | 07:47 |
| jam | vila: can you hear us at least? | 07:47 |
| vila | yup | 07:47 |
| mr-russ | okay, my next attempt is up, I'll leave it for you all to review. | 07:48 |
| spiv | mr-russ: thanks! | 07:48 |
| jam | jelmer: if you're up, we're on mumble | 07:48 |
| jam | spiv: your' mic is locking "on" with background noise | 07:48 |
| poolie | spiv? | 07:53 |
| spiv | poolie: X crashed and apparently took my whole system with it | 07:56 |
| poolie | wow | 07:56 |
| poolie | insert xkcd joke about '2003 called' | 07:56 |
| jam | poolie: did you warn them? | 07:57 |
| spiv | (I'm back) | 07:57 |
| xarinatan | May i ask a silly simple question? How do i set the remote username in the windows bzr interface? It keeps using my workstation's username, like so http://j.mp/enNaNX | 08:12 |
| jam | xarinatan: you can do it in the URL, "http://myuser@host/" | 08:13 |
| xarinatan | Ah, thanks, i vaguely heard of that before, but i did user@bzr+ssh://hostname instead ^^; thanks again | 08:16 |
| jam | anyone care to second review: https://code.launchpad.net/~mgiuca/bzr/test-log-show-ids/+merge/54199 | 08:35 |
| ubot5 | Ubuntu bug 54199 in zsnes (Ubuntu) "zsnes segfault on startup" [Medium,Fix released] | 08:35 |
| jam | I'm actually going to be afk for a while, taking my son to the doctor. | 08:35 |
| jelmer | jam: I'll have a look | 08:40 |
| xarinatan | is it normal that bzr stays a while in the background after committing, seeming to do a lot of processing? | 08:47 |
| xarinatan | http://j.mp/h4CpWR (taskmanager screenshot) | 08:48 |
| jelmer | xarinatan: "bzr commit" (the command) should exit right after it's finished | 08:49 |
| jelmer | perhaps something else has started it in this case though (e.g. tortoisebzr?) | 08:49 |
| === hunger_ is now known as hunger | ||
| xarinatan | jelmer: I used tortoisebzr to commit data to my server, but after that finished and the window closed, that process stayed for a while, 2 processes at first, now they're both gone, just wondering if it's normal | 08:50 |
| xarinatan | I gotta say though, i just switched from SVN to BZR and i like it a lot better, SVN simply wasn't usable for my needs (versioned backup for my project/school data sticks) and bloated my data a lot, especially clientside made that unusable for me | 08:53 |
| bob2 | to be fair, most things are better than svn :) | 08:56 |
| xarinatan | Heh, true i suppose, but SVN is sort of the 'standard' these days. Kind of like how IPv4 is still the standard for internet communication :P | 08:57 |
| xarinatan | But that could be me | 08:57 |
| jelmer | xarinatan: I suspect it's got something to do with how tortoisebzr works, but I'm not sure. | 09:19 |
| jam | anyone care to give a second review to: https://code.launchpad.net/~mgiuca/bzr/log-not-in-branch/+merge/53955 | 11:29 |
| ubot5 | Ubuntu bug 53955 in Ubuntu "System time wrong" [Undecided,Invalid] | 11:29 |
| Peng | Nice, ubot5. | 11:30 |
| jelmer | jam: I'm on it | 11:53 |
| jam | jelmer: thanks | 11:53 |
| jam | thanks for the earlier one, too | 11:58 |
| jelmer | jam: least I could do after all the reviews two weeks ago :) | 11:58 |
| jelmer | jam: Did you see the bug I filed about get_revisions / revision_trees / get_deltas ? | 11:58 |
| jam | jelmer: sounds hazy | 11:58 |
| jelmer | jam: Basically, "bzr log" uses those methods underneath but if one of the specified revids is a ghost the entire method will fail. | 11:59 |
| jelmer | the simple solution is to use the singular fetch functions so when we get a NoSuchRevision exception we know which revision is missing | 12:00 |
| jelmer | but that obviously has performance consequences | 12:00 |
| jam | jelmer: can we do X and then fall back to Y if there is a problem? | 12:00 |
| jam | or not easily? | 12:00 |
| jam | it shouldn't have the same implications it used to | 12:00 |
| jam | we used to be spending all our times deserializing the inventories | 12:00 |
| jam | which should be much better now | 12:00 |
| jam | jelmer: you're the one packaging meliae, right? | 12:03 |
| jelmer | jam: We can't fall back easily as far as I can tell | 12:03 |
| jam | have you seen bug #735284 | 12:03 |
| ubot5 | Launchpad bug 735284 in Meliae "Installs from source distributions fail" [Undecided,New] https://launchpad.net/bugs/735284 | 12:03 |
| jam | i'm just trying to understand who is running 'sdist' and why | 12:03 |
| jam | rather than, say, running 'setup.py install' | 12:03 |
| jam | I know *I* build the tarball using "bzr export ../foo.tar" | 12:03 |
| jelmer | jam: Yep, I'm packaging it for Debian and Ubuntu. | 12:04 |
| jelmer | jam: I don't use sdist, the packaging magic simply runs "setup.py install" directly from the packaging branch (which is derived from your trunk with an extra debian/ dir) | 12:04 |
| === psynaptic is now known as psynaptic|lunch | ||
| spiv | jelmer: just briefly | 12:15 |
| spiv | jelmer: some of the new fetch_spec stuff has a if_present_ids param (or something like that) | 12:15 |
| spiv | jelmer: because e.g. when fetching revisions named by tags we want to fetch them if they exist, but not fail if they turn out to be not present in that repo | 12:16 |
| spiv | jelmer: perhaps that concept is what that "bzr log" issue needs | 12:16 |
| * spiv -> zzz | 12:17 | |
| jelmer | spiv: We do want to know about missing revisions, since they should still be mentioned in log as being missing | 12:17 |
| jelmer | spiv: anyway, perhaps we can discuss that later. G'night! | 12:17 |
| jam | jelmer: we could have 'revision_trees' return None rather than raising an exception, as an example | 12:18 |
| jam | possibly by adding a flag so that current users of the api aren't surprised | 12:18 |
| jelmer | jam: Yeah, it's the current callers I'm worried about. A flag would work. | 12:26 |
| jelmer | jam: Perhaps returning an AbsentTree rather than None, so we can still access the relevant revision id? | 12:32 |
| jam | jelmer: something like that seems fine to me | 12:32 |
| jam | I thought revision_trees always returned in order | 12:32 |
| jam | and most callers zip the input list with the returned values | 12:32 |
| jam | I could be wrong | 12:33 |
| xarinatan | Hey guys, i'm getting a weird error when trying to commit a lot of data with tortoise bzr http://pastebin.com/XMtwzW0r can someone help me? | 12:34 |
| jam | xarinatan: so usually "TooManyConcurrentConnections" is actually a failure somewhere else, that is then covered up by us getting an error while running the cleanup code to handle the original error. | 12:35 |
| jam | I'm very surprised to see this happening during the "_rpc_open_2_1" | 12:36 |
| jam | since it indicates it is happening before we've even connected to the other branch. | 12:36 |
| xarinatan | Weird, i am currently SSH'd into that server with said username and everything seems fine | 12:37 |
| xarinatan | I had the same error earlier and i couldn't find out why it did, so i recreated the repository and first checked in a small bit of data, that worked fine | 12:37 |
| xarinatan | Small bits of data seem to go fine | 12:41 |
| xarinatan | the 'big' commit was ~340MB, 25756 files | 12:46 |
| xarinatan | oh wait, apparently the 'small' commit was bigger then i thought, about 720MB | 12:47 |
| xarinatan | but only 250 files | 12:47 |
| xarinatan | Maybe i'm overfilling some buffers or my RAM if i commit that much files.. | 12:52 |
| dOxxx | good morning | 12:57 |
| vila | hey dOxxx ! | 12:57 |
| dOxxx | vila: quick question re plugin versions | 12:57 |
| vila | yup, fire it :) | 12:57 |
| dOxxx | vila: should I be using trunk for all plugins or just the two that didn't work with bzr 2.4b1? | 12:58 |
| dOxxx | didn't load* | 12:58 |
| vila | hehe, tricky one ;) | 12:58 |
| dOxxx | I was thinking I should only do it for hte plugins which didn't load | 12:58 |
| vila | the conservative answer would be: switch to trunk when something bad happen | 12:58 |
| dOxxx | I don't want to distirbute tip for all plugins and then have to switch back for final release because the author never made a stable release | 12:59 |
| vila | the aggressive one would be: always use trunk until we approach the .0 release | 12:59 |
| vila | exactly | 12:59 |
| vila | plus some trunks may be bogus | 12:59 |
| dOxxx | yeah | 12:59 |
| vila | on the other hand, we have beta releases to *expose* the latest and greatest | 12:59 |
| dOxxx | bleh | 13:00 |
| vila | ? | 13:00 |
| dOxxx | just an annoying situation | 13:00 |
| vila | yeah | 13:00 |
| dOxxx | I don't have time to test all the plugins | 13:00 |
| vila | I think it's a balance between packagers and plugin authors being pro-active or not | 13:01 |
| vila | yup, the installer focused test suite... | 13:01 |
| dOxxx | it would be nice | 13:01 |
| vila | ... which still doesn't exist :-/ | 13:01 |
| dOxxx | something that exercises all the bundled plugins to see that nothing blows up | 13:01 |
| vila | but indeed would help | 13:01 |
| === psynaptic|lunch is now known as psynaptic | ||
| vila | yeah, so, what we currently have is the daily builds which help decide which plugin versions should be distributed | 13:02 |
| dOxxx | we do? | 13:02 |
| vila | but the ppas imply that *some* version is defined and tracked in a branch | 13:03 |
| vila | dOxxx: for Ubuntu yes | 13:03 |
| vila | dOxxx: for 2.4b1, I'd say just switch bzr-pipeline to tip | 13:04 |
| dOxxx | and svn | 13:04 |
| vila | jelmer: is there a 2.4-compatible release for bzr-svn ? | 13:04 |
| vila | jelmer: or is the trunk tip good enough to embed in the 2.4b1 OSX installers ? | 13:05 |
| xarinatan | Can someone point me to what i should change or how i can fix this error: http://pastebin.com/XMtwzW0r ? small commits are fine (<1000 files) but large commits seem to give that error | 13:07 |
| maxb | The implication is a bug in bzr, but that's not something I've ever seen. | 13:10 |
| vila | xarinatan: there nothing obvious there, file a bug at http:/pad.lv/fb/bzr | 13:12 |
| vila | xarinatan: that would be easier to track progress and ask you for more details | 13:12 |
| xarinatan | vila: Okay, i'll do that then. | 13:12 |
| vila | xarinatan: the weird thing is that the *size* of the commit shouldn't matter... | 13:13 |
| vila | xarinatan: the only vaguely similar issue I can think of was one related to ssh key renegotiation when reaching a 1GB threshold (on transmitted data) but 1) I'm pretty sure launchpad has some specific config that was exhibiting it 2) the symptom was different | 13:15 |
| vila | xarinatan: did you look at the .bzr.log on the server ? | 13:16 |
| xarinatan | Well it's only 70MB of data, but nearly 10,000 files | 13:16 |
| xarinatan | 'small' commits of 720MB with only 250 files go through just fine | 13:17 |
| xarinatan | So i'm suspecting some buffer overflow maybe? | 13:17 |
| vila | xarinatan: add the relevant parts of the .bzr.log from client and server to the bug report, there may be something there | 13:18 |
| vila | xarinatan: there are bigger projects (in terms of # files), but 720MB for 250 files sounds big, any binaries there ? (Shouldn't matter either..) | 13:19 |
| xarinatan | Some archive(zip) files and images, i was planning on using bazaar as 'versioned backup system' for my School and work project data sticks, which both hold about 5 gigs of data, of which most is 100% original content created by me, so for that this system would be perfect if it works ^^; | 13:21 |
| xarinatan | I have a lightweight ubuntu virtual machine setup at home for the data storage | 13:22 |
| vila | xarinatan: hmm, there was a report recently about some weird ssh issues when using NAT for a VM | 13:22 |
| xarinatan | Where can i find the .bzr.log file btw? | 13:22 |
| vila | what virtualization software are you using ? | 13:23 |
| xarinatan | It's not NATted | 13:23 |
| xarinatan | I'm using KVM | 13:23 |
| xarinatan | I'm logging in through OpenVPN.. | 13:23 |
| dOxxx | `bzr version` will tell you where your log file is | 13:23 |
| vila | xarinatan: like dOxxx said, but make sure you run it on the server with the same settings as the user connecting there | 13:24 |
| xarinatan | what do you mean by 'same settings'? | 13:24 |
| vila | xarinatan: just do 'ssh user@host bzr version' and you should be fine | 13:25 |
| xarinatan | Oh! That could be it, i'm using the default ubuntu repos for the bzr installation, those might be a bit behind on the actual version | 13:26 |
| xarinatan | Hah, yes, stupid me, the server is running 2.2.1 and i'm running 2.3.1 on the client ^^;.. | 13:27 |
| xarinatan | Weird that it works with smaller commits though | 13:28 |
| vila | xarinatan: still worth reporting as a bug mentioning the client/server versions involved | 13:28 |
| xarinatan | villa: Will do | 13:29 |
| vila | xarinatan: this should be supported, servers can't always be upgraded as fast as clients and they are supposed to be compatible | 13:29 |
| vila | xarinatan: it's not even sure that upgrading the server will address the issue | 13:29 |
| vila | good afternoon mgz ;) | 13:31 |
| xarinatan | I'll check if it fixes it =p | 13:31 |
| vila | hmmm, how much memory does your VM server has ? | 13:32 |
| vila | mgz: before your patch, can you remember me how memory errors were reported from a smart server ? | 13:32 |
| vila | xarinatan: hmmm, how much memory does your VM server has ? | 13:34 |
| vila | bleh, 'how much memory on the VM server' is probably better english :-/ | 13:35 |
| Peng | I'd go with "how much memory does it have". | 13:35 |
| vila | rats, thanks Peng ;) | 13:36 |
| fullermd | "does it have the geebees?" | 13:36 |
| dOxxx | hmmm just thinking about it now... the rules on when to use 'has' vs 'have' are not clear | 13:37 |
| dOxxx | I have. You have. They have. It has. vila has. the server has. how much does it have? | 13:38 |
| dOxxx | really not predictable | 13:38 |
| fullermd | 'has' is third person... | 13:38 |
| vila | fullermd: geebees like the shaddoks friends ? | 13:38 |
| fullermd | I have. You have. He/she/it has. | 13:38 |
| dOxxx | so why then is "how much does it have?" correct? | 13:38 |
| vila | fullermd: http://en.wikipedia.org/wiki/Les_Shadoks says it's spelled Gibis (even in english) so probably not ;) | 13:39 |
| dOxxx | I guess there are exceptions. | 13:39 |
| fullermd | Ugh, I've forgotten too much linguistics to explain it. It's not a subject verb there... | 13:40 |
| dOxxx | oh hmm I see | 13:40 |
| dOxxx | the ver is 'does' in the sentence | 13:40 |
| dOxxx | verb* | 13:40 |
| vila | and when should it be "does it had" vs "does it have" ? | 13:40 |
| dOxxx | never | 13:40 |
| fullermd | It's not a participle, it's something related. | 13:40 |
| dOxxx | it would "did it have" for past tense | 13:40 |
| dOxxx | be^ | 13:41 |
| fullermd | I'll go with "languages are all stupid" for $300, Alex. | 13:41 |
| xarinatan | Sorry, back, upgraded BZR on the server in question | 13:42 |
| xarinatan | And the VM has 1GB RAM and 1GB Swap, previously had 256MB RAM but that was obviously not enough when i committed large files :P | 13:42 |
| fullermd | Also related: http://www.qwantz.com/index.php?comic=1915 :p | 13:42 |
| jam | anyone in the US or AU that can run a script for me? I'm trying to see how long interactions take with Launchpad from various locations | 13:44 |
| xarinatan | Also, isn't it "How much does your server have?"? I'm dutch, i don't remember exactly how the rules were taught back in highschool, but surely it had some correlation to what form was used | 13:44 |
| beuno | jam, Argentina any good? | 13:45 |
| jam | http://paste.ubuntu.com/584285/ | 13:45 |
| jam | beuno: would be good for me | 13:45 |
| jam | beuno: can you run the above paste ? | 13:46 |
| dOxxx | xarinatan: yes 'have' would be correct, we were just trying to figure out why :) | 13:46 |
| beuno | jam, running | 13:46 |
| jam | beuno: I'm seeing 300+ms from Netherlands, which seems pretty crazy long. | 13:46 |
| vila | 10 loops, best of 3: 330 msec per loop from here | 13:47 |
| fullermd | Maybe it is a [present] participle... | 13:47 |
| vila | fullermd: hehe nice comic ;) | 13:47 |
| fullermd | 10 loops, best of 3: 897 msec per loop | 13:47 |
| beuno | jam, 10 loops, best of 3: 1.87 sec per loop | 13:47 |
| jam | beuno, fullermd, vila: that is the time to resolve "lp:bzr" into a bzr+ssh url | 13:48 |
| xarinatan | dOxxx: your ____ have, it's a property of someone else. . oh well, i'm not linguist :P I'll leave that upto people who actually study the language | 13:48 |
| vila | jam: I'm sure you've know found a great way to stress test the forking server ;-D | 13:48 |
| vila | s/know/now/ :-( | 13:48 |
| jam | vila: no, that is the XMLRPC server | 13:48 |
| jam | vila: https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523 | 13:48 |
| ubot5 | Error: Launchpad bug 2 not found | 13:48 |
| jam | if you want that time to go away | 13:48 |
| vila | jam: nm, the joke was lost | 13:49 |
| dOxxx | xarinatan: yeah something like that. possessive. | 13:49 |
| jam | vila: it would have been better if we actually logged in | 13:49 |
| beuno | jam, that's pretty crazy | 13:49 |
| fullermd | (LP being ~125ms from here) | 13:49 |
| fullermd | So a mere 7 round trips... | 13:49 |
| xarinatan | vila: I'm currently doing a commit with the upgraded version on my server, see if it makes a difference | 13:50 |
| xarinatan | vila: It looks like it's working this time, with about 12,000 files | 13:50 |
| fullermd | vila: Everybody loves Dinosaur Comics, don't they? :p | 13:50 |
| jelmer | hmm, something is eating PQM emails again for me :( | 13:51 |
| xarinatan | jam: Are you from holland btw? Since you mentioned the netherlands | 13:52 |
| jam | xarinatan: I'm actually from the US, but I'm living in Netherlands for a couple years. | 13:53 |
| jelmer | jam: I thought launchpad supported short names for http as well these days. Certainly bzr log http://code.launchpad.net/bzr works for me. | 13:53 |
| jam | my wife got a promotion and temporary training here | 13:53 |
| jam | jelmer: it works for Loggerhead, but not for 'bzr branch' | 13:53 |
| fullermd | I had to kick jam out of my $TZ; he was making me look bad with all that "getting up at a reasonable hour" stuff :p | 13:53 |
| xarinatan | jam: How's the language for you? :P I heard some people who tried to move over to here complain about it a lot | 13:53 |
| jam | xarinatan: I know almost no dutch. It happens that we live in Eindhoven, where 90% of the people work for Philips, who mandates English on campus | 13:54 |
| jam | I'm exaggerating slightly, but I haven't had a problem getting people to talk to me in English | 13:54 |
| jam | except for the ones that stop asking for directions while I'm walking down the street. | 13:54 |
| jam | why are they picking me? :) | 13:54 |
| xarinatan | jam: Aha, well that's nice too, though most of the 'dutchies' speak english anyway ^^; | 13:54 |
| vila | jam: cos' you're walking and not using a car ? :-D | 13:55 |
| jam | vila: so are they | 13:55 |
| jelmer | jam: Hah, so I guyess you already make the impression you look like you belong ? :-P | 13:55 |
| jam | but I'm also walking with my son | 13:55 |
| jam | so maybe I'm safe | 13:55 |
| xarinatan | jam: You must be secretly dutch! :P | 13:55 |
| jam | jelmer: It happened to happen 2 times over the weekend | 13:55 |
| jam | xarinatan: german descent... | 13:55 |
| jelmer | jam: it works for bzr branch for me too ("bzr branch http://code.launchpad.net/bzr ~/tmp/bzr") | 13:56 |
| xarinatan | jam: Same difference, except everything sounds like a curse there, i love german xD | 13:56 |
| vila | jam: yes, that's why they can stop you ;-D | 13:56 |
| vila | jam: but, jokes aside, the kid part is probably the trigger | 13:57 |
| jam | vila: yeah, that was my guess | 13:57 |
| jam | you don't look much like a tourist when you have a kid with you | 13:57 |
| jam | though if you hear him chattering away, they would know better | 13:57 |
| vila | hehe | 13:58 |
| dOxxx | jelmer: I may have missed your reply but should I be using bzr-svn trunk tip for bzr.2.4b1? | 13:58 |
| jelmer | dOxxx: ah | 13:58 |
| jelmer | dOxxx: yes | 13:58 |
| dOxxx | ok | 13:58 |
| jelmer | two more bugs to fix before 1.1.0 | 13:58 |
| jam | jelmer: speaking of which, new development in the dutch saga. We just found out that Customs won't actually let our goods through until April 1st. And our lease for short-term apartment ends on the 31st. Just silly given that they arrived before we did a month ago. | 14:02 |
| vila | jam: regarding https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523 | 14:02 |
| ubot5 | Error: Launchpad bug 2 not found | 14:02 |
| vila | jam: nice one :) But one question: | 14:02 |
| vila | what are the risks that we diverge from lp ? (0 ? We were already making assumptions about the lp implementation ?) | 14:03 |
| jelmer | jam: wtf? This is the Dutch customs? | 14:03 |
| jam | jelmer: yep. | 14:04 |
| jam | I guess part of the issue is they can't start the paperwork until we get here and get BSN numbers, etc | 14:04 |
| jam | which takes a wek | 14:04 |
| jam | week | 14:04 |
| fullermd | I told you trying to smuggle in those kidneys would be trouble... | 14:04 |
| vila | jam: how tasty for an April 1st hoax... | 14:04 |
| jam | vila: you can follow the bug | 14:04 |
| jam | but LP explicitly implemented "+branch/foo" so that we could use it | 14:04 |
| jelmer | jam: And I thought moving to the US was hard (a friend of mine is moving from Eindhoven to CA) | 14:04 |
| jam | very low chance we'll diverge | 14:05 |
| jam | especially since it will start breaking for people once we stop using xmlrpc :) | 14:05 |
| jam | jelmer: well, there are quite a few things that could have made it smoother. Having my bank in the US allow scheduling international wires without being physically present. | 14:05 |
| jam | What's funny is that most of the Expat stuff from Eindhoven was very fast | 14:06 |
| jam | and they have a huge Expat center in the middle of town | 14:06 |
| jam | so its something they supposedly care a lot about | 14:06 |
| jelmer | jam: Ah :-/ How's that going, is the bank still holding up your cheques? | 14:06 |
| jam | (30% tax free income for my wife, etc) | 14:06 |
| jam | jelmer: yep | 14:06 |
| jam | we have confirmation that it made it to Amsterdam, a *week* after we gave it to the local bank | 14:06 |
| jam | apparently they operate by carrier pidgeon | 14:07 |
| jelmer | heh | 14:07 |
| jelmer | a courier walked to Amsterdam perhaps? | 14:07 |
| fullermd | It went by boat. For security reasons, y'know. | 14:08 |
| briandealwis | Hi everybody. I have a private branch that I want to amend a couple of commit messages before pushing to a public branch. I should know this, but is there a plugin for rewriting a commit message — knowing that it'll destroy history? Or is there an alternative beyond merging each commit one at a time? | 14:08 |
| jelmer | briandealwis: you should be able to fastexport the commits, edit the stream and reimport | 14:09 |
| maxb | jelmer: "I'm able to branch from https://code.launchpad.net/bzr-svn ." ..... really!?!? Does not work for me and I cannot see how it would. | 14:09 |
| jelmer | maxb: | 14:09 |
| jelmer | charis:~/src/hydrazine/trunk% BZR_PDB=1 bzr branch --no-plugins https://code.launchpad.net/bzr-svn ~/tmp/bsa | 14:09 |
| briandealwis | jelmer: hmm, there's 16000-odd commits... | 14:09 |
| jelmer | Branched 3647 revision(s). | 14:09 |
| dOxxx | briandealwis: you can also, with some effort, combine uncommit and shelve to reverse your commits and recommit them with updated messages. | 14:09 |
| briandealwis | dOxxx: that's a good idea. thx | 14:10 |
| jam | maxb: code.launchpad.net/bz-svn has a 'BranchReference' pointer at | 14:10 |
| jam | ttps://code.launchpad.net/bzr-svn/.bzr/branch/location | 14:10 |
| jam | https://code.launchpad.net/bzr-svn/.bzr/branch/location | 14:10 |
| maxb | ahh! (And it is probably being broken by one of the foreign bzr plugins, then) | 14:10 |
| jam | maxb, jelmer: that was how we implemented lp:foo before the XMLRPC was added | 14:10 |
| jelmer | maxb: Yeah, bzr-hg breaks it | 14:10 |
| jam | jelmer: because it inserts itself earlier in the stack? | 14:11 |
| jelmer | jam: ah, I wasn't aware of that | 14:11 |
| jelmer | jam: yep | 14:11 |
| maxb | Is there a reason why we don't always probe for bzr-native formats first? | 14:11 |
| jelmer | jam: is there any reason to prefer XMLRPC over the branch references? It seems in case of the branch references it's possible to keep the same HTTP connection | 14:11 |
| jam | jelmer: I mentioned on the bug, it also involves an SSL request in what would otherwise be pure-HTTP | 14:11 |
| jam | jelmer: not possible | 14:11 |
| jam | different top-level domain, and HTTPS vs HTTP | 14:11 |
| jelmer | maxb: the bzr smart server does a POST request and that blows up on several foreign servers (e.g. google code errors with a 401) | 14:12 |
| jam | so you can't re-use the connection | 14:12 |
| jelmer | jam: ah, argh :-( | 14:12 |
| vila | jam: just re-read the bug (bunch of pages ;) and it mentions the http urls too, may be you should clarify the situation in a bug comment before closing the bug | 14:12 |
| maxb | It seems like it would be nice to allow foreign plugins to attach fallback probing after such a failure | 14:12 |
| jelmer | maxb: that's been discussed a couple of times on the list | 14:13 |
| jelmer | maxb: and there's a bug about it | 14:13 |
| jam | jelmer: yeah, I think the issue is that there are *valid* cases where a server would issue 401 (that is Auth required, right?) in response to POST | 14:14 |
| vila | jam: or may be just file a new bug so your proposal is not blocked on the http discussion | 14:14 |
| jelmer | jam: right | 14:14 |
| jam | jelmer: seems like it would be nicest to have a whitelist/blacklist of known sites that use X format. | 14:15 |
| jam | or just remember the last one to succeed and use it first next time | 14:16 |
| jelmer | jam: I think we should try to avoid the POST unless we know there is bzr at that site | 14:16 |
| jelmer | jam: e.g. check for .bzr/branch-format, then try the POST and if that fails fall back to use with the format directly | 14:17 |
| jam | jelmer: but how do we *find out* (and arguably, it adds a round-trip overhead for what we want to be the fast case) | 14:17 |
| maxb | Encourage people to use bzr+http, hg+http etc? | 14:17 |
| jam | maxb: we had svn+ and I guess people really didn't like it | 14:17 |
| jelmer | maxb: I think a single very small HTTP request is worthwhile overhead to not have to type foo+ | 14:18 |
| vila | jam: the issue that was discussed made it clear that POSt was also forcing an additional round-trip (and led to failures) | 14:18 |
| jelmer | it is still always possible for people to use bzr+http://.... if they care about that roundtrip | 14:18 |
| vila | jam: the situation today is that people that install foreign plugins *do* an additional round-trip *before* trying the POST | 14:19 |
| jelmer | right now we do one extra roundtrip per foreign VCS plugin that's loaded before we probe for bzr formats | 14:19 |
| vila | yeah, per plugin even ;) | 14:19 |
| maxb | I think we should do the POST .bzr/smart, and if it fails, give plugins a chance to try things, and if none succeed, continue raising the original error | 14:20 |
| jelmer | maxb: that doesn't work, as the POST can trigger a username/password prompt | 14:20 |
| maxb | gah | 14:20 |
| vila | and that's without mentioning walking up the url to find the format ? | 14:21 |
| vila | or is it only after we successfully found the branch format ? | 14:21 |
| jelmer | vila: yes, though generally people don't specify inside-branch paths for remote URLs | 14:21 |
| jelmer | vila: that's something we could make better though - there's no need to walk down for SVN branches for example | 14:23 |
| * vila nods | 14:24 | |
| dOxxx | looks like bzr 2.4b1 is happy with trunk versions of svn and pipeline | 14:24 |
| dOxxx | or at least they pass the `bzr plugins` smoketest | 14:25 |
| dOxxx | uploading... | 14:27 |
| vila | dOxxx: \o/ | 14:27 |
| jelmer | jam,vila: Actually, if a user specifies a URL that doesn't contain a .bzr dir it's quicker to check for .bzr/format first because then we can skip the dumb format check before descending one level | 14:27 |
| jelmer | though I'm not sure how much we care about that use case | 14:27 |
| dOxxx | it's murdering my remote desktop connection to work though XD | 14:29 |
| jam | jelmer: there is no .bzr/format, there is .bzr/branch/format and .bzr/branch-format | 14:32 |
| xarinatan | Just submitted the bug report regarding the large amount of file issue from 2.3.1 clients to 2.2.1 servers https://bugs.launchpad.net/bzr/+bug/741015 | 14:32 |
| ubot5 | Ubuntu bug 741015 in Bazaar "BZR crashes when large amounts of files are committed through TortoiseBZR over bzr+ssh from 2.3.1 client to 2.2.1 server." [Undecided,New] | 14:32 |
| jelmer | jam: Sorry, I mean .bzr/branch-format | 14:32 |
| jelmer | I still think that's an odd name for something that actually describes the control dir format, but I guess that's for historical reasons? | 14:33 |
| jam | jelmer: ideally we would have a proper probe to .bzr/smart to get the full branch + repository at any given level. It is certainly one of my pet-peeves that we have about 10 round trips just to say "yes you have a Branch" | 14:33 |
| jam | jelmer: yeah, we had it before we did the split out | 14:33 |
| jam | and by keeping the name, old clients can say "I don't know what branch format this is" rather than saying "I don't see a branch" | 14:33 |
| jam | of course, it has been 4 years since we had clients that didn't know about MetaDir :) | 14:34 |
| jam | but also no push to actually change it | 14:34 |
| jam | vila: is there any way to instrument the XMLRPC stuff? It looks like the current lp: resolving code is going to an https server | 14:34 |
| jam | which is where all the overhead is | 14:34 |
| jam | 1 0 1.1641 1.1641 <built-in method do_handshake> | 14:35 |
| jam | which is part of the ssl module | 14:35 |
| jam | the stack goes through our _urllib2_wrappers | 14:35 |
| dOxxx | I must revisit my qbzr branch for the mergetool stuff so that it can be bundled into bzr 2.4 | 14:35 |
| vila | jam: -Dhttp from command-line, for more stuff see DEBUG in _u2_wrappers 1 for basic stuff 9 for all | 14:36 |
| jelmer | jam: It would be nice if we could do that without a POST request.. | 14:36 |
| jam | jelmer: "do that without" ? | 14:37 |
| jam | probe for whether there is a smart server? | 14:37 |
| jelmer | jam: Probing to .bzr/smart | 14:37 |
| vila | jam: but I don't think you'll get timings from that | 14:37 |
| jam | vila: I have -Dhttp set, and it doesn't seem to see the XMLRPC stuff | 14:37 |
| jam | vila: I'm wrong, it is in the log | 14:38 |
| jam | just hard to find | 14:38 |
| vila | may be because it use a cutom Request ? | 14:38 |
| jam | it looks like we explicitly only make the request to xmlrpc.launchpad.net:443 | 14:39 |
| jam | vila: LAUNCHPAD_INSTANCE[instance] = 'https://xmlrpc.%s/bazaar/' % domain | 14:41 |
| jam | it looks like at some point we recently updated the launchpad lp_registration plugin to make its requests via SSL | 14:42 |
| jam | which adds a rather significant amount of overhead | 14:42 |
| jam | in my lsprof timing, it is 1.2s | 14:42 |
| jam | which is far worse than the 300ms or so if you do it in a loop | 14:42 |
| jam | vila: do you automatically get connection sharing via our urllib2 enhancements? | 14:42 |
| jam | or do you have to save some object to get that? | 14:43 |
| vila | from what layer ? | 14:43 |
| dOxxx | vila: osx installer uploaded and changes on trunk committed. I haven't branched for 2.4 yet. | 14:46 |
| vila | dOxxx: ok, I was wondering about that, do you plan to create 2.4 branch or should we wait for the 2.4.0 release instead ? | 14:46 |
| dOxxx | I think I'll wait | 14:47 |
| vila | ok | 14:54 |
| jam | vila: I was just wondering if my looping xmlrpc stuff was connection sharing | 14:56 |
| jam | which would explain why it looks like 1.2s real world time, but the loop shows it as 300ms | 14:56 |
| vila | haaa, well, I looked briefly at the lp_directory stuf but I'm not even sure it uses _u2_wrappers there... | 14:58 |
| vila | and you need to poke hard at urllib2 to use persistent connections (unless things have changed in recent python versions but I really doubt it) | 14:59 |
| vila | jam: you can copy httplib.py and patch it (that's what I did pas then), there should be a debug or DEBUG variable or attribute somewhere | 15:01 |
| vila | s/pas/past/ | 15:01 |
| jam | vila: then it most likely isn't a persistent connection thing | 15:02 |
| jam | we create a new LaunchpadRequest object, etc. each time | 15:02 |
| jam | there isn't any cache state in LaunchpadDirectory | 15:03 |
| jam | and I'm not trying to make it faster, I'm trying to skip the ssl handshake entirely :) | 15:03 |
| vila | use http :) | 15:05 |
| jam | jelmer: your first report about bzr-git not allowing --excludes :) | 15:16 |
| jam | lucky you (bug 403811) why is it showing up as NEW for me | 15:16 |
| ubot5 | Launchpad bug 403811 in Bazaar "commit with record_iter_changes should support exclude" [Medium,Confirmed] https://launchpad.net/bugs/403811 | 15:16 |
| jam | ah, it is just connecting it to the debian bug | 15:17 |
| jelmer | yep | 15:26 |
| jelmer | hmm, I wonder if the cleanup.OperationWithCleanup could be useful as a decorator | 15:30 |
| === psynaptic is now known as psynaptic|food | ||
| jelmer | vila: I'm getting test failures during 2.4b1 | 15:35 |
| jelmer | 3 instances of IllegalUseOfScopeReplacer and a remote upgrade command that takes fewer requests than expected | 15:35 |
| vila | O_o context ? | 15:37 |
| jelmer | vila: I'm trying to build the 2.4b1 packages, currently trying to figure out what we're doing differently in the packaging to trigger those errors | 15:38 |
| vila | ha, at least you don't get the failures locally ? | 15:39 |
| jelmer | well, I get them locally but only when run in my debian sid chroot using the packaging arguments (disabling the launchpad plugin, for example) | 15:41 |
| vila | with --no-plugins ? | 15:41 |
| * vila running B_P_P=-site to see | 15:41 | |
| === psynaptic|food is now known as psynaptic | ||
| === psynaptic is now known as psynaptic|shower | ||
| vila | jelmer: right, can't reproduce here :-/ Any more hints ? | 15:46 |
| briandealwis | jelmer: I'm doing a dpush to push up 4 small revisions with bzr-svn to a server (first time ever dpushing here). There's a message: "Storing Bazaar metadata in file properties. Use `bzr dpush` for lossfull push without file properties.Upgrade the server to Subversion 1.5 or later to use (less visible) revision properties.", and it seems to be transferring the world: almost 300MB so far. | 15:51 |
| briandealwis | jelmer: is this expected? It's a big deep tree (16k revisions). | 15:51 |
| briandealwis | jelmer: and I don't know what version it's running remotely, and can't see how to find out | 15:52 |
| === deryck is now known as deryck[lunch] | ||
| vila | jelmer: got the one failure in bb bzr info you fixed lately with --no-plugins | 15:56 |
| vila | jelmer: are you trying to run with --parallel ? (just checking, I did my run with --parallel=fork anyway) | 15:57 |
| jelmer | vila: yes, this is with --parallel | 15:59 |
| jelmer | I haven't reproduced it outside of the package scripts yet | 15:59 |
| vila | jelmer: any idea of the number of processes involved ? | 16:00 |
| jelmer | vila: it'd be 4 processes. The env variables we set include: BZR_HOME=debian/bzrhome \ | 16:00 |
| jelmer | BZR_PLUGIN_PATH=-site:-user \ | 16:00 |
| jelmer | BZR_DISABLE_PLUGINS=launchpad \ | 16:00 |
| jelmer | briandealwis: what version of bzr-svn? | 16:00 |
| briandealwis | jelmer: 1.0.4 | 16:01 |
| vila | jelmer: I always run with 8, but there was failures loooong ago when using different numbers (because it slices tests in different ways, this may trigger different isolation test bugs) | 16:01 |
| briandealwis | It sounds very much like the problem described here: http://web.archiveorange.com/archive/v/mvjb49H5gqOiXreQjtmn | 16:01 |
| vila | jelmer: -user is useless here ;) Why do you disable launchpad / | 16:02 |
| vila | ? | 16:02 |
| jelmer | vila: the launchpad plugin tests connect with launchpad | 16:03 |
| vila | grrr, sorry, forgot it again :-/ | 16:03 |
| briandealwis | jelmer: I interrupted it after 500mb; it pushed 3 revisions up. Pushing the final revision was very quick. Very bizarre. | 16:04 |
| jelmer | briandealwis: there's a bug about that, fixed in trunk | 16:05 |
| briandealwis | jelmer: ah great! | 16:05 |
| jelmer | vila: http://pastebin.ubuntu.com/584355/ | 16:06 |
| vila | jelmer: right, so 'ui' is involved in all cases so probably the same root cause | 16:09 |
| jelmer | vila: ui? I thought it was branch | 16:09 |
| vila | well, not in the pastebin you just paste AFAICS | 16:10 |
| vila | errr, except for the first failure >-/ | 16:10 |
| vila | s/failure/error/ | 16:10 |
| jelmer | and the last | 16:10 |
| jelmer | I hate how we catch all exceptions during upgrade :-/ | 16:11 |
| jelmer | I'm not entirely sure how to deal with these scope exceptions though - these imports seems perfectly reasonable to me | 16:12 |
| vila | old == _mod_branch.BzrBranchFormat5 ... I'm not sure you're allowed to do that with lazy objects (jam ?) | 16:12 |
| jelmer | it's been like that forever though, we haven't touched it in the last few cycles | 16:12 |
| vila | jelmer: unfortunately, that's irrelevant :-/ There could be side-effects with lazy loading | 16:13 |
| jelmer | ah, I see | 16:17 |
| === psynaptic|shower is now known as psynaptic | ||
| vila | jelmer: the bright side is that you're exposing genuine bugs in our imports here :-/ | 16:23 |
| vila | jelmer: as generally fixing these bugs is adding the right import in the right place.... :-} | 16:24 |
| jelmer | vila: what worries me is that these are hard to reproduce :-/ | 16:25 |
| vila | jelmer: I know :-( Not using --parallel may work around the issue in the mean time | 16:26 |
| sidnei_ | uhm, is there any change with plugins in bzr trunk? i installed the daily build and now my custom plugins don't seem to be registered anymore | 16:54 |
| sidnei_ | oh, maybe they are not compatible with the api version and didn't get loaded or something | 16:55 |
| vila | sidnei_: probably, but this didn't happen yesterday, more like several weeks ago (unless the daily build has been failing for some time ?) | 16:56 |
| sidnei_ | vila, i installed the daily build today to check out jam's fixes | 16:56 |
| vila | sidnei_: right, but when was your previous install ? | 16:56 |
| sidnei_ | vila, i haven't used daily builds, not since i reinstalled from scratch several weeks ago. i was running 2.3.0 before. | 16:57 |
| vila | ha ok, then yes, the API have changed | 16:57 |
| vila | well, if your plugins *test* the compatible API that is | 16:58 |
| === psynaptic is now known as psynaptic|break | ||
| === fjlacoste is now known as flacoste | ||
| briandealwis | I'm in a situation where I have a codebase where I need to make some patches for the code to work locally within my IDE. These patches shouldn't be committed. But shelving and unshelving them before a commit is a bit painful. Pipeline/loom doesn't seem the right fit… Any suggestions? | 17:10 |
| === beuno is now known as beuno-lunch | ||
| briandealwis | mm, I guess I want something like Darcs' ability to reorder patches | 17:14 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === psynaptic|break is now known as psynaptic|afk | ||
| ryan_scott | I have to use a different VCS for work reasons, but am really missing the bzr visual diff tool. | 19:22 |
| ryan_scott | Does anyone know if it can be called by itself? | 19:22 |
| beuno | ryan_scott, which one is that? | 19:23 |
| beuno | meld? | 19:23 |
| ryan_scott | Whatever is the default for bzr on the windows client. | 19:24 |
| * beuno doesn't do windows | 19:24 | |
| * ryan_scott used to not do windows and was happier about it. | 19:27 | |
| ryan_scott | Specifically I miss doing development on Linux | 19:28 |
| jam | lifeless: sometime I'd like you to take a look at a possible race issue for concurrent fetching into a pack repository. | 19:49 |
| jam | My bug comment is here: https://bugs.launchpad.net/bzr/+bug/709349/comments/13 | 19:50 |
| jam | but the basic summary | 19:50 |
| ubot5 | Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,Incomplete] | 19:50 |
| jam | 2 bzr processes are run concurrenty to fetch from the same branch into the same repository. | 19:50 |
| jam | Both of them are thus fetching exactly the same content, but since they start concurrently, neither one sees that the other is doing the work | 19:50 |
| jam | when one finishes, it adds the pack to the repo | 19:50 |
| jam | (renames it into packs, updates pack-names) | 19:50 |
| jam | it then goes to autopack, and sees that this new pack needs to be moved to obsolete packs | 19:51 |
| jam | so it removes it from pack-namse, but has not renamed it to obsolete yet | 19:51 |
| jam | the second process then sees "ok, I'm done fetching, let me put this new content into the repo" | 19:51 |
| jam | "oh look, it isn't already presenT" | 19:51 |
| jam | renames it *over top* of the existing pack file | 19:51 |
| jam | updates pack-names to add the new file | 19:52 |
| jam | process 1 finishes and renames the newly re-added file to obsolete_packs | 19:52 |
| lifeless | jam: kk; I just got off a call; I'll look right after breakfast | 19:52 |
| jam | lifeless: no problem. I'm heading out. | 19:53 |
| jam | I just wanted a second opinion since you did a lot of the pack danec | 19:53 |
| jam | dance | 19:53 |
| jam | lifeless: the key is 2 fetches doing identical content concurrently, I think | 19:53 |
| lifeless | nice | 19:53 |
| lifeless | sounds plausible | 19:53 |
| lifeless | damn concurrency is hard | 19:53 |
| === Ursinha-lunch is now known as Ursinha | ||
| === psynaptic|afk is now known as psynaptic | ||
| LeoNerd | Someone remind me... having accidentally killed a branch by overwriting a pull... how do I get it back? I can see it in bzr heads --dead | 23:55 |
| soren | LeoNerd: bzr pull . -r revid:your_rev_id | 23:58 |
| LeoNerd | Hrmmmm.. it claims it's diverged... | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!