| lifeless | jam: 110G and growing, 13K to go | 00:14 |
|---|---|---|
| hoser | Is anyone familiar with bzr.webdav? | 00:20 |
| poolie | hoser: not very, but if you have a question go ahead and ask | 00:26 |
| hoser | Hmm.. well.. at the moment I'm using svn for a lot of projects, and would like to switch to bzr. I've been looking at the webdav plugin but if I'm right, it's basically for the client side, and there's nothing but pure dav on the server side. With svn there are apache modules mod_dav_svn and mod_authz_svn. I'm just wondering if similar things exist somewhere | 00:28 |
| hoser | so that on the server you can implement read/write controls, allow different usernames to access different projects, etc | 00:29 |
| === jkakar_ is now known as jkakar | ||
| lifeless | we have a wsgi server | 00:36 |
| lifeless | and you can do some policy stuff there' for auth we depend on apache | 00:37 |
| lifeless | note that with a distributed vcs like bzr policy and access concerns are rather different | 00:37 |
| lifeless | rather than one repository with N different permissions and groups | 00:37 |
| lifeless | its easier to adminster N repositories, each for one user-or-group | 00:37 |
| hoser | yes, but I imagine most projects still have a central authoritative branch | 00:38 |
| lifeless | sure | 00:38 |
| hoser | which is all I'm concerned about | 00:39 |
| lifeless | the N repositories can be on the same server - apache has all tjhe facilies needed to do that with either wsgi or webdav | 00:39 |
| lifeless | [wsgi is a lot faster at push and pull than webdav] | 00:39 |
| hoser | So you recommend looking into wsgi, then | 00:40 |
| lifeless | yu | 00:40 |
| lifeless | yup | 00:40 |
| lifeless | its in our docs too | 00:40 |
| hoser | OK, will do. The key things that are currently motivating switching vcs are: renaming as a known operation, easy branch and merge, offline commits. So if I can sort out the server side I'll be very happy | 00:42 |
| lifeless | cool | 00:43 |
| hoser | Thanks for your help | 00:43 |
| lifeless | have a read of the docs and if they are unclear or you need inspiration / support just give us a yell | 00:43 |
| spiv | lifeless: want to review https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root/+merge/11033 ? | 01:02 |
| lifeless | sure | 01:03 |
| lifeless | spiv: you could look at my adjacent streams patch if you like | 01:10 |
| spiv | Ok. | 01:10 |
| lifeless | spiv: its not up for review as such, just look at the tip commit | 01:10 |
| spiv | lifeless: that looks reasonable. | 01:17 |
| lifeless | spiv: ok, I might land that now, to avoid noise in the other patch | 01:18 |
| lifeless | ok? | 01:18 |
| spiv | lifeless: Hmm. One comment: it's not clear from the method names/docstrings what the interface to that class is. | 01:19 |
| spiv | i.e. that you should call .record_stream rather than .iter_something... | 01:20 |
| lifeless | spiv: I could make them private, but its a private class | 01:21 |
| spiv | A brief comment in the class docstring, or renaming the other methods to have leading _, or something along those lines would be good. It will make understanding the class easier to make it clear what the entry point is. | 01:21 |
| lifeless | it kind of wants to be several classes | 01:21 |
| lifeless | one that does the lookahead handling and grouping | 01:22 |
| lifeless | and one that turns stuff into NetworkRecordStreams | 01:22 |
| spiv | Right, because of the relatively complex state it holds. | 01:22 |
| lifeless | and handwave | 01:22 |
| lifeless | otoh this is clearer I think than the previous code | 01:22 |
| lifeless | for all that it does more | 01:22 |
| spiv | Well, with the other code the "now what is the first method that calls the rest" was easy to answer because of the nesting of the functions :) | 01:23 |
| lifeless | I'll tinker a little. I don't feel much need to polish though: this was the only known defect in this area, and we knew that when we wrote it. | 01:23 |
| spiv | Just put "Expected usage: decoder = _ByteStreamDecoder(...); stream = decoder.record_stream()" in the class docstring if you like, that'd be enough to satisfy me. | 01:24 |
| lifeless | sure | 01:24 |
| === thumper is now known as thumper-afk | ||
| lifeless | grabbing foodstuffs | 01:46 |
| lifeless | spiv: why do you change pack_repo to know about chk_bytes? | 02:13 |
| spiv | lifeless: because it was convenient ;) | 02:16 |
| spiv | lifeless: I was thinking of pushing that into groupcompress_repo, though. | 02:16 |
| spiv | Now that I've made a separate method that GCPackCollection could override. | 02:16 |
| lifeless | I suggested that | 02:17 |
| lifeless | but there is another implication | 02:17 |
| lifeless | we either are missing the check for inventories on packs | 02:17 |
| lifeless | or there is duplication amongst things withthis broad goal | 02:17 |
| lifeless | I ask that you look for which of those in your future work | 02:17 |
| spiv | I *think* the former, at least partly. | 02:17 |
| spiv | Because of the existing 'get missing parent inventories' checks that happen in streaming fetch (but perhaps not all fetch code paths?) | 02:18 |
| lifeless | throw a stream with only a revision in it at a repo; see what happens :) | 02:18 |
| lifeless | 10K to go | 02:35 |
| twb | You guys change your repo format a lot, right? | 02:51 |
| lifeless | some people think so | 02:51 |
| twb | What's the end-user workflow for updating the current repo's format? | 02:51 |
| lifeless | we're about to make our first change to the default since nov 2007 | 02:52 |
| lifeless | twb: 'bzr upgrade' | 02:52 |
| twb | OK, thanks. | 02:52 |
| lifeless | there is a guide with docs | 02:52 |
| lifeless | but that should be the heart of it :) | 02:52 |
| twb | (I work on Darcs, and we're adding in-place upgrading of the repo format. I want to avoid unnecessary differences with other VCS' CLIs.) | 02:53 |
| lifeless | cool | 02:53 |
| lifeless | what have you improved in the repo format? | 02:53 |
| twb | Several years ago we hashed the files in the "pristine" directory, which is an unmodified copy of the working tree. We also changed the semantics of patch application, e.g. two identical changes no longer conflict. | 02:54 |
| twb | Historically upgrades have been done by making a copy of the repo, but people want to be able to make the change in-place. | 02:55 |
| lifeless | yeah | 02:55 |
| lifeless | its convenient, particularly for developers on C/C++ projects | 02:55 |
| twb | Why? Because they have huge codebases? | 02:55 |
| lifeless | because their build products are expensive | 02:55 |
| twb | (I mean: why C/C++ especially) | 02:55 |
| twb | You mean their compilation process is really slow? | 02:56 |
| lifeless | yes | 02:56 |
| twb | Yeah, I can see that. | 02:56 |
| spiv | right, they want to be able to recycle .o files etc if at all possible. | 02:56 |
| twb | distcc :-) | 02:56 |
| lifeless | 9.8K revisions to go. | 02:57 |
| lifeless | hg fast-export. Slowness. cry. | 02:57 |
| lifeless | mind you, I have a 117G fast import to test out next | 02:57 |
| twb | At least it works :-/ | 02:57 |
| lifeless | darcs doesn't? | 02:57 |
| twb | darcs fast-import of a git repo was busted on a mkdir -p-type operation, last time I checked. | 02:58 |
| lifeless | [darcs fast export I mean] | 02:58 |
| twb | IIRC darcs fast-export gets more love, because most people want to leave darcs, not join it :-) | 02:58 |
| twb | Because you start out with a small project that Darcs works well for, and you end up with a big project that Darcs is too slow for. | 02:58 |
| lifeless | yeah we had that problem | 02:58 |
| lifeless | took about 18 months to properly solve it | 02:59 |
| twb | But also I use hg at work and it is super annoying. | 02:59 |
| lifeless | still don't have as lovable patch workflow as darcs does | 02:59 |
| AfC | I have a bzr-svn created branch of GTK. It took about 2 days to make. Blogged about it back then, maintained it publicly. It even caused Jc2k to take an interest and set up bzr mirrors etc. | 03:11 |
| AfC | Meanwhile, GNOME (abetted by the very same Jc2k, traitor) switched to Git. Idiots. But I am now wondering: how to I talk to it? | 03:11 |
| AfC | Can I somehow leverage the existing bzr-svn created revisions? Or do I use some bzr-git plugin (which launchpad claims to use, not sure if I believe it). | 03:12 |
| AfC | Should I use git natively to clone & transfer their repo down, and then use something local disk to convert to bzr? | 03:12 |
| lifeless | you can use bzr-git | 03:15 |
| lifeless | same author as bzr-svn :) | 03:15 |
| lifeless | and yes, lp uses bzr-git | 03:15 |
| lifeless | no, you can't use the existing bzr-svn import of gtk, because there isn't a guaranteed correspondence with what they imported to git | 03:15 |
| poolie | spm, lifeless, how about we try the conversion/switchover again now? | 03:17 |
| poolie | (or after lunch) | 03:18 |
| spm | poolie: I can kick off the check now, but am also debugging an LS issue -so somewhat distracted; but should be cool. | 03:18 |
| lifeless | I'd rather not have you distracted :) | 03:19 |
| lifeless | I think we should do it | 03:19 |
| lifeless | when do you think you'll be ours, body n soul? | 03:19 |
| spm | lifeless: hrmmm. say 2-3 weeks? we can schedule something in then? :-P | 03:20 |
| * lifeless wedges 3pm into spm's schedule | 03:20 | |
| lifeless | (earlier would be better..) | 03:20 |
| spm | seriously tho - I'll rebuild a new bzr from trunk. kick off the make check - and go from there? after lunch basically. | 03:21 |
| lifeless | spm: make sure you have rev 4666 or newer | 03:21 |
| AfC | lifeless: ok, so I guess I'll throw away the bzr-svn branches. That's mostly what I wanted to know. | 03:21 |
| lifeless | AfC: yup | 03:21 |
| spm | lifeless: actually 3pm is a horrible time - I can send Dee off alone; but that's usually when I leg stretch by fetching the boy back from school | 03:21 |
| AfC | bzr-git is bundled now, right | 03:21 |
| AfC | er, is anything bundled now? | 03:22 |
| lifeless | the windows installer bundles a bunch | 03:23 |
| lifeless | we haven't progressed on bundling elsewhere | 03:23 |
| AfC | I thought we were going to batteries included everything useful. Hm. | 03:24 |
| lifeless | ETIME | 03:31 |
| poolie | etime? | 03:33 |
| poolie | afc, igc is working on bundling some more stuff on windows | 03:33 |
| poolie | we're not going to block 2.0 on bundling more things | 03:33 |
| AfC | poolie: ah | 03:34 |
| poolie | we may do that after 2.0 actually freezes though= | 03:34 |
| poolie | that will make it easier to change the packaging | 03:34 |
| AfC | poolie: well, I'm glad to hear Canonical employees are spending time on making Linux better. | 03:34 |
| poolie | spm, lifeless, how about just after you get back from trawling the playgrounds? :) | 03:35 |
| spm | poolie: rob trawls playgrounds!??!!? | 03:35 |
| poolie | no, only you | 03:35 |
| spm | damn. so much for an unsubtle attempt at sliding out of that one ;-) | 03:36 |
| fullermd | ... I knew we were going for a friendly VCS and all, but I didn't know we were aiming at _friendly_... | 03:36 |
| poolie | but seriously | 03:36 |
| poolie | ping us then? | 03:36 |
| spm | poolie: will do | 03:37 |
| === thumper-afk is now known as thumper | ||
| spm | lifeless: bzr revno 4667 from dev is built/live and working | 03:46 |
| lifeless | jml: poolie: Want to lunch tomorrow; talk LP bug handling & the like? | 03:46 |
| lifeless | poolie: I has book for you | 03:46 |
| spm | poolie: if you're ok with it; I'll stop bzr pqm now; and start a make check on the tree with the 4667 revno I just built | 03:46 |
| spm | (and a new backup -> assumed) | 03:46 |
| lifeless | spm: doit | 03:46 |
| spm | 'kk | 03:47 |
| spm | ...../bzr check in progress | 03:49 |
| === abentley1 is now known as abentley | ||
| * spm afk for lunch | 03:49 | |
| jam | lifeless: this line doesn't look right to me: | 03:56 |
| jam | + for record in self.iter_pack_records: | 03:56 |
| jam | since I can't find 'iter_pack_records' and if I did find it, I would expect it to be a callable iter_pack_records(): | 03:56 |
| lifeless | jam: its assigned to self | 03:57 |
| lifeless | its a generator we keep using | 03:58 |
| lifeless | look at seed_state() | 03:58 |
| lifeless | jam: I got your call; thanks! where is your current branch? | 03:58 |
| jam | lp:///~jameinel/bzr/2.1b1-pack-on-the-fly | 03:59 |
| poolie | spm, that's great | 04:01 |
| poolie | lifeless: that's ok | 04:01 |
| poolie | i mean lunch tomorrow is ok | 04:01 |
| lifeless | great | 04:01 |
| jam | lifeless: yeah, I called poolie because you didn't answer your phone :) | 04:01 |
| lifeless | jam: was in the other room - sorry | 04:02 |
| lifeless | and at max ring volume its stupidly quiet | 04:02 |
| jam | not a big deal, it got through to you | 04:02 |
| lifeless | 125087/133780 | 04:02 |
| lifeless | nearly there | 04:02 |
| lifeless | 119G | 04:02 |
| AfC | Jelmer's dulwich page http://samba.org/~jelmer/dulwich/ claims a GPG signature for 0.3.3 but the .asc there is not being groked by by `gpg`. Nor by `file`. | 04:03 |
| AfC | It is certainly not ASCII, whatever it is | 04:03 |
| lifeless | file dulwich-0.3.2.tar.gz.asc | 04:04 |
| lifeless | dulwich-0.3.2.tar.gz.asc: PGP signature | 04:04 |
| AfC | um | 04:04 |
| AfC | oh, weird. Epiphany has saved a gzip of it. Is that a transfer-compression miss-thing | 04:05 |
| lifeless | yes | 04:05 |
| lifeless | also note that his link is to 3.2 | 04:05 |
| lifeless | gpg dulwich-0.3.3.tar.gz.asc | 04:06 |
| lifeless | gpg: Signature made Fri 24 Jul 2009 04:29:25 EST using RSA key ID D729A457 | 04:06 |
| lifeless | wget -S http://samba.org/~jelmer/dulwich/dulwich-0.3.3.tar.gz.asc | 04:06 |
| AfC | ah, that's also not helping | 04:06 |
| lifeless | Content-Type: text/plain | 04:06 |
| AfC | jelmer: ping? You've got a copy & paste bug | 04:06 |
| AfC | Meanwhile, /me uses trusty wget | 04:06 |
| lifeless | I'd need a network trace to say. Could be either server misconfig or epiphany damage. | 04:07 |
| AfC | ok, good signature now, thanks | 04:07 |
| AfC | lifeless: I think it's probably Epiphany trying to be too clever | 04:08 |
| lifeless | possibly | 04:08 |
| AfC | lifeless: jelmer's c&p bug didn't help either. Nothing like multiple simultaneous unrelated problems. | 04:08 |
| lifeless | equally possibvly is the server claiming content encoding | 04:08 |
| AfC | server claimed "Vary: Accept-Encoding" ... I wonder if that faked out Epiphany's "Download..." | 04:09 |
| AfC | something for another time. Thanks Robert | 04:09 |
| lifeless | yeah, it means that it will give wget and epiphany different answers :) | 04:10 |
| lifeless | I bet there was a content encoding on the response you got, and the interaction fails | 04:10 |
| * AfC grumbles ... Galeon did such things correctly. I need to go bitch at someone, I think | 04:13 | |
| lifeless | debug first | 04:13 |
| lifeless | :) | 04:13 |
| lifeless | get the right culprit | 04:13 |
| AfC | You kidding? Random drive-by bitching is much more fun. Especially when innocent bystanders get caught in the cross-fire. | 04:15 |
| fullermd | Innocent? They're on the internet. | 04:15 |
| AfC | I lost my innocence long before the internet. | 04:16 |
| AfC | Oh, I hate my life | 04:17 |
| AfC | bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade' | 04:17 |
| AfC | after 2 hours of work trying to get bzr-git to work. | 04:18 |
| poolie | hm, probably a mismatched version of the plugin | 04:18 |
| AfC | poolie: yeah, I'd branched trunk. I'm gonna try branching from the newest sounding release tag | 04:19 |
| poolie | i don't *think* we changed that recently though | 04:19 |
| AfC | I just packaged released dulwich, so I guess I'll use released bzr-git to go with it | 04:20 |
| AfC | Bah. No, that didn't help | 04:21 |
| AfC | So, I'm trying | 04:21 |
| AfC | $ bzr info git://git.gnome.org/gtk+ | 04:21 |
| AfC | prepatory to trying | 04:22 |
| poolie | spiv, tell me about bug 406687? | 04:22 |
| ubottu | Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687 | 04:22 |
| AfC | $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/ | 04:22 |
| poolie | git+ssh:// maybe? | 04:22 |
| AfC | [though I guess that's optional, I'm not pushing at the moment, just like to have r+w since I do] | 04:22 |
| AfC | poolie: probably - but git:// needs to work first | 04:23 |
| Talden | Does anyone know if bzr-svn should support local access (file:///...) to Subversion 1.6 repositories? I get a 'not a branch' exception suggesting no. | 04:23 |
| AfC | poolie: c.f. http://www.gtk.org/download.html | 04:23 |
| fullermd | I thought bzr-git only got along with local access. | 04:23 |
| fullermd | Or maybe I'm thinking of bzr-hg. | 04:23 |
| poolie | afc, and what happens? just that typeerror? | 04:23 |
| AfC | yes | 04:23 |
| poolie | fullermd: i think there is at least some remote support now | 04:23 |
| AfC | poolie: ^ | 04:23 |
| spiv | poolie: the partial fix (ensure revisions have corresponding inventories present, and that those inventories + any parent inventories have chk root entries present) is with PQM (although I think PQM is paused for the 2a migration?). | 04:23 |
| poolie | ah it may be | 04:24 |
| AfC | [off topic, but: | 04:24 |
| AfC | $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/ | 04:24 |
| AfC | gives | 04:24 |
| poolie | and the next step is to check that the whole inventory closure is there? | 04:24 |
| spiv | poolie: the more comprehensive fix is underway, I think I have working code for checking all necessary chk records are present, but I want to write some tests now to prove that :) | 04:24 |
| AfC | bzr: ERROR: Unsupported protocol for url "ssh://afcowie@git.gnome.org/git/gtk+/": bzr supports bzr+ssh to operate over ssh, use "bzr+ssh://afcowie@git.gnome.org/git/gtk+/". | 04:24 |
| AfC | which would be WRONG :)] | 04:24 |
| poolie | how about opening a new bug for that larger fix? | 04:25 |
| poolie | afc, right, i guess you really mean 'dwim over ssh' | 04:25 |
| lifeless | poolie: well I filed this bug for the larger fix | 04:25 |
| spiv | poolie: and then having found all relevant chk pages, then extract the relevant text versions from that and check they are present too. | 04:25 |
| AfC | but keep in mind Linus's avowed hatred of git+ssh:// so most of the time people will be using ssh:// | 04:25 |
| AfC | poolie: yeah | 04:25 |
| poolie | though that's actually a bit hard to implement | 04:25 |
| lifeless | poolie: we never did get to talking about this yesterday. | 04:25 |
| AfC | poolie: I think bzr should dwim too | 04:25 |
| AfC | :) | 04:25 |
| AfC | poolie: ie s/bzr+ssh/ssh/ | 04:25 |
| AfC | but anyway | 04:26 |
| spiv | As lifeless says the existing bug is for the larger fix, although that is a bit inconvenient because it limits how much tracking we can do in LP. | 04:26 |
| AfC | yeah, | 04:26 |
| AfC | $ bzr info git+ssh://afcowie@git.gnome.org/git/gtk+/ | 04:26 |
| spiv | Although filing a smaller bug now and immediately marking it fix committed feels like cheating :) | 04:26 |
| AfC | gives the bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade' crash | 04:26 |
| lifeless | poolie: I contend that we should fix the larger issue now, without necessarily delaying 2.0 | 04:26 |
| poolie | that's fine | 04:26 |
| lifeless | poolie: because its defensive | 04:26 |
| poolie | i'm just asking or suggesting that there be one bug per incremental step | 04:27 |
| poolie | opinions may vary on whether this is clarity or overhead :) | 04:27 |
| lifeless | AfC: its bzr-git that you'd need to tweak/change not dulwich :) | 04:27 |
| spiv | Yeah, at least when one of those steps is targetted to a milestone and others aren't... | 04:27 |
| lifeless | poolie: I think that when it helps us its clarity. | 04:27 |
| AfC | lifeless: good to know. I had to package & install to system to use it, me not being a sophisticated pythonista | 04:27 |
| poolie | exactly | 04:28 |
| AfC | lifeless: but meanwhile bzr-git is crashing, so I give up. | 04:28 |
| AfC | Data point: git clone gtk+ took 25m17s | 04:28 |
| lifeless | AfC: at least file a bug on bzr-git. I bet you're pulling from some place jelmer has forgotten about | 04:28 |
| poolie | afc, please put the traceback in a bzr-igt bug | 04:28 |
| lifeless | AfC: what url did you get bzr-git from | 04:28 |
| poolie | spiv, so what did the news or merge for the branch you have sent say? | 04:29 |
| AfC | lifeless: um... info says http://bazaar.launchpad.net/~bzr/bzr-git/trunk/ and history says ... lp:bzr-git | 04:29 |
| poolie | 'partially fix ....'? | 04:29 |
| AfC | lifeless, poolie: ok, will do later today. | 04:29 |
| spiv | poolie: right | 04:29 |
| spiv | +* Prevent some kinds of incomplete data from being committed to a 2a | 04:29 |
| spiv | + repository, such as revisions without inventories or inventories without | 04:29 |
| spiv | + chk_bytes root records. Partially fixes #406687. | 04:29 |
| spiv | + (Andrew Bennetts) | 04:29 |
| poolie | i guess the operational change i'm suggesting is to never say (in news, merges, proposals) "partially fix blah" | 04:29 |
| poolie | split it and then totally fix the split off bit | 04:30 |
| poolie | if you see what i mean | 04:30 |
| spiv | Yeah. | 04:30 |
| lifeless | poolie: so, this may mean larger landings | 04:30 |
| * SamB_XP wonders why you people are all green | 04:30 | |
| lifeless | or more landings that do things without references to bugs. | 04:30 |
| fullermd | SamB_XP: It's not easy. | 04:31 |
| SamB_XP | *groan* | 04:31 |
| spiv | I'm not sure if that will *always* fit well, but maybe I'm wrong. I'm happy to try that out. | 04:31 |
| SamB_XP | I don't know what you mean | 04:31 |
| lifeless | AfC: and what revno do you have? | 04:31 |
| spiv | (I'm sure it will often work well, though) | 04:31 |
| poolie | as (i think) Orwell said, 'break any of these rules rather than doing something barbarous' | 04:32 |
| lifeless | I would like to understand the concern about what spiv did though | 04:32 |
| AfC | lifeless: trunk 603. 0.4.1 whatever the tag said | 04:32 |
| spiv | Right. I think "make separate bugs rather than write 'partially fixes'" is a good default policy. | 04:32 |
| spiv | What should I do about the landing that's in-flight? Just let it be, I suppose. | 04:33 |
| lifeless | AfC: what does bzr help plugins show | 04:33 |
| lifeless | spiv: pqm is disabeld | 04:33 |
| lifeless | we're upgrading to 2a | 04:33 |
| SamB_XP | hoooray! | 04:33 |
| spiv | lifeless: right, which means the flight-time is going to be quite long :) | 04:33 |
| fullermd | Gotta be a way to plug that into the VCS/airlines thing :p | 04:34 |
| lifeless | AfC: it should list a directory that bzr-dif is being loaded from | 04:34 |
| lifeless | bzr-git, I mean | 04:34 |
| lifeless | I kindof think we should have one bug filed per thing a user reports | 04:35 |
| poolie | lifeless: am i right in thinking you agreed with robert on what to do with recombining groups, bug 402652? | 04:35 |
| ubottu | Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652 | 04:35 |
| AfC | lifeless: you meant `bzr plugins -v` I assume. It says 0.4.1, from the .bazaar/plugins symlink, which points to my 0.4.1 branch | 04:35 |
| lifeless | and not use the bug tracker as a proxy for merges; merges are merges. | 04:35 |
| spm | lifeless: poolie: the check came back with "found error:Internal check failed: revno does not match len(mainline) 1649 != 1674" istr vila suggested just running reconcile would fix same? | 04:35 |
| poolie | i think that's right | 04:35 |
| spiv | poolie: lifeless usually agrees with himself ;) | 04:35 |
| * AfC thinks we should discuss bzr-git another time. I think you guys are doing something more important and I don't want to distract you | 04:36 | |
| poolie | about the check | 04:36 |
| lifeless | spm: run bzr reconcile in that dir; it will say it fixes the branch, then hit ctrl-c | 04:36 |
| spm | lifeless: oki | 04:36 |
| lifeless | AfC: yeah bug filing time | 04:36 |
| poolie | lifeless: about whether issues are change requests or user issues or what; um, it's a very open question but i think in this case the balance is wrong | 04:37 |
| lifeless | specifically, I don't see any tension between saying you're working towards a bug and landing some code | 04:37 |
| poolie | i'm not saying strictly 1:1 bug with changes | 04:37 |
| poolie | me either | 04:37 |
| poolie | however, he's done more than that here | 04:37 |
| lifeless | if its because you want to untarget the bug; I'd just untarget the bug. *My* intent when I filed it was that the larger fix is what we'd do for 2.0 | 04:37 |
| poolie | it's not | 04:37 |
| lifeless | ok | 04:38 |
| spiv | poolie: I'm going to file a new bug for the smaller fix; link to it from the existing bug, and replace the 'partially fixes <old bug>' in that NEWS entry with the new bug. | 04:38 |
| poolie | i do think it's possible in principle that we could decide only part of the change was needed | 04:38 |
| poolie | and in that case having them separate would help | 04:38 |
| poolie | cool | 04:38 |
| spiv | In an ideal world, splitting (and joining) bugs would be an easy operation (and create no confusion). | 04:39 |
| lifeless | so, I think the confusion is that 'work' and 'requests' are different here. AFAICT its only the desire to be able to talk about the work later, to either show we did it, or to show someone that suffered it and wants to know if there is a fux, that drives the idea of assigning a new label | 04:41 |
| poolie | lifeless: so, re bug 402652? | 04:42 |
| ubottu | Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652 | 04:42 |
| lifeless | poolie: we're working on it | 04:42 |
| SamB_XP | lifeless: or show *what* you fixed | 04:42 |
| poolie | lifeless: i basically agree; maybe i'm putting more value on those things than you do | 04:42 |
| lifeless | SamB_XP: the merge log does that | 04:42 |
| spm | lifeless: interesting. never said it was fixing. just did it's thing. "Reconciling branch file:///home/pqm/archives/thelove/bzr/0.8/ ;;revision_history ok.;; Reconciling repository file:///home/pqm/archives/thelove/bzr/ ;; Reconciliation complete" | 04:50 |
| lifeless | spm: well, goodo | 04:50 |
| lifeless | next | 04:50 |
| spm | check again? | 04:50 |
| lifeless | yes | 04:51 |
| lifeless | we cycle until check is clean | 04:51 |
| spm | wfm as a plan | 04:51 |
| lifeless | but let us know when its not to think about how to handle | 04:51 |
| lifeless | there are some things we might say 'meh' to | 04:51 |
| lifeless | check and reconcile are not ideal yet. | 04:51 |
| spm | 'k will do | 04:52 |
| spm | ie play it safe; anything unusual pls to be asking loudly kthx | 04:52 |
| lifeless | 7.5K to go | 04:53 |
| jml | lifeless, lunch tomorrow sounds good. | 05:12 |
| spm | lifeless: poolie: check still going. the previous check fail has passed this time (post reconcile) so looking good | 05:30 |
| RenatoSilva | I have a speific code that I think was introuced in some revision? Anything better than bzr log -p | grep -n 'code' to find the revision? | 05:31 |
| lifeless | bzr search some things from the code | 05:31 |
| fullermd | I'd find a rev that has it and use annotate, if the former is easy. | 05:34 |
| RenatoSilva | lifeless: how to make it search? | 05:35 |
| lifeless | RenatoSilva: via the bzr-search plugin, however it sounds like you don't have that, so log -p | grep is fine too | 05:36 |
| RenatoSilva | ok | 05:38 |
| spm | lifeless: poolie: that check has finished. no issues. https://pastebin.canonical.com/21777/ I'm about to be afkingfor the school run, so can continue when I get back? | 05:43 |
| lifeless | ok | 05:44 |
| lifeless | bah 4 hours to go on this export. sheese | 05:47 |
| fullermd | And you're already a bunch of hours ahead of most of the world. | 05:49 |
| lifeless | fullermd: 121G of fast-export stream so far | 05:49 |
| lifeless | fullermd: from 1 .7G hg repo | 05:49 |
| fullermd | Better your IO subsystem than mine. | 05:50 |
| bob2 | your poor laptop | 05:52 |
| fullermd | So, is this thing you're doing with spm now theoretically the Big Switch, or just testing in anticipation of? | 05:52 |
| jml | I really want to read and summarize the test speed thread | 05:53 |
| jml | sadly, I have other things to do | 05:53 |
| lifeless | bob2: this is on my i7 | 05:53 |
| lifeless | bob2: my laptop ould have run out of disk. | 05:54 |
| lifeless | fullermd: Biggus Switchus | 05:54 |
| lifeless | jml: heh. Trials n Tribunals. | 05:54 |
| jml | yeah | 05:54 |
| lifeless | there is a time to talk, and a time to do. | 05:54 |
| lifeless | jam: your branch has tests. | 06:01 |
| lifeless | jam: I'm not sure whats missing, looking at it | 06:01 |
| jam | lifeless: well, the fact that the test passes with "if len(factories) == 1" rather than "if manager.check_is_utilized()" is one of them | 06:15 |
| jam | so we don't have a test that insert_record_stream uses the right functionality | 06:15 |
| jam | anyway, /me => bed | 06:15 |
| * vila waves at jam ! | 06:17 | |
| fullermd | Bed? The sun isn't even up yet! | 06:19 |
| AfC | I am SO pleased to read that poolie's "heart rate" is going up, and that he's getting "excited". | 06:21 |
| spm | poolie: lifeless: shall we continue? | 06:32 |
| lifeless | AfC: ? | 06:40 |
| lifeless | spm: yes | 06:40 |
| spm | lifeless: cool. so next step: I assume is the bzr upgrade --2a ? | 06:41 |
| AfC | lifeless: From: Martin Pool <mbp@canonical.com> Message-ID: <e01316480909022053n78bb7eci7a98f981a5b77b97@mail.gmail.com> Subject: Re: metronome mail for Bazaar 2.0 and 1.18 | 06:42 |
| poolie | spm, hi | 06:56 |
| poolie | afc, i can't tell if that was sarcasm or not | 06:57 |
| spm | poolie: heyo, so dunno how much of the above you saw? but we're all ready to roll. | 06:57 |
| AfC | poolie: it was humour, yes. | 06:57 |
| poolie | iow you're not pleased? | 06:57 |
| poolie | spm, i think i saw all of it, and the next step would be to do the upgrade | 06:58 |
| poolie | so let's do it! | 06:58 |
| AfC | poolie: I thought it was funny. What comes next after "increasing excitement"? By the time you guys release, you're going to be talking about "orgasms", I'm sure. | 06:58 |
| poolie | ok | 06:58 |
| poolie | it was meant to be a bit funny | 06:58 |
| AfC | then good! | 06:59 |
| spm | poolie: 'kk. I'll give you all 10 seconds to cross fingers, arms legs, then I hit enter. starting.... now. | 06:59 |
| poolie | a dryer way to say it is that when there's more release-related activity we should say more about it | 06:59 |
| AfC | poolie: dry, yes. Interesting, no | 06:59 |
| spm | hahahahahaha. bzr: ERROR: File exists: u'/home/pqm/archives/thelove/bzr/backup.bzr/': [Errno 17] File exists: '/home/pqm/archives/thelove/bzr/backup.bzr/' | 07:00 |
| AfC | You know the Bazaar hackers are working too hard when humorous replies to funny emails fall flat. | 07:00 |
| poolie | drier* | 07:00 |
| poolie | :) | 07:00 |
| AfC | You guys really need to teach bzr not to repeat itself. | 07:00 |
| poolie | no, just checking | 07:00 |
| AfC | yup | 07:00 |
| poolie | i think in a sense releases, or the process of releasing, should be boring | 07:00 |
| poolie | you should get more satisfaction from improving things and then getting it out is just a natural consequence | 07:01 |
| spm | speaking from an operational side, couldn't agree more - releases should be boring. | 07:01 |
| AfC | poolie: "should be boring". That makes it official. You're now a corporate worker slave | 07:01 |
| poolie | it's like being excited about getting to a concert on time, not the performance itself | 07:01 |
| === tro|| is now known as tro | ||
| SamB_XP_ | the release should be exciting | 07:02 |
| SamB_XP_ | ... to the users who get to use all the cool new doodads | 07:03 |
| poolie | btw that error, i agree it looks lame | 07:03 |
| poolie | it's actually python doing it, and the behaviour varies per python release | 07:04 |
| poolie | so while we could eliminate it, it's nontrivial to do it correctly | 07:04 |
| poolie | and make sure it's shown just once on all versions | 07:04 |
| poolie | it would make a good personal-pleasure bug | 07:04 |
| lifeless | spm: so bzr upgrade --2a in the root | 07:08 |
| lifeless | spm: and in each branch | 07:08 |
| lifeless | poolie: are you doing escudero ? | 07:08 |
| lifeless | poolie: or is spm, or its been forgotten ? | 07:08 |
| spm | err. poss the latter. | 07:09 |
| lifeless | spm: there is a repo on escudero needs the same treatment | 07:09 |
| lifeless | spm: and we'll have to do the 1.17/1.18/2.0 branches on lp too | 07:09 |
| spm | lifeless: flip side, I have almost no access on esco itself - only via balleny | 07:09 |
| lifeless | ok | 07:10 |
| lifeless | I'll ssh in | 07:10 |
| spm | rephrase - can login look around; but nothing special | 07:10 |
| lifeless | 1.17, it'll do | 07:11 |
| lifeless | bzr check under way | 07:11 |
| lifeless | spm: now, for bzr.dev, we're going to change where it points at at the same time | 07:12 |
| spm | lifeless: oki | 07:13 |
| igc1 | any windows users online right now? | 07:18 |
| === igc1 is now known as igc | ||
| poolie | hi igc1 | 07:18 |
| igc | hi poolie | 07:18 |
| lifeless | lamont: did you upload subunit to karmic this morning? If so thanks :) | 07:20 |
| lifeless | lamont: I was going to release 0.0.2 before asking for a FFe :> | 07:20 |
| === tro|| is now known as tro | ||
| spm | lifeless: what's the preferred way of u/ging the required branches on LP? I assume we can take a branch from the newly upgraded (or use the existing subdir in the shared repo) and delete old/push that? or? | 07:27 |
| lifeless | ok its a little complex. | 07:27 |
| lifeless | uhm | 07:27 |
| spm | heh | 07:27 |
| lifeless | there's a guide | 07:27 |
| lifeless | but lets toss that out the window | 07:27 |
| lifeless | is bzr.dev upgraded ? | 07:28 |
| spm | <smash? | 07:28 |
| spm | not yet. | 07:28 |
| spm | Transferring revisions 9600/27302 | 07:28 |
| lifeless | when it is, do the following. | 07:28 |
| lifeless | bzr init --2a lp:~launchpad-pqm/bzr/bzr.dev [adjust the user if I got it wrong] | 07:28 |
| spm | 'k | 07:28 |
| lifeless | then bzr push the bzr.dev branch there using --remember so it sticks | 07:29 |
| lifeless | thats probably a Good Time to change the bzr pqm config too, for bzr.dev | 07:29 |
| spm | this is from ~/archives/thelove/bzr ? vs one of the subdirs | 07:29 |
| spm | right | 07:29 |
| lifeless | the subdir +trunk | 07:29 |
| spm | ah. righto | 07:29 |
| lifeless | then | 07:30 |
| lifeless | in the bzr project on lp | 07:30 |
| lifeless | change the branch for the trunk/bzr.dev series to point at this new branch. | 07:30 |
| spm | k | 07:30 |
| lifeless | now, if we're lucky, we can just delete the other launchpad-pqm owned branches and repush them. | 07:31 |
| lifeless | if we're unlucky we can either rename-and-push, or we can bzr upgrade --2a <URL> them | 07:31 |
| spm | but the key is the bzr.dev; right. makes sense. stacked on I assume. | 07:31 |
| spm | ew | 07:32 |
| lifeless | yes, for all new things pushed | 07:32 |
| spm | right | 07:32 |
| lifeless | once escudero is upgraded, all the old branches will suddenly start crying | 07:32 |
| * spm fetches a box of tissues | 07:32 | |
| lifeless | elephant tears | 07:33 |
| spm | 3 boxes of tissues | 07:33 |
| vila | hi all | 07:33 |
| spm | hey vila | 07:33 |
| * vila forgot to unmark as away... | 07:33 | |
| poolie | spm, we're talking about it... | 07:35 |
| spm | poolie: np | 07:36 |
| spiv | lifeless: I wonder how changing the branches on lp like that will interact with the merge proposals against the existing lp:bzr? | 07:37 |
| vila | spiv: stop beating the dead horse :) | 07:38 |
| lifeless | spiv: they will need to be resubmitted | 07:38 |
| vila | I'm 95% sure we need to resubmit them anyway after having been upgraded | 07:38 |
| SamB_XP_ | spiv: they'll suddenly be against lp:~bzr/bzr/???, I guess | 07:38 |
| spiv | Ok. That's a shame (but not a show-stopper). | 07:39 |
| vila | spiv: The way I see it is that we're changing the devlopment focus, so lp:bzr gets a new semantic, mp were done against the old one, *something* has to be done, I don't think this can be automated | 07:40 |
| lifeless | vila: oh it would merge ok | 07:44 |
| lifeless | vila: but the trunk url config is changing | 07:44 |
| === tro|| is now known as tro | ||
| vila | mmm | 07:45 |
| spm | Transferring revisions 11100/27302 <== this may take a while I'm thinking... | 07:46 |
| lifeless | spm: no | 07:46 |
| lifeless | spm: time stands stil | 07:46 |
| lifeless | l | 07:46 |
| lifeless | l | 07:46 |
| lifeless | l | 07:46 |
| lifeless | l | 07:46 |
| spm | heh | 07:46 |
| lifeless | I'm setting up a new 1.9 format mirror of bzr.dev to become the new trunk for all the old stacked branches | 07:47 |
| lifeless | poolie and I just discussed some of the merits of different ways of tackling this | 07:47 |
| lifeless | we're going to keep them working, for now at least. | 07:47 |
| spm | oki | 07:47 |
| lifeless | 4.5K to go | 07:48 |
| jml | oh, that reminds me | 07:48 |
| lifeless | .oOo. | 07:48 |
| jml | (the ohloh LP enlistment is moving very very slowly) | 07:48 |
| spm | I'm going to afk and grab an early dinner (curry made last night - should be nicely improved by now). if you need me in a hurry, ring my mobile, or home phone. | 07:48 |
| lifeless | jml: \o/ | 07:49 |
| lifeless | jml: where is it up to ? | 07:49 |
| jml | lifeless, 8248/66451 | 07:49 |
| lifeless | spm: I'm basically EOD'd: when that completes please SMS me or wave furiously or something. | 07:50 |
| jml | lifeless, it was at ~6500 this morning | 07:50 |
| lifeless | jml: holy swear words bat man | 07:50 |
| lifeless | _what_ command are they running | 07:50 |
| jml | lifeless, Launchpad doesn't track that, you'd have to ask them :) | 07:51 |
| lifeless | jml: how does launchpad track the enlistment ? | 07:51 |
| jml | lifeless, it doesn't. my data is from, https://www.ohloh.net/p/launchpad/enlistments | 07:51 |
| lifeless | jml: k | 07:52 |
| SamB_XP_ | ooh! how did you ever get access to that information! | 07:52 |
| jml | lifeless, I guess someone who knows bzr could maybe derive the command from the apache log | 07:52 |
| SamB_XP_ | </fake-awe> | 07:52 |
| lifeless | SamB_XP_: its on the page :P | 07:52 |
| spiv | http://www.ohloh.net/forums/3491/topics/3685 claims they run "bzr log --long --show-id --forward --include-merges -r 1.. -v" | 07:56 |
| spm | lifeless: oki, will sms | 08:01 |
| lifeless | poolie: I believe there is a cron job donig 'bzr update' in the bzr.dev tree on escudero.. what account is that under - can you cancel it ? | 08:01 |
| poolie | i don't recall, but yes i can | 08:01 |
| poolie | .. find out and cancel it | 08:01 |
| lifeless | spm: ~bzr-pqm is the user I think | 08:02 |
| lifeless | spm: has it converted yet ? | 08:02 |
| spm | lifeless: yeah, that sounds more sane | 08:02 |
| spm | nope. 14000 | 08:02 |
| poolie | done | 08:02 |
| spm | just over half way | 08:02 |
| spm | lifeless: so guestimating.... about another hour. | 08:03 |
| poolie | spm: to upgrade? that seems slower than it was for me | 08:03 |
| lifeless | poolie: much older machine | 08:03 |
| spm | poolie: about 2 hours in total. | 08:03 |
| lifeless | balleny is uhm 3.5? 4? years old | 08:04 |
| spm | AMD Opteron(tm) Processor 250 | 08:04 |
| spm | single cpu, no cores. | 08:04 |
| lifeless | 1 core ! | 08:04 |
| spm | almost as old as me and vila! | 08:04 |
| spiv | no cores would explain slowness ;) | 08:05 |
| jml | does bzr actually use more than one core for upgrading? | 08:05 |
| lifeless | jml: no, but other things can | 08:05 |
| spm | anyways - back to cooking poppadums - and trying not to eat them all as they emerge. | 08:05 |
| vila | spm: you mean me *+* you :) | 08:06 |
| vila | spiv: right, they finally found the worst way ever to use bzr log :-) | 08:07 |
| jml | vila, you should comment on the thread :) | 08:08 |
| * jml was quite impressed with ohloh's friendliness and willingness to actually do stuff to support bzr better. | 08:09 | |
| SamB_XP_ | jml: well, there sure were a lot of people asking for bzr support! | 08:13 |
| SamB_XP_ | ... how does one get a CPU with no cores ? | 08:14 |
| SamB_XP_ | ... what does it *do*? | 08:14 |
| LarstiQ | jml: when was this? they ignored bzr for a year or so | 08:15 |
| SamB_XP_ | LarstiQ: I think the proper term is "were swamped" | 08:16 |
| SamB_XP_ | not "ignored bzr" | 08:16 |
| LarstiQ | SamB_XP_: ok, let me rephrase that. Despite a lot of people asking for support, and some offering help, I have never seen a public statement from ohloh on the issue. | 08:17 |
| LarstiQ | but maybe I don't care about their site enough | 08:17 |
| SamB_XP_ | there aren't very many of them! | 08:18 |
| LarstiQ | SamB_XP_: not enough to reply on the forum thread? | 08:19 |
| jml | LarstiQ, well, they've supported bzr for a while | 08:21 |
| jml | LarstiQ, but they replied quite quickly to my thread about Launchpad open sourcing | 08:21 |
| bialix | bonjour vila | 08:25 |
| vila | hello Alexander | 08:25 |
| LarstiQ | jml: cool | 08:25 |
| LarstiQ | jml: yeah, my disappointment is from the period before they supported bzr | 08:25 |
| * LarstiQ lost interest on the way | 08:26 | |
| jml | heh | 08:26 |
| bialix | morning knows better than night, I've decided that much simpler for me will be to write special hidden command which invokes get_user/password methods for me | 08:26 |
| * jml likes that expression | 08:27 | |
| vila | *commands* ? Wow, I'm lost here, I really need to read the code you will write... | 08:27 |
| * vila upgraded 1/3 hosts, fully checked | 08:28 | |
| bialix | vila: ^, so I won't need to lookj for real svn repo to test | 08:28 |
| bialix | vila: ? | 08:28 |
| vila | And you will have automated tests then ? | 08:28 |
| vila | Oh I got it ! | 08:28 |
| bialix | vila: heh, you're really out of context | 08:28 |
| lifeless | jml: it saddens me to hear that lp doesn't use pqm's test facilities at all :( | 08:28 |
| bialix | vila: :-P | 08:29 |
| bialix | no automated tests yet | 08:29 |
| vila | you will fake the svn repo behavior to ensure you can catch get_password/get_username ? | 08:29 |
| bialix | yes!!! | 08:29 |
| vila | bialix: but if you do that you're '' close to have automated tests ! | 08:29 |
| jml | lifeless, well, it's much more a function of our terrible test suite rather than anything in pqm | 08:29 |
| bialix | vila: I need to test that our SubprocessUIFactory in QBzr works OK for get_user et al methods for subprocessed bzr command | 08:30 |
| lifeless | jml: I'm still sad though | 08:30 |
| jml | lifeless, sorry :( | 08:30 |
| bialix | vila: it will be pain to properly write automated test | 08:30 |
| vila | You already suffered for not having an automated test for that ! | 08:30 |
| jml | lifeless, tbh, it doesn't sadden me, it just annoys me constantly. I really miss the days when someone trying to land a failing branch meant that only that person had to care about the failed attempt. | 08:31 |
| vila | Not writing it now, when you got the concept clearly in your head... is a bit like not making the one missing step to get there :-/ | 08:31 |
| jml | (whether that person was me or someone else) | 08:31 |
| vila | you want to write an hidden command, I say this hidden command can be part of your test framework | 08:31 |
| vila | bialix: Where will you write that command otherwise ? In a plugin ? | 08:32 |
| lifeless | jml: I hear you have Influence now | 08:33 |
| jml | lifeless, I don't have magical powers though. | 08:34 |
| lifeless | jml: cow | 08:34 |
| lifeless | [have you seen apt cow?] | 08:34 |
| jml | lifeless, my influence on this kind of thing is the same as it always was. | 08:34 |
| lifeless | I know | 08:34 |
| jml | [I have!] | 08:34 |
| lifeless | I was teasing | 08:34 |
| lifeless | 4K revisions to go | 08:35 |
| lifeless | and then I can put my new memory in! | 08:35 |
| jml | lifeless, if we could test and land a new LP branch in under 15 minutes, I would argue for switching back to PQM | 08:35 |
| bialix | vila: one day I bribe you to help properly set up test suite for QBzr based on QTest | 08:35 |
| bialix | :-P | 08:35 |
| vila | :-D | 08:36 |
| bialix | testing GUI is not easy | 08:36 |
| jml | lifeless, but as it stands, I think the current (flawed) system is better than the massive queues we had with a traditional PQM set up. | 08:36 |
| vila | bialix: I hope to meet you at one bzr sprint one day.... | 08:36 |
| bialix | me too | 08:36 |
| lifeless | jml: me too | 08:36 |
| vila | bialix: 'testing GUI is not easy' that's why you should test at lower levels :-P | 08:37 |
| bialix | vila: rrrrrrr | 08:37 |
| bialix | vila: but I need test high level interactions! | 08:37 |
| vila | bialix: You can't get robust walls if you don't use robust bricks | 08:38 |
| bialix | vila: when you will have a 5 minutes to relax, look into qbzr/liv/subprocess.py SubprocessUIFactory | 08:38 |
| spm | 19000/27302 ... getting there.... | 08:38 |
| vila | Start with robust bricks and your walls will be solid enough even if not tested | 08:38 |
| bialix | vila: I'm amazed | 08:39 |
| vila | the opposite is a dream, a nice dream, but a dream anyway | 08:39 |
| vila | Obviously my english is not good to explain that :-/ | 08:39 |
| bialix | I like dreams | 08:39 |
| vila | Obviously my english is not good enough (not are my typing abilities :) to explain that :-/ | 08:39 |
| bialix | and my french even worse than your english | 08:39 |
| vila | want to hear my russian ? | 08:39 |
| vila | :) | 08:40 |
| vila | na gavariu pa ruski | 08:40 |
| bialix | :-) :-) | 08:40 |
| bialix | LOL | 08:40 |
| bialix | ne | 08:40 |
| vila | bialix: exactly ! :-D | 08:40 |
| vila | 3 words and 1 mistake already ! | 08:40 |
| bialix | your russian is better and better every time! :-D | 08:41 |
| === JaredWigmore is now known as JaredW | ||
| bialix | vila: writing tests is good, and like them, but for QBzr sometimes is much faster to write bugfix w/o tests | 08:43 |
| vila | bialix: so, why don't you just copy/paste get_password in subprocess.py (and update whatever corresponding code that handles GETPASS) ? | 08:43 |
| vila | bialix: It's always faster to write the bugfix without tests | 08:43 |
| bialix | and because I have not infinite amount of free time I have to choose between bugfix w/o test and no bugfix at all | 08:43 |
| vila | What takes more time it to reproduce the bug so you can diagnose it to be able to write the bugfix :) | 08:44 |
| vila | And if you write down how long you spend on the respective tasks... at one point you realize that writing tests saves a lot of time. And if it doesn't... you have to learn how to write better tests :) | 08:45 |
| bialix | to reproduce THAT bug I need to find such svn repo | 08:45 |
| vila | bialix: wrong | 08:45 |
| bialix | vila: I hear you! I hear you! I believe you! But I have reason to do otherwise | 08:46 |
| vila | You know you need to implement get_username, do that, test it, ask the people encountering the bug to check your fix :) | 08:46 |
| bialix | more: I share your belief in tests | 08:46 |
| vila | if you tested it correctly, you're 99% sure they will come back to tell you: "Great ! It works ! Thanks !" | 08:46 |
| bialix | aaaaaah! | 08:47 |
| bialix | vila! | 08:47 |
| poolie | hello, vila, bialix | 08:47 |
| vila | hye poolie | 08:47 |
| bialix | hello | 08:47 |
| bialix | poolie: I have a question about traceback generator code | 08:51 |
| bialix | poolie: I have a question about traceback report generator code | 08:51 |
| poolie | sure | 08:51 |
| bialix | https://bugs.launchpad.net/bugs/423221 | 08:51 |
| ubottu | Launchpad bug 423221 in qbzr "External diff no longer works" [Undecided,New] | 08:51 |
| bialix | poolie: ^, if you llok at the bug report generated by bzr you'll see there is bencoded dict passed as argument | 08:52 |
| poolie | bialix: sorry i don't see the connection? | 08:52 |
| * igc dinner | 08:52 | |
| bialix | err, bencoded list | 08:52 |
| poolie | oh, right | 08:52 |
| bialix | what can I do to decode it for easy understanding? | 08:52 |
| bialix | some hook into trace.py maybe? | 08:53 |
| bialix | any advice? | 08:53 |
| poolie | so | 08:53 |
| poolie | i guess this is obvious, but it's not the trace code that's doing the encoding | 08:53 |
| poolie | it's the qsubprocess or whatever | 08:53 |
| bialix | no | 08:53 |
| bialix | yes, this string generated by qbzr internals | 08:53 |
| bialix | I just think for me will be nice if qbzr devs see not only raw string but also decoded list | 08:55 |
| poolie | from the command line you can say something like this: | 08:55 |
| poolie | python -c 'import sys;from bzrlib.util.bencode import bdecode;print bdecode(sys.stdin.read())' | 08:55 |
| poolie | but i can see how putting it into the bug report would make something easier | 08:55 |
| poolie | how about if | 08:55 |
| bialix | yes, exactly | 08:55 |
| poolie | we add another line of output that's called something like decoded_arguments | 08:56 |
| poolie | and we call a function in trace.py that can optionally return different more readable arguments | 08:56 |
| poolie | then it can look for a --bencode option? | 08:56 |
| bialix | that will be great | 08:56 |
| bialix | maybe just provide hook point? | 08:56 |
| poolie | right, then the plugins could hook it | 08:56 |
| bialix | may I file this feature request as bug report? | 08:57 |
| poolie | of course | 08:57 |
| poolie | um | 08:57 |
| bialix | thanks | 08:57 |
| bialix | um? | 08:57 |
| poolie | my only concern would be, at the time we've already crashed | 08:57 |
| poolie | the more code we call, the more likely it is that something else will go wrong | 08:58 |
| bialix | yep, this is a problem | 08:58 |
| poolie | for instance if one of the plugins isn't installed properly, calling this hook might break something more | 08:58 |
| bialix | heh | 08:58 |
| poolie | and prevent us getting a traceback at all | 08:58 |
| poolie | that probably wouldn't happen in most cases | 08:58 |
| bialix | I'll ask gary for his mind | 08:58 |
| poolie | i think that string is fairly readable once you know a bit about it | 08:59 |
| poolie | about bencode | 08:59 |
| poolie | we should test if apport will work ok on windows | 08:59 |
| bialix | because we have special code to show qbzr tracebacks in GUI dialog, maybe we just override it | 08:59 |
| bialix | poolie: apport on windows? you want real testing? any pointers on how to setup it? | 09:00 |
| bialix | igc working on better installer | 09:00 |
| bialix | because I'm fan of bzr.exe I need apport working with bzr.exe | 09:00 |
| poolie | i think that if you just install it from https://launchpad.net/apport | 09:01 |
| poolie | then bzr will try to use it | 09:01 |
| poolie | then do something like 'bzr assert-fail' or make it crash in some other way | 09:01 |
| bialix | at which level bzr hook into apport? | 09:01 |
| poolie | when we want to report an error, we try to import appotr | 09:02 |
| poolie | apport* | 09:02 |
| poolie | and if we can, we use that to write the error to a file, rather than printing it ourselves | 09:02 |
| bialix | is it invoked as subprocess? | 09:02 |
| poolie | no, just as a python library | 09:02 |
| bialix | this won't work for bzr.exe | 09:02 |
| bialix | it should be bundled inside it | 09:02 |
| poolie | oh? | 09:02 |
| poolie | right, but we could bundle another python library into it? | 09:03 |
| bialix | or there is should be plugin to setup sys.path | 09:03 |
| bialix | bundle into bzr.exe? yes, but it makes it a bit bigger | 09:03 |
| poolie | that's true | 09:03 |
| vila | lifeless: one more mp vote where you forgot the leading space | 09:04 |
| poolie | it's probably not very big | 09:04 |
| bialix | how big apport is? | 09:04 |
| lifeless | vila: someday it will listen to me | 09:04 |
| bialix | I'll look if I can wrap apport into plugin | 09:04 |
| vila | LOL | 09:04 |
| poolie | 332k | 09:04 |
| poolie | we could cut out only the bits we need, which is probably less than half | 09:05 |
| bialix | well, py2exe is very good in tracking actual import dependencies so it will pick only required modules | 09:05 |
| bialix | but py2exe don;t know about lazy_imports | 09:05 |
| poolie | in this case it's not lazy | 09:06 |
| bialix | igc: can you look into bundling apport into bzr.exe? just installing it in your python will be enough | 09:06 |
| poolie | it's imported inside the function that uses it, but py2exe should be able to handle that | 09:06 |
| bialix | poolie: so, what I should expect when apport is working? | 09:07 |
| bialix | how I can see it actually working ok? | 09:07 |
| poolie | try 'bzr assert-fail' and rather than a traceback it should tell you the location of a crash file | 09:10 |
| * bialix get lp:approt | 09:12 | |
| bialix | poolie: bzr: ERROR: Unable to create symlink 'data/icons/scalable/mimetypes/text-x-apport.svg' on this platform | 09:12 |
| spm | poolie: fyi: Transferring revisions 20000/27302 | 09:12 |
| bialix | poolie: I'm unable to get apport sources | 09:12 |
| lifeless | 3K to go, 126G | 09:14 |
| lifeless | you can do itm 128G FTW | 09:14 |
| poolie | bialix :/ | 09:14 |
| poolie | there is a tarball | 09:14 |
| poolie | sorry about the symlink bug | 09:14 |
| poolie | i tried it under wine and it didn't work well | 09:14 |
| poolie | i have to go now, i may be back later | 09:14 |
| vila | spm: just checking pqm mail submissions are disabled right ? | 09:15 |
| poolie | i'm not sure why eithr | 09:15 |
| bialix | C:\work\Bazaar\zzz\apport\apport-1.8>setup.py bdist_wininst -d. | 09:15 |
| bialix | To build Apport you need https://launchpad.net/python-distutils-extra | 09:15 |
| bialix | huh? | 09:15 |
| bialix | poolie: no way for apport today, too much obstacles | 09:15 |
| vila | dependencies.... salt of the earth :-/ | 09:16 |
| bialix | poolie: and you say that installing windows dev tools is tricky! | 09:16 |
| bialix | comparing to apport it was easy | 09:16 |
| spm | vila: aye | 09:17 |
| vila | bialix: that's certainly a *big* difference between windows and linux and linux devs tends to be used to automatic depedency tracking: you want a tool, you install it, if dependencies are needed, they are taken care of automagically | 09:17 |
| spm | vila: we've still got a ways to go on the 2a upgrade. so the pqm processing is disabled | 09:17 |
| vila | spm: sure, I understand that, | 09:17 |
| vila | fully | 09:17 |
| spm | cool :-) | 09:18 |
| vila | upgrading my various dev hosts too just to shake things a bit more | 09:18 |
| bialix | vila: I see how easy it may look, but I prefer to understand what's going on | 09:18 |
| vila | by doing it at the same time | 09:18 |
| bialix | this one reason why I hate eggs | 09:18 |
| vila | bialix: but you don't need to care anymore once you use a distro where people's work is to make damn sure the dependencies are right | 09:19 |
| bialix | I don;t want to talk about it | 09:19 |
| * bialix bbl maybe | 09:20 | |
| vila | ok, np | 09:20 |
| vila | james_w: ping, strangeness here: https://code.edge.launchpad.net/~debian-bazaar/bzr-gtk/debian the last commit is by you and says 'works with bzr-1.19' ?? and lp can access it since 2009-09-01 | 09:29 |
| spm | Transferring revisions 24700/27302 | 09:51 |
| spm | thumb twiddling excitement :-) | 09:52 |
| jml | :D | 09:54 |
| jml | hmm. | 09:55 |
| jml | spm, by my calculations, ohloh's import of Launchpad should be finished by the 13th. | 09:55 |
| spm | jml: which year? | 09:58 |
| jml | my bad. | 09:58 |
| jml | spm, I meant to say, "the 13th century AD" | 09:58 |
| spm | when the universe wraps around again? | 09:59 |
| lifeless | 2.2K | 09:59 |
| lifeless | 127G | 09:59 |
| lifeless | jam: I won't get to the group combining patch today | 10:02 |
| james_w | vila: the branches were upgraded | 10:03 |
| james_w | vila: the commit message is a typo | 10:03 |
| vila | james_w: ok, which branches upgraded to what ? | 10:04 |
| james_w | debian branches to 2a | 10:04 |
| vila | oh great | 10:05 |
| lifeless | igc: does fast-import get multiple branches? | 10:06 |
| vila | james_w: so the lp branch should be re-created ? | 10:06 |
| james_w | I guess | 10:07 |
| james_w | it looks like LP doesn't like mirrored branches being upgraded | 10:07 |
| lifeless | james_w: it should remirror | 10:07 |
| lifeless | jml: ^ | 10:08 |
| jml | what | 10:08 |
| jml | yes, it should. | 10:08 |
| vila | remirror as opposed to ? | 10:08 |
| lifeless | vila: error ? :P | 10:08 |
| lifeless | vila: lp is meant to delete its copy and start over when the format doesn't match | 10:09 |
| vila | lol, no, the question was, was is lp doing right now ? | 10:09 |
| vila | ha ok | 10:09 |
| jml | my understanding of the code is that it should be doing that. | 10:11 |
| jml | what's actually happening? | 10:15 |
| vila | jml: lp says This branch may be out of date, because Launchpad has not been able to access it since 2009-09-01 | 10:16 |
| vila | https://code.edge.launchpad.net/~debian-bazaar/bzr-gtk/debian | 10:16 |
| jml | hmm | 10:17 |
| lifeless | now, I filed a bug about it /not doing/ this, but mwhudson/jml seemed convinced it was only a scanner issue at the time. | 10:17 |
| spm | poolie: lifeless: 'repository converted' | 10:18 |
| lifeless | ok, push trunk to ~bzr-pqm/2.0 | 10:19 |
| lifeless | ^bzr | 10:19 |
| lifeless | bleh | 10:19 |
| lifeless | spm: I fail. | 10:19 |
| spm | is cool - I get the gist :-) | 10:19 |
| jml | hmm | 10:19 |
| lifeless | spm: to ..bzr.dev | 10:19 |
| lifeless | spm: not to 2.0 | 10:19 |
| lifeless | trunk is bzr.dev :P | 10:20 |
| spm | ahh. no didn't get that gist. right. lemme run the cmd line past you first. one sec... | 10:20 |
| jml | so, while I don't dispute that the bug is occurring | 10:21 |
| jml | and that it's probably in the puller | 10:21 |
| jml | if you look at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/annotate/head%3A/lib/lp/codehosting/puller/worker.py and grep for 'format', it's hard to see what's wrong | 10:21 |
| spm | lifeless: ~/archives/thelove/bzr/+trunk$ ...<funky_path>/bzr push --remember bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr.dev | 10:21 |
| lifeless | no | 10:22 |
| lifeless | ... bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev | 10:22 |
| spm | gah. missed that. sorry. | 10:22 |
| spm | lifeless: ? https://pastebin.canonical.com/21784/ | 10:23 |
| lifeless | https://edge.launchpad.net/bzr is kinda ugly @ 800 wide | 10:23 |
| lifeless | thats good | 10:24 |
| lifeless | now do it again | 10:24 |
| spm | oh? ok. | 10:24 |
| spm | well <....> me. is working. | 10:24 |
| lifeless | stacking | 10:24 |
| lifeless | fails | 10:24 |
| lifeless | then exists so doesn't alter the setting | 10:25 |
| lifeless | iz UI bug | 10:25 |
| spm | ah. perhasps a nicer error message would help? :-D | 10:25 |
| spm | snap :-) | 10:25 |
| lifeless | yes | 10:25 |
| lifeless | critical, not blocker | 10:25 |
| spm | right | 10:25 |
| spm | kinda like being a windows sysadmin again. if something fails, try it exactly the same way a 2nd or third time. usually works then. :-D | 10:26 |
| lifeless | oh don't say that | 10:26 |
| lifeless | thats nasssty | 10:26 |
| spm | Created new branch. | 10:26 |
| spm | nasty. maybe. accurate tho.... /cynical | 10:26 |
| lifeless | ok | 10:26 |
| lifeless | now I'm going to change trunk to point at the 2a format branch | 10:27 |
| spm | 'kk, and likewise am modifying trunk in pqm config | 10:27 |
| lifeless | ok, escudero's bzr.dev is now a branch alias | 10:28 |
| spm | publish_to=bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev | 10:28 |
| spm | published_at=http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev | 10:28 |
| spm | sane ^^? | 10:28 |
| lifeless | is that analagous to 1.18? | 10:29 |
| spm | copy'n'past'nmodify, yup | 10:29 |
| lifeless | spelling etc optional | 10:29 |
| lifeless | kk | 10:29 |
| lifeless | doit | 10:29 |
| spm | ZZ | 10:29 |
| lifeless | now, to update the 2.0 bzr-pqm branch | 10:29 |
| lifeless | want to do this the easy way? | 10:29 |
| spm | 7.30pm? whadda reckon? :-) | 10:30 |
| lifeless | got lftp there? | 10:30 |
| spm | errrr... | 10:30 |
| lifeless | [it does sftp] | 10:30 |
| spm | yes! | 10:30 |
| vila | spm: not windows related (if it fails, try again), I used to do that in GCOS days | 10:30 |
| lifeless | lftp sftp://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 | 10:30 |
| lifeless | rm -rf .bzr [in lftp speak,w hich I forget offhand] | 10:30 |
| Spabby__ | hi guys is there a yum repo that has a newer version of bzr than the epel one please? | 10:31 |
| lifeless | \o/ 128G fastexport stream from netbeans hg repo | 10:31 |
| spm | lifeless: this'd be in the 2.0 dir I assume? or move existing to one side and create a new. | 10:31 |
| spm | on nm. I'm being dense. | 10:32 |
| lifeless | spm: we're deleting the 1.9 format history on lp; replacing it with the updated master copy. | 10:32 |
| lifeless | Spabby__: http://bazaar-vcs.org/Download | 10:32 |
| lifeless | has a yum repo listed | 10:32 |
| Spabby__ | yes | 10:32 |
| spm | right - yeah - worked that out. was thinking in terms of copy down. | 10:32 |
| Spabby__ | but the version is 1.3.1 | 10:32 |
| Spabby__ | which is really old | 10:33 |
| Spabby__ | it's the epel one I mentioned in my initial question | 10:33 |
| lifeless | Spabby__: oh, I did'nt know that | 10:33 |
| spm | lifeless: so. .bzr rm'd from baz.lp.n/~bzr-pqm/bzr/2.0 | 10:33 |
| lifeless | I'm sorry, I don't know know of others | 10:33 |
| lifeless | spm: cd to the 2.0 branch; push it, with --use-existing-dir | 10:33 |
| spm | lifeless: to confirm: .../thelove/bzr/2.0$ /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr push --use-existing-dir | 10:35 |
| lifeless | spm: also, remember the 2.0 review team change? | 10:35 |
| lifeless | we need to do that here as well | 10:35 |
| lifeless | spm: ack | 10:35 |
| lifeless | to the bzr.dev branch | 10:35 |
| spm | lifeless: vaguely - that was in the LP ui from memory? change to ~bzr-devs or similar | 10:35 |
| lifeless | bzr-core | 10:36 |
| lifeless | yes | 10:36 |
| spm | right | 10:36 |
| lifeless | https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev | 10:36 |
| spm | Using saved push location: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0/ | 10:36 |
| spm | Source branch format does not support stacking, using format: | 10:36 |
| spm | Branch format 7 | 10:36 |
| spm | Using default stacking branch /~bzr-pqm/bzr/bzr.dev at lp-45207760:///~bzr-pqm/bzr | 10:36 |
| spm | Created new stacked branch referring to /~bzr-pqm/bzr/bzr.dev. | 10:36 |
| spm | looks good | 10:36 |
| spm | lifeless: review team changed to bzr-core | 10:37 |
| lifeless | spm: ok | 10:38 |
| lifeless | spm: repeat the 2.0 process on the other existing bzr-pqm branches | 10:38 |
| lifeless | I think thats 1.17 and 1.18 | 10:38 |
| lifeless | unlock pqm | 10:38 |
| spm | phew. for a minute there I thought you meant 0.1 to 1.18 :-) | 10:38 |
| lifeless | and thank you, We all appreciate your doing this late :) | 10:39 |
| lifeless | I'll write up docs to the list | 10:39 |
| spm | ta | 10:39 |
| vila | spm: I second that: T-h-a-n-k y-o-u | 10:39 |
| lifeless | its kinda snappy in loggerhead now | 10:40 |
| lifeless | :P | 10:40 |
| spm | 1.17 done (damn this is faster the 2nd time) | 10:40 |
| lifeless | spm: yupyup | 10:40 |
| spm | 1.18 done | 10:41 |
| spm | so if ya'll feeling brave, we can re-enable PQM then? | 10:41 |
| lifeless | DoIt | 10:42 |
| vila | https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0 still says Repository format: Packs 6 (uses btree indexes, requires bzr 1.9) | 10:42 |
| vila | https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev is fine | 10:42 |
| lifeless | vila: check http with bzr client | 10:43 |
| spm | bzr pqm, re-enabled | 10:44 |
| lifeless | super | 10:44 |
| vila | lifeless: you're right, bzr client reports the right format, the web site lags ? | 10:45 |
| lifeless | vila: scanner bug | 10:46 |
| spm | cache? | 10:46 |
| spm | shouldn't be replication lag. that's < 5 secs | 10:46 |
| lifeless | spm: metadata cache in lp | 10:46 |
| spm | figures | 10:46 |
| lifeless | spm: its coherency bug | 10:46 |
| lifeless | filed, queued. | 10:46 |
| vila | I'd say data in some table extracted from .bzr and either not updated or not refreshed (I hope it's the later) | 10:46 |
| spm | lifeless: I look forward to your patch for same tomorrow morning. :-P | 10:46 |
| lifeless | spm: filed some months ago | 10:47 |
| spm | anyways. anything else at this stage? leave it for vila to break overnight? | 10:47 |
| vila | on my way to submit a simple patch to bzr.dev :-D | 10:48 |
| spm | hahahahahah | 10:48 |
| vila | 1) upgrade the local integration branch :) | 10:49 |
| vila | 0) upgrade the bounded stacked branch | 10:49 |
| lifeless | 1.5K to go | 10:55 |
| spm | oki, outa here. night all. | 10:55 |
| lifeless | thanks again. | 10:56 |
| alex_morelli | a good day to all | 11:04 |
| alex_morelli | I need some help with a OSX 10.4 installation: even after installing Python 2.6.2, the installer complains of an incompatible version and asks me to install Python 2.6 | 11:05 |
| alex_morelli | do I need to reboot after installing Python? | 11:06 |
| === lifeless changed the topic of #bzr to: Bazaar version control system | bzr.dev is in 2a format | 1.18 final released soon | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| alex_morelli | someone can help me? | 11:13 |
| lifeless | alex_morelli: I would sorry, but I am really not here :( | 11:16 |
| lifeless | vila: ^ | 11:16 |
| lifeless | any idfeas? | 11:17 |
| jelmer | fetch from hg into bzr seems to somewhat work now with current versions of bzr and hg | 11:53 |
| james_w | \o/ | 11:57 |
| lvh | yay, finally we can throw hg away | 11:57 |
| jml | jelmer, grats | 12:10 |
| lifeless | 133304/133780, 129G | 12:12 |
| lifeless | so very very close | 12:12 |
| lifeless | 138378654414 - netbeans fastexport | 12:45 |
| lifeless | igc: ^ | 12:45 |
| ronny | lvh: evil ... | 13:30 |
| lvh | ronny: haha | 13:32 |
| ronny | well, i guess i'll have to do a sprint on hg-bzr next week | 13:32 |
| lvh | don't mind me, I'm just trolling | 13:33 |
| ronny | hmm, bzr is starting to spit into my waters (with all those abstractions) | 13:33 |
| ronny | but i dont see me wanting to use bzr's api anytime soon | 13:34 |
| ronny | brb, food | 13:34 |
| lvh | ronny: that's okay, I feel very much the same way about hg's api | 13:35 |
| lvh | oh wait, I'm not supposed to use hg's python api because it's not public :-) | 13:35 |
| jelmer | lvh: mercurial's API doesn't have the abstractions that bzr's API has | 13:35 |
| jelmer | lvh: for better or worse | 13:35 |
| lvh | jelmer: I'm mostly talking about hg.ui.ui() | 13:36 |
| lvh | err, mercurial.ui.ui() probably :-) | 13:36 |
| lvh | jelmer: every time I moan about it people tell me "yeah stop using that the api is private" | 13:36 |
| lvh | jelmer: my reaction is to stop using hg, I like public apis | 13:36 |
| jelmer | ahh | 13:36 |
| jelmer | the API stability of mercurial is also a bit of a concern for bzr-hg :-/ | 13:37 |
| lvh | which API | 13:37 |
| lvh | there is no API! | 13:37 |
| lvh | jelmer: I ran into the same problem when making a version updater for git repos | 13:38 |
| lvh | jelmer: eg inspect the current repo state -> produce __version__="foo" in __init__.py | 13:38 |
| lvh | jelmer: then I noticed that hg seems to assume that you are always working interactively | 13:38 |
| lvh | jelmer: and there is no real way aorund that | 13:38 |
| lvh | jelmer: (But I'm not really sure -- the original/core dev told me to use os.system and parse the output, so I stopped using hg) | 13:39 |
| jelmer | lvh: well, there is an API, just no guarantees about its stability | 13:39 |
| lvh | jelmer: yeah, I dont think that really counts :-) | 13:40 |
| lvh | jelmer: but sure -- there's an API, and you're not supposed to use it | 13:40 |
| ronny | jelmer: i like the fact that its a unstable api | 13:54 |
| ronny | jelmer: all the suckage slowly goes away, and doesnt has to stay for centuries | 13:54 |
| jelmer | functionality is always deprecated first in Bazaar before it is removed several versions later | 13:55 |
| jelmer | that's good for API users, but a bit of a burden on developers | 13:55 |
| ronny | well, bzr is kind of __huge__ and has stuff spead out in unpleasant ways | 13:56 |
| ronny | i still dont understand bzrs actual repo formats, for hg it was like read 3 files, done including backward compatibilities | 13:57 |
| ronny | for bzr i lost interest after dozens of files, tonns of inheritance and pain | 14:00 |
| eLBati | ciao | 14:25 |
| eLBati | using env var http_proxy , is it possible to use username and pass for authenticate to proxy? | 14:27 |
| vila | eLBati: yes | 14:27 |
| vila | eLBati: Did you try ? | 14:27 |
| eLBati | vila: yes, but I get a connection time out | 14:28 |
| eLBati | doing bzr branch | 14:28 |
| vila | eLBati: use -Dhttp and look at your .bzr.log to check | 14:29 |
| vila | eLBati: if you don't understand the http headers I canhelp but be aware that your credentials will appear there | 14:29 |
| eLBati | vila: thanks | 14:30 |
| eLBati | vila: http://pastebin.com/m30eee712 | 14:41 |
| eLBati | someone is not responding | 14:41 |
| vila | you didn't specify -Dhttp :-/ | 14:42 |
| vila | oh, wait, you're trying to use a lp: url, that's a known bug beehind proxies :-// | 14:42 |
| eLBati | yes, lp | 14:42 |
| vila | you need to use the resolved URLs instead, | 14:42 |
| eLBati | ah | 14:43 |
| vila | what os/versions are you using ? | 14:43 |
| eLBati | ubuntu 8.04 | 14:43 |
| eLBati | how could I resolve URL? | 14:44 |
| eLBati | (lp:openobject-doc) | 14:45 |
| vila | hmm, by going to the web site, | 14:45 |
| vila | lp:openobject-doc is bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/ | 14:46 |
| vila | or http:// instead of bzr+ssh:// | 14:46 |
| vila | eLBati: https://code.launchpad.net/openobject-doc is the entry point, | 14:47 |
| vila | from there you get access to all existing branches in the project and by clicking on each one, you'll get a page with all the urls you need | 14:48 |
| eLBati | thanks vila | 14:49 |
| vila | eLBati: and the relevant bug is #186920 | 14:50 |
| ronny | btw, is there anything for bzr comparable to submodules/subrepos/externals? | 14:50 |
| vila | ronny: nested trees, but it's still a work in progress | 14:50 |
| NET||abuse | hey bzr folks,,, i have a site i downloaded from the server, put under bzr version control on my local drive, developed new pages for, and now I need to publish to the webserver again. is there a good way to push the code up to a server from my local machine? | 15:00 |
| vxnick | NET||abuse: try bzr-upload | 15:04 |
| === kiko-afk is now known as kiko | ||
| === sabdfl1 is now known as sabdfl | ||
| lvh | hi! | 15:12 |
| lvh | what's the easiest way to see the revision id's of the last past commits? | 15:12 |
| lvh | I've tried olive-gtk but that doesnt seem to show me the revision ids. | 15:13 |
| lvh | bzr log -l 10 or so? | 15:13 |
| lvh | Yay, that shows revnos :-) | 15:14 |
| jelmer | lvh: --show-ids | 15:26 |
| eLBati | vila: http://pastebin.com/m6b8d36eb | 15:41 |
| eLBati | with easy_install I can authenticate | 15:41 |
| === cprov is now known as cprov-lunch | ||
| vila | lvh: bzr log -l 10 --show-ids | 15:42 |
| vila | eLBati: bzr-1.3.1, right, I'm 99% sure this has been fixed in recent bzr version, you may want to add the bzr-ppa repository to your software sources | 15:43 |
| eLBati | I have 1.3.1 | 15:44 |
| vila | yes, I can see that, let me find the bug | 15:45 |
| vila | eLBati: in the mean time, look here for instructions on how to get the latest stable release of bzr: https://launchpad.net/~bzr/+archive/ppa | 15:46 |
| gioele | hello | 15:52 |
| vila | eLBati: bug #366107 | 15:52 |
| ubottu | Launchpad bug 366107 in bzr "Bazaar should attempt Basic authentication if HTTP server offers NTLM" [Undecided,Fix released] https://launchpad.net/bugs/366107 | 15:52 |
| gioele | vila: hi, thank you for fixing bug #423331 ;) | 15:53 |
| ubottu | Launchpad bug 423331 in bzr-upload "Don't upload additional files in / but in another directory" [Wishlist,Fix released] https://launchpad.net/bugs/423331 | 15:53 |
| vila | so you need at least 1.15 to get the fix | 15:53 |
| vila | gioele: my pleasure, your description made it obvious and I felt bad that I didn't realize what Alfredo was talking about :-/ | 15:54 |
| eLBati | thank you vila | 15:54 |
| vila | eLBati: Note that using the ppa bzr archive is how we distribute the upgrades to all Ubuntu releases | 15:55 |
| gioele | vila: one last thing: what is supposed syntax of that option? Is a simple "upload_revid_location = foo" in branch.conf is 'foo' interpreted relative to the path given on the command line? | 15:56 |
| vila | so adding it to your software sources is the best way to get future updates as they become available | 15:56 |
| eLBati | vila: ;) | 15:56 |
| jam | btw, morning vila | 15:57 |
| vila | gioele: yes, relative to the remote path, if you find a clearer way (thatn the README attempt) to explain that, patches are welcome :-) | 15:57 |
| vila | mornign jam !! | 15:57 |
| vila | Was about to say: Always happy to help (tm), so you were in my thoughts :) | 15:58 |
| gioele | vila: oops, I didn't see the README file in the bzr-upload source code :( | 15:58 |
| vila | gioele: no worries, it means we need a better way to communicate the documentation (and since the targeted audience is web developers, may be one of them will help generate some doc :) Or look into the effort led by igc to generate the html doc from the plugins... I need to check that | 15:59 |
| NET||abuse | hmm, i've never pulled code down from launchpad before. | 15:59 |
| NET||abuse | how do i get the plugin? | 15:59 |
| vila | NET||abuse: which one ? | 16:00 |
| NET||abuse | i'm looking to use bzr-upload | 16:00 |
| NET||abuse | so they didn't have direct downloads on the site, just list the trunk in the code section. | 16:00 |
| vila | cd ~/.bazaar/plugins (create the dir if it doesn't exist) bzr branch lp:bzr-upload upload | 16:00 |
| vila | yeah, the plugin authors are bit lazy about distributions... | 16:01 |
| NET||abuse | so i suppose i have to pull code down, and sure why not, i'm getting into bzr and git a bit more than svn these days. | 16:02 |
| NET||abuse | i seem to be mixing up both from project to project, bit confusing at times. | 16:02 |
| NET||abuse | that lp alias, can i make my own and assign it to my own launchpad installation, was looking to host my own launchpad on my webserver for the various projects i'll be buliding over the coming months/years ;) | 16:03 |
| NET||abuse | and if it was a straight forward way to do things, it would win out as the choice over git and trac | 16:03 |
| NET||abuse | i've already setup svn trac before for 2 projects on my site, but trac doesn't make multiple projects a very straight forward proposition. | 16:04 |
| NET||abuse | launchpad i imagine would make things simple, as the decisions on how to sperate out projects would be kinda made for you, and launchpad on the ubuntu side works well :) | 16:04 |
| vila | NET||abuse: try #launchpad if you want support for that, I'm sure they'll be happy to help (tm too) :) | 16:04 |
| NET||abuse | tm? | 16:05 |
| vila | Trade Mark | 16:05 |
| gioele | vila: mini-bug report for bzr-upload (a these lazy users, always requesting things): #423770 | 16:05 |
| gioele | very low priority, filed just in case somebody else need it | 16:05 |
| vila | ubottu: wake up bot, tell us about bug #423770 please | 16:05 |
| ubottu | Launchpad bug 423770 in bzr-upload "Don't quit with "bzr: ERROR: Failure" when upload_revid_location is a directory" [Undecided,New] https://launchpad.net/bugs/423770 | 16:05 |
| vila | thanks | 16:05 |
| vila | gioele: thanks for filing it, there is already a FIXME in the code about more tests with invalid paths, that one is certainly the most obvious error one can make... I even wonder if I didn't make a mistake in giving full control instead of just providing the directory.... | 16:07 |
| vila | NET||abuse: oh, and if you use karmic, bzr-upload is already packaged there | 16:08 |
| kfogel | Anyone know how to turn a revision id (such as "launchpad@pqm.canonical.com-20090806060602-gqejhnxt9rbj5cr1" into a loggerhead URL? I don't see a way to get to a revision by raw ID through loggerhead; only by revision number (which for various reasons isn't ideal here, as we have different branches with the same rev ids having different rev numbers). | 16:10 |
| * kfogel supplies the closing paren missing in the middle of the above: ")" | 16:10 | |
| NET||abuse | vila, no, jaunty till full release | 16:10 |
| NET||abuse | when's karmic out? | 16:10 |
| vila | 9.10 ? :D | 16:11 |
| NET||abuse | yeh, i woulda thought this month | 16:11 |
| NET||abuse | just havn't seen any kind of promotion for it. | 16:11 |
| gioele | vila: I promise that if you change that option I will not complain :) | 16:11 |
| vila | :-) | 16:11 |
| gioele | now, back to *using* bzr-upload | 16:12 |
| gioele | thank you again | 16:12 |
| gioele | bye | 16:12 |
| kfogel | jelmer: any idea how to turn a revision id (such as "launchpad@pqm.canonical.com-20090806060602-gqejhnxt9rbj5cr1") into a loggerhead URL? I don't see a way to get to a revision by raw ID through loggerhead; only by revision number (which for various reasons isn't ideal here, as we have different branches with the same rev ids having different rev numbers). | 16:27 |
| jelmer | kfogel: hi | 16:28 |
| jelmer | kfogel: It was possible IIRC it is possible, since I remember there was a bug in that code at some point. Let me check.. | 16:28 |
| jelmer | s/it is possible// | 16:29 |
| kfogel | jelmer: that'd be great; I didn't see anything in loggerhead UI for it, but could have missed it. | 16:30 |
| james_w | kfogel: I think you can do it by crafting the URLs | 16:33 |
| james_w | I assume they still work, the "prettier" ones are the ones that are presented though | 16:33 |
| jelmer | kfogel: it seems just using the revid instead of the revno works | 16:33 |
| jelmer | kfogel: http://HOST/PATH/revision/REVID | 16:34 |
| kfogel | jelmer: wow, I never even thought to try that | 16:34 |
| * kfogel looks | 16:34 | |
| kfogel | jelmer: yup | 16:35 |
| kfogel | jelmer: thanks for the tip | 16:35 |
| jam | kfogel: the only thing to watch out for is crazy escaping... | 16:53 |
| kfogel | jam: ? | 16:53 |
| kfogel | jam: the only funny thing in there is an "@" sign, right? | 16:53 |
| jam | kfogel: well revision ids *can* have more than just '@' in them | 16:54 |
| jam | Though if they are just bazaar ones, they probably won't | 16:54 |
| kfogel | jam: ? is there a known charset I can depend on? | 16:54 |
| jam | svn ids, for example, have ':' | 16:54 |
| kfogel | jam: this is just bazaar | 16:54 |
| jam | I think some may have '/' | 16:54 |
| jam | etc | 16:54 |
| jam | Technically revision ids are UTF-8 strings, but I think the underlying issue is that cherrpy does crazy stuff with things like '/' | 16:55 |
| jam | anyway, it probably won't matter for what you are doing | 16:55 |
| kfogel | they're link targets in a wiki | 16:55 |
| jam | I just seem to recall that one of the primary reasons to move away from cherrypy was because it had lossy escaping | 16:55 |
| jam | kfogel: so *if* a link works for you, then it is probably good for all eternity. | 16:56 |
| jam | :) | 16:56 |
| kfogel | jam: comforting | 16:56 |
| jam | I'm just not confirming that all mappings from revid will actually lookup the exact content in loggerhead | 16:57 |
| jam | though if this is normal bzr operations, it should work ok | 16:57 |
| phinze | oof, okay so my plugin now successfully detects if a tip change touches anything inside a given path, happy times there... | 17:00 |
| phinze | now i need to figure out how to check if a given change to a protected path was made by a merge with an authorized branch | 17:00 |
| kfogel | jam: what would be a non-normal operation? I mean, these are all commits... | 17:01 |
| jam | kfogel: importing from svn | 17:02 |
| jam | importing from git | 17:02 |
| jam | someone hand-crafting revision-ids to do something special | 17:02 |
| jam | kfogel: not things you will likely encounter, depending on what that wiki page is for | 17:02 |
| kfogel | jam: https://dev.launchpad.net/Contributions/Draft | 17:03 |
| jam | kfogel: I wouldn't expect that to ever be a problem. Especially if you are always linking the pqm revision | 17:04 |
| jam | although by the same token, if you are linking to launchpad's trunk, I would expect that linking by revno would *also* always just work | 17:05 |
| kfogel | jam: I am, although I have a separate ambition to remove PQM from the picture and just have us committing directly. | 17:05 |
| kfogel | jam: but that's a different discussion :-) | 17:05 |
| kfogel | jam: part of the problem is that launchpad has four trunks | 17:05 |
| kfogel | jam: linking by revno also just works -- that's how it was working up until about 5 minutes ago, in fact. | 17:05 |
| vxnick | hi all - is it possible to branch a repo into another repo? I've done this, but 'bzr add' doesn't add the branched repo to the current repo (if that makes sense) | 17:10 |
| jam | vxnick: I think you are thinking of "branching a branch" not a "repo". Yes it is possible ,but we won't add it to the containing branch | 17:12 |
| vxnick | jam: so I'd need to branch it on the production server separately then | 17:13 |
| jam | vxnick: I believe so | 17:13 |
| vxnick | jam: thanks | 17:13 |
| phinze | jam: got spare cycles for me to bother you about this tip change hook i'm working on? .. just a couple of conceptual questions | 17:14 |
| === deryck is now known as deryck[lunch] | ||
| jam | phinze: possibly, though my load counter is pretty high right now :) | 17:15 |
| phinze | jam: if not, is AOK... just looking to sap your expertise for fun and profit | 17:15 |
| phinze | jam: basically i'm stuck given the fact that i'm given a old_revid and a new_revid ... and none of the new revisions exist in the *branch* yet but they're in the *repository* | 17:16 |
| phinze | so i can get the last new revision easily, as i have its id | 17:16 |
| phinze | but i'd like to iterate over all the incoming revisions, because i want to see if changes being made to the dirs i'm watching come from the right place | 17:16 |
| jam | g = branch.repository.get_graph() | 17:17 |
| jam | g.find_unique_ancestors(new_revid, [old_revid]) | 17:17 |
| jam | b.repository.revision_trees(unique_ancestors) | 17:17 |
| jam | phinze: something like that? | 17:17 |
| phinze | jam: beautiful | 17:17 |
| phinze | the API is large... i was making my way, but slowly :) | 17:18 |
| jam | phinze: you'll have to double check some of the api to make sure you are supplying the values correctly | 17:18 |
| jam | but something like that should work | 17:18 |
| jam | also you may want b.repository.revisions(...) | 17:18 |
| jam | if you want to read the commit message, etc | 17:18 |
| jam | but if you want the tree contents | 17:18 |
| phinze | awesome, you've definitely saved me some significant head-scratching times | 17:18 |
| jam | then revision_trees() | 17:18 |
| phinze | right... i've got code that walks the delta between old and new and successfully detects if watched paths have changed, but now i've got to nail those changes down to a revision to see if it's a merge from trunk | 17:19 |
| jam | phinze: ah, so user A isn't allowed to modify them, but it is okay if they look changed because they merged it from trunk? | 17:19 |
| phinze | basically the plugin ensures that certain dirs are only changed in trunk and merged to projects ... we've had a lot of trouble with people making changes and diverging when they shouldn't | 17:19 |
| phinze | jam: right | 17:20 |
| jam | phinze: why do you care about the individual revisions, rather than the net effect of the merge? | 17:20 |
| jam | why not just compare old_rev_id and new_revid's trees | 17:20 |
| jam | rather than every step along the way | 17:20 |
| phinze | that's what my current code does... walks through newtree.changes_from(oldtree) | 17:21 |
| phinze | but isn't it possible that the tip change includes many revisions, some of them merges from trunk and others local changes? | 17:21 |
| === cprov-lunch is now known as cprov | ||
| jam | phinze: well, if you only have trunk changes, then the result of the merge should be empty | 17:33 |
| jam | since those changes are already on the trunk | 17:33 |
| phinze | jam: bzr branch lp:bzr-protect to see what i gots | 17:34 |
| phinze | meant to be run on the shared repository | 17:35 |
| jam | phinze: when I get a chance... I'm currently upgrading all my branches to --2a format, which is being ... involved :) | 17:35 |
| phinze | ahh fair | 17:35 |
| jam | phinze: you might want to look at something like "merge --preview" | 17:35 |
| jam | which does a merge, and figures out what the final content changes are | 17:35 |
| fullermd | Does upgrade recurse yet? | 17:35 |
| phinze | jam: will do, thanks for all the advice -- i'll keep working on it | 17:35 |
| jam | fullermd: my branches are new enough, but I decide to 'bzr branch lp:bzr' rather than upgrading from scratch | 17:35 |
| jam | phinze: so just doing "new.iter_changes(old)" you could easily have changes in there that are 'bogus' because your trunk changed something and old didn't change anything | 17:36 |
| fullermd | Well, I was asking for me, but I guess I can just test it :) | 17:36 |
| jam | you could look at "common_ancestor.iter_changes(new)" but that may also include things that, like you said, are from trunk | 17:36 |
| jam | fullermd: I don't believe so | 17:36 |
| jam | not sure | 17:36 |
| fullermd | A quick test agrees with you. Gruuh. | 17:37 |
| phinze | jam: exactly, so i want to exclude from the list of invalid changes anything that originated in an authorized branch | 17:38 |
| phinze | i mean i could probably simplify the use case if i dictate that merges from trunk must be made exclusively | 17:39 |
| phinze | so cd project.bound; bzr merge ../trunk.bound; bzr ci; | 17:39 |
| jam | phinze: so there is also the possibility that when someone merges trunk, they also edit the content before they commit | 17:39 |
| phinze | jam: ick, i suppose that's true, but this is not meant for protection from a hostile environment, just as an aid to clumsy developers :) | 17:40 |
| jam | phinze: my point is | 17:40 |
| jam | if you do the merge --previou | 17:40 |
| jam | --preview | 17:40 |
| jam | then *nothing* should change for those files | 17:40 |
| phinze | ahhhh | 17:40 |
| phinze | ok | 17:40 |
| jam | since it should only include changes that have already happened | 17:40 |
| jam | it also allows someone to | 17:40 |
| jam | bzr commit -m "modify some files" | 17:41 |
| jam | bzr revert bad_files -r -2 | 17:41 |
| jam | bzr commit -m "didn't mean to do that" | 17:41 |
| jam | and still end up with a clean merge | 17:41 |
| jam | as long as they undo their mistake before it gets merged. | 17:41 |
| phinze | gotchya | 17:41 |
| phinze | so the commands you just listed, that would be something someone did on trunk? | 17:43 |
| jam | phinze: commit + revert would be something they did on their branch | 17:44 |
| phinze | ahh bad_files being stuff that would be protected | 17:44 |
| jam | phinze: right | 17:44 |
| phinze | so--and i'm sorry i'm being slow with this--you're suggesting i look into checking merge --preview into the use case for the plugin (i.e. users would somehow work with it) or into the execution of the tip-change hook | 17:45 |
| jam | phinze: so how are users changing the tip? | 17:46 |
| jam | via a checkout | 17:46 |
| jam | via push? | 17:46 |
| jam | via ??? | 17:46 |
| jam | (PQM?) | 17:46 |
| phinze | 95% of the time via checkout | 17:46 |
| jam | phinze: and where is this check running? locally, or on the server? | 17:47 |
| phinze | and i can dictate that it is always via $METHOD_FOO if that makes this plugin work for us | 17:47 |
| jam | phinze: well, I would *recommend* via a checkout, and I would *recommend* setting 'append_revisions_only=True' in the trunk's branch.conf | 17:47 |
| phinze | jam: both of these are true currently | 17:47 |
| phinze | so it's bzr co bzr+ssh://dev/trunk trunk.bound | 17:48 |
| jam | so... what you are getting is a new_revision_id which is actually the product of the merge | 17:48 |
| jam | so just doing new.iter_changes(old) should result in 0 changes to the protected files | 17:48 |
| jam | the point of 'merge --preview' is that the 'result of the merge should not change these files' | 17:49 |
| jam | and you are already dealing in the 'result of the merge' | 17:49 |
| jam | now... how do you actually introduce *desired* changes to those files? | 17:49 |
| phinze | oooooh... i just realized i've been testing by doing 'bzr push' and not emulating the actual environment | 17:49 |
| jam | phinze: well, bzr push should operate the same as 'bzr commit' | 17:49 |
| jam | since the end result is a revision which should be a merge into the trunk last revision | 17:49 |
| phinze | ah ok | 17:50 |
| jam | given that you have 'append_revisions_only' | 17:50 |
| jam | there is a small possibility of something else | 17:50 |
| jam | which I'll graph | 17:50 |
| jam | just a sec | 17:50 |
| phinze | jam: heh, i feel bad i always try and make my questions simple and pointed and it always spins out into me trying to get my head around something you're spending much effort to explain :) | 17:51 |
| jam | phinze: http://paste.ubuntu.com/264530/ | 17:52 |
| phinze | http://gist.github.com/180399 <-- current code, in more easily visible form | 17:52 |
| jam | http://paste.ubuntu.com/264532/ for a bit more detail | 17:53 |
| phinze | okay, so "will push cleanly as" refers to a push from where to where | 17:55 |
| phinze | from user -> project branch? | 17:55 |
| jam | phinze: right | 17:56 |
| jam | see the second paste | 17:56 |
| jam | normal operation would be to merge the change to a single mainline revision | 17:56 |
| jam | however, push with append_revisions_only will allow the other | 17:56 |
| phinze | so basically this is an edge case that could circumvent the policy? | 17:58 |
| phinze | so if we dictate "only merge into trunk, don't push" | 17:59 |
| phinze | we should be in the clear, no? | 17:59 |
| jam | phinze: so instead of 'changes_from()' I would use the 'iter_changes()' function | 18:01 |
| jam | phinze: it won't circumvent policy | 18:01 |
| jam | not really | 18:01 |
| jam | just that potentially D could modify the files, and E revert those changes | 18:01 |
| jam | and the policy would then allow that to be pushed | 18:01 |
| jam | and you would have a mainline revision which modifies and reverts content | 18:01 |
| jam | http://paste.ubuntu.com/264536/ | 18:01 |
| jam | I would change your inner loop to ^^ | 18:01 |
| phinze | ha! so python folk really do use _ ... i was wondering about that yesterday | 18:02 |
| phinze | even though _ is just a valid variable name and just gets reassigned | 18:03 |
| jam | phinze: also, I find: http://bazaar.launchpad.net/~phinze/bzr-protect/trunk/annotate/head%3A/__init__.py | 18:03 |
| jam | to be just fine without having to go to github :) | 18:03 |
| jam | phinze: it is generally used to mean "I'm ignoring this variable" | 18:03 |
| phinze | jam: ah sorry, rubyist in a foreign land :) | 18:04 |
| jam | python interpreter's use it to store the 'last computed value' | 18:04 |
| jam | well, *interactive interpreter* | 18:04 |
| jam | inside python itself | 18:04 |
| jam | it is just another variable you can assign or not | 18:04 |
| jam | but it isn't auto-assigned | 18:05 |
| phinze | jam: right i'm familiar with its usage, i just assumed since _ had a value in testing that it was somehow not the Right Way | 18:05 |
| jam | 'value in testing' ? you mean in the interactive? | 18:05 |
| phinze | it was in interactive | 18:05 |
| jam | we use it inside bzrlib to just mean "I'm ignoring you" | 18:05 |
| phinze | so i must have just been confused by that | 18:05 |
| phinze | alright [/aside] :) | 18:06 |
| phinze | so empty list evaluates to false as well | 18:06 |
| phinze | nice | 18:07 |
| phinze | alright lunchtime here... thank you a million times... i will be working on this once i get back | 18:07 |
| jam | phinze: empty list/set/tuple/etc all evaluate to false | 18:07 |
| jam | you could also do | 18:07 |
| jam | if len(foo) == 0: if you want | 18:08 |
| phinze | jam: next time you're in town i definitely owe you a beer ;D | 18:08 |
| === phinze is now known as phinze_lunch | ||
| * vila 2/3 hosts upgraded to 2a, submission sent to pqm (involving both hosts and lp) ! EODing | 18:12 | |
| spirov92 | a question- I have 2 branches-mysite/working and mysite/devel. one is put on the server, and one is for local development. They need to have different database config files. How do I copy just *some* changes from one to the other? | 18:29 |
| spirov92 | I'm thinking while I'm cd'd to mysite/devel, bzr push ../working. if I haven't changed the different files, will that work? | 18:30 |
| === deryck[lunch] is now known as deryck | ||
| === phinze_lunch is now known as phinze | ||
| jam | phinze: what town is that? | 19:46 |
| phinze | jam: iowa city; i work with keith; we had lunch and talked RCS :) | 20:10 |
| jam | ah, right | 20:11 |
| moldy | hi | 20:11 |
| jam | been a while since I've thought about you guys :) | 20:11 |
| phinze | we're still here, plugging along with bzr ;) | 20:11 |
| phinze | i extended the cerberus CI package with bazaar support and that's been working decently for us http://cerberus.rubyforge.org/ | 20:12 |
| phinze | got it pushed upstream and everything :) | 20:12 |
| lifeless | moin | 20:23 |
| phinze | jam: incorporated your suggestions, much cleaner now: http://bazaar.launchpad.net/~phinze/bzr-protect/trunk/annotate/head%3A/__init__.py | 20:32 |
| phinze | reading about TransformPreview to try and figure out how to detect valid changes to protected directories | 20:32 |
| phinze | jam: hmm after re-reading above and looking again wondering if your suggestions already account for that; because merges don't show up in the iter_changes loop | 20:38 |
| phinze | but i don't see how that could be the case since there's no detection being done as to the origin of each change... i'm not sure if i should be trying to use the '(source_parent, target_parent)' returned in the tuple from iter_changes to figure that out | 20:39 |
| jam | so, phinze, the whole objective here is that the change relative to the last committed trunk revision should have no paths in the 'protected set' | 20:46 |
| jam | which should be okay for all cases | 20:47 |
| lifeless | hi jam | 20:47 |
| jam | hi lifeless | 20:47 |
| jam | the main problem is how do you end up introducing *wanted* changes? | 20:47 |
| lifeless | 129G of fast import to test today :P | 20:47 |
| jam | lifeless: at least it finally finished | 20:48 |
| lifeless | jam: yeah. I was very happy about that | 20:48 |
| lifeless | I just installed my memory upgrade too | 20:48 |
| jam | ooh, shiny | 20:50 |
| jam | though 6GB <<< 129 :) | 20:50 |
| lifeless | yes | 20:50 |
| lifeless | sadly true | 20:50 |
| lifeless | I let fast import try overnight | 20:50 |
| jam | I'm pretty sure igc recommends .gz your fast import file | 20:50 |
| lifeless | startsed at 300Revs/sec | 20:50 |
| lifeless | thrashing when I got up, so stopped it and put the memory in | 20:50 |
| phinze | right... | 20:51 |
| lifeless | jam: I didn't get to the group combining, doing the dogfood upgrade took over | 20:52 |
| jam | lifeless: yeah, I'm still working on getting my branches upgraded as well | 20:52 |
| phinze | jam: ideally relative to the last committed revision from "an authorized branch" | 20:52 |
| phinze | such that it's configuravble | 20:52 |
| phinze | but the concept is the same yes | 20:53 |
| phinze | jam: perhaps a companion command that does the merging from trunk/authorized_branch in a sane way? | 20:54 |
| phinze | bzr authorized_merge ../trunk.bound => merges to tip of trunk and commits? | 20:55 |
| phinze | bzr authorized_merge ../my_dumb_branch => Exception: my_dumb_branch not listed as authorized branch | 20:55 |
| jam | phinze: well, any sort of direct access to the branch that isn't using the plugin would work, too | 21:00 |
| jam | however, you could set up the pre filter based on source? I'm not really sure | 21:00 |
| jam | you could check the username of the committed message | 21:00 |
| phinze | hmmm... yeah basically we just need the i-know-what-i'm-doing detection | 21:00 |
| phinze | :) | 21:00 |
| phinze | jam: yeah that's easy | 21:00 |
| phinze | check branch.conf for "smart_people" | 21:01 |
| phinze | my pie in the sky spec for this plugin was that it would actually split off the changes and attempt to make a commit to trunk and merge it in before attempting a commit to the project branch | 21:02 |
| phinze | crazy? oh yes | 21:02 |
| phinze | but i think limiting merge access to certain users is probably a good first step | 21:02 |
| lifeless | jam: in-1.9-format is in 1,9 | 21:08 |
| jam | lifeless: check | 21:09 |
| lifeless | jam: I think you're ina checkout of 2a or something with an old bzr format | 21:09 |
| jam | bzr pull http:..../bzr.dev-in-1.9 is not working | 21:09 |
| lifeless | jam: I did, I replied on the list | 21:09 |
| phinze | eh, the more i think about it the less satisfied i am with it as a compromise... i feel like there should be some way to detect "changes that came from trunk"... | 21:09 |
| lifeless | jam: yes, I *think* you'll find that 'bzr info' also fails | 21:09 |
| thumper | what would cause a VersionedFileInvalidChecksum when pulling from a merge directive into a branch? | 21:10 |
| jam | thumper: best guess, a bundle created with a version of bzr before it actually worked with 2a formats | 21:11 |
| thumper | jam: what about a bundle that was created when it worked and a pulling with a version that didn't? | 21:11 |
| jam | thumper: probably as well | 21:11 |
| * thumper nods | 21:11 | |
| thumper | LP has this | 21:11 |
| lifeless | what release did you fix bundles in? | 21:12 |
| jam | lifeless: 1.18rc1 according to NEWS | 21:14 |
| lifeless | lp has 1.18 | 21:14 |
| lifeless | sorry | 21:14 |
| lifeless | 1.17 | 21:14 |
| thumper | we have 1.18 landed but not rolled out | 21:15 |
| jam | lifeless: any idea why lp:bzr would be 3x larger than it should be? | 21:23 |
| jam | 90MB vs 30MB after 'bzr pack' | 21:23 |
| lifeless | none as yet | 21:25 |
| lifeless | once spm gets here I'll use him to poke around | 21:25 |
| spm | o/ | 21:25 |
| lifeless | o hai | 21:26 |
| lifeless | you can eat first :P | 21:26 |
| jam | lifeless: interesting... I have converted to 2a locally, and tried to push to an existing 1.9 branch. It gave me "no revisions to push" which is probably accurate | 21:26 |
| jam | but I expected cross-format warnings first | 21:26 |
| lifeless | jam: the branch has a duplicate check | 21:26 |
| lifeless | based on tip | 21:26 |
| jam | ah, self.tip == remote.tip exit early? | 21:26 |
| jam | fair enough | 21:26 |
| jam | I'm not *terribly* surprised, just a little surprised :) | 21:27 |
| lifeless | I think; also possibly if you were pushing to lp, the remote stuff may have helped defer issues | 21:27 |
| jam | yeah | 21:27 |
| jam | I was | 21:27 |
| spm | lifeless: already eaten etc :-) need to be at the boy's school this morning for a fathers day whatsit. so afk from ~8-10am; hence the early start. | 21:27 |
| jam | I also have my downloaded copy, which is ~100MB on disk, which I can use for post-introspection if necessary | 21:27 |
| lifeless | jam: not sure on that one. Have you solved the mystery of why you think in-1.9 is in 2a? | 21:28 |
| jam | lifeless: you did add code to auto-pack after upgrade, right? | 21:28 |
| jam | even for remote? | 21:28 |
| lifeless | jam: yes, Interfaces | 21:28 |
| lifeless | jam: remote uses the same interface locally | 21:28 |
| jam | lifeless: I think the branch I was pulling into was a checkout of bzr.dev, which caused the failure at 'open master branch' though the failure message doesn't make that clear | 21:28 |
| lifeless | on the far end | 21:28 |
| lifeless | jam: yes, thats what I thought :) | 21:28 |
| jam | well, the failure message doesn't indicate what branch format it is failing to read | 21:29 |
| lifeless | jam: as in, something along those lines :) | 21:29 |
| jam | what branch format *file* | 21:29 |
| lifeless | jam: yeah, we might want a optional url in the error | 21:29 |
| lifeless | spm: so, can you please pastebin ls -l archives/thelove/bzr/.bzr/{obsolete_,}packs | 21:29 |
| lifeless | spm: on balleny | 21:29 |
| spm | lifeless: No such file or directory on both cases | 21:30 |
| lifeless | add repository/ | 21:30 |
| jam | .bzr/repository/{... | 21:31 |
| lifeless | spm: our repo is 3 times larger than we expected | 21:31 |
| lifeless | spm: we want to figure out why | 21:31 |
| jam | lifeless: so it could certainly be fragmentation copying it from balleny to lp | 21:31 |
| jam | especially if they have different ideas of 'groupcompress' order | 21:31 |
| lifeless | oh, also we might benefit by getting a copy of ~/.bzr.log* | 21:31 |
| lifeless | jam: lp is running 1.17 | 21:31 |
| jam | lifeless: I assume that is pushed from pqm | 21:31 |
| lifeless | jam: so thats a very plausible theory | 21:32 |
| lifeless | jam: yes | 21:32 |
| jam | lifeless: what version is pqm running? | 21:32 |
| jam | also 1.17? | 21:32 |
| lifeless | high security -> lower security | 21:32 |
| spm | lifeless: https://pastebin.canonical.com/21816/ | 21:32 |
| lifeless | jam: the conversion was done with .dev 4667 | 21:32 |
| jam | lifeless: sure the conversion, but what pushed it to lp? | 21:32 |
| lifeless | same same | 21:32 |
| jam | lifeless: obsolete packs has a nice small: -rw-r--r-- 1 pqm pqm 31820 2009-09-03 15:12 8bc55f8aeed4e37d4d993bff6b8a26dd.pack | 21:32 |
| jam | packs probably has a bunch of garbage packs in there | 21:33 |
| jam | though I'm a bit surprised by the dates | 21:33 |
| lifeless | spm: bzr dump-btree .../repository/pack-names, please | 21:33 |
| spm | lifeless: https://pastebin.canonical.com/21817/ | 21:34 |
| jam | lifeless: ones like: -rw-r--r-- 1 pqm pqm 14115960 2009-09-03 09:12 0eeefcbd67df67ab2e7decf890907ba7.pack are about 6 hours older than the obsolete pack | 21:34 |
| jam | now that is strange | 21:35 |
| jam | they appear to all be referenced and the nicely packed one is in obsolete... | 21:35 |
| jam | although... are those all in bytes? | 21:35 |
| lifeless | yes | 21:35 |
| jam | I guess 32k would be way too small | 21:36 |
| lifeless | I asked for -hs, got neither :( | 21:36 |
| lifeless | that that pack is in obsolete_packs is just weird | 21:36 |
| lifeless | spm can you do the ls again, with -lhS please | 21:37 |
| jam | lifeless: so the size in packs is 54MB | 21:38 |
| jam | which is approx what I would expect from packs if it was loose | 21:38 |
| jam | though it bloated to 90MB on lp | 21:38 |
| spm | lifeless: certainly | 21:38 |
| lifeless | thanks! | 21:39 |
| spm | lifeless: https://pastebin.canonical.com/21818/ | 21:39 |
| lifeless | jam: I can't explain that tiny pack | 21:40 |
| jam | lifeless: I assume the tiny pack is just remnants from other stuff | 21:40 |
| jam | like merging a revision | 21:40 |
| lifeless | oh, I know | 21:40 |
| lifeless | it will be a merge from a 1.9 branch | 21:40 |
| lifeless | that does the following: | 21:40 |
| jam | but it would seem that we did *not* repack the whole repo into a single pack after upgrade | 21:40 |
| jam | is this an IDS artifact? | 21:41 |
| lifeless | fetch (converting); insert; autopack that one pack file | 21:41 |
| jam | that IDS only causes autopack of the *last* entry, and not all entries? | 21:41 |
| lifeless | yes, IDS was used to convert | 21:41 |
| lifeless | uhm, not sure | 21:41 |
| lifeless | IDS should be passing in all the packs it accumulated on the way | 21:41 |
| lifeless | unfortunately because a 1.9 branch landed we can't see what obsolete packs was | 21:42 |
| lifeless | the log files will help | 21:42 |
| lifeless | spm: ^ | 21:42 |
| jam | lifeless: so the overall layout looks like what I would expect from IDS without having it repack everything | 21:42 |
| jam | it looks like IDS's pack every 10k 1k, etc | 21:42 |
| spm | lifeless: the ~/.bzr.log as in? | 21:42 |
| lifeless | jam: well, standard log10 backoff | 21:43 |
| lifeless | spm: and .old too please | 21:43 |
| jam | lifeless: right, especially given we have 27k revs | 21:43 |
| jam | and there are 2 10+MB packs, 8 1-7MB ones | 21:43 |
| jam | and a couple small ones | 21:43 |
| jam | it doesn't perfectly line up, but pretty close | 21:43 |
| jam | lifeless: so with pack-on-the-fly starting from the 'badly packed' copy from launchpad: | 21:44 |
| jam | time bzr branch test-area | 21:44 |
| jam | real 1m2.541s; 101MB (same as source) | 21:44 |
| jam | time bzr-pack branch test-area | 21:44 |
| jam | real 1m42.478s; 61MB | 21:44 |
| jam | time bzr pack | 21:45 |
| jam | 2m0s ; 30MB | 21:45 |
| lifeless | spm: the next thing I'd like you to do | 21:45 |
| jam | so the current pack-on-the fly code does help, albeit not as much as a full pack | 21:45 |
| lifeless | spm: is to gather the same ls data, for the master copy of the bzr.dev branch on codehosting | 21:45 |
| spm | 'kk | 21:45 |
| thumper | hey lifeless, poolie: https://code.edge.launchpad.net/bzr/+activereviews https://code.edge.launchpad.net/bazaar/+activereviews https://code.edge.launchpad.net/~lifeless/+activereviews https://code.edge.launchpad.net/~lifeless/bzr/+activereviews | 21:45 |
| jam | lifeless: I also realized a bit ago that we may need to look again at 'chk_map.iter_interesting_nodes()' for pack-on-the-fly performance | 21:46 |
| jam | it returns 'unordered' at each 'level' of the tree | 21:46 |
| jam | rather than grouping by subkey | 21:46 |
| spm | lifeless: we have the backup copy - pre the migration - if on the very off chance that'll help. worst case, I can rerun same ?? | 21:46 |
| jam | ('pack' groups by subkey) | 21:46 |
| lifeless | spm: thanks, for now keep it in reserve | 21:46 |
| spm | lifeless: https://chinstrap.canonical.com/~spm/bzrlog.tgz | 21:46 |
| spm | 'k | 21:46 |
| lifeless | spm: nothing is wrong with our conversion, just identifying things we want to fix in bzr where it could have done better | 21:47 |
| jam | so, take that back, 'bzr pack' results in 39MB, but still better than now | 21:47 |
| spm | lifeless: ahh right. goodo | 21:47 |
| lifeless | 06:44:17 38000/133780 commits processed at 1030/minute (:38000) | 21:49 |
| jam | lifeless: this is your fast-import ? | 21:49 |
| jam | and IIRC, fast-import still buffers way to much in memory | 21:50 |
| jam | lifeless: so I have to redact slightly | 21:50 |
| lifeless | yes | 21:50 |
| jam | pack-on-the-fly is 41MB after 1m37s sending | 21:50 |
| jam | no-pack is 101MB after 1m01s | 21:50 |
| jam | pack is 39MB after 2m0s | 21:50 |
| lifeless | isn't real world data lovely :) | 21:50 |
| lifeless | thumper: whats changed? | 21:51 |
| jam | testing already-packed to new location | 21:51 |
| thumper | lifeless: approved merges at the top, other heading changed, you can now have it for project groups and person/product | 21:51 |
| lifeless | thumper: awesome; sorry that I had to ask :) | 21:52 |
| thumper | lifeless: and if you look at someone else's reviews, it shows better | 21:52 |
| thumper | lifeless: pn | 21:52 |
| thumper | np | 21:52 |
| lifeless | spm: how we going on the private copy on codehosting? | 21:52 |
| spm | lifeless: getting - just getting the disk location now | 21:52 |
| jam | pack-on-the-fly-from already packed: 41MB 1m0s | 21:53 |
| jam | lifeless: so it is working as we would like | 21:53 |
| jam | it packs data when it needs to | 21:53 |
| jam | doesn't spend time repacking when the source looks good | 21:54 |
| jam | gets close to full pack results | 21:54 |
| jam | lifeless: however, I think the branch was started from bzr.dev rather than --2a, should we cherrypick it, then? | 21:54 |
| lifeless | jam: well, I started mine from 2a, you merged .dev :P | 21:54 |
| jam | lifeless: I probably started from dev | 21:55 |
| lifeless | I'd land on .dev | 21:55 |
| lifeless | then cherrypick back | 21:55 |
| lifeless | My remote streaming thing hasn't landed on .dev either | 21:55 |
| spm | lifeless: https://pastebin.canonical.com/21820/ | 21:55 |
| jam | lifeless: adjacent-streaming? | 21:55 |
| lifeless | onyl got it into 2a before the shutdown for conversion | 21:55 |
| lifeless | yes | 21:55 |
| lifeless | just needs a new NEWS entry in the IN DEVELOPMENT section | 21:55 |
| lifeless | spm: thanks | 21:56 |
| lifeless | 50M where pqm pushed | 21:56 |
| lifeless | 91M where lp copied | 21:56 |
| lifeless | I think fragmentation | 21:56 |
| lifeless | lets get 2.0 on lp; then get a pack run of all public copies :) | 21:56 |
| spm | ....!!!! | 21:57 |
| lifeless | spm: it will same 60% of disk or more | 21:57 |
| spm | Oh! In that case, I'm pushing it in now. 'k | 21:57 |
| lifeless | spm: see how one repo is 50M the other 90? | 22:04 |
| spm | yeah - I was wondering if that was an issue - hence the frag comments made some sense | 22:05 |
| lifeless | jam: I'm satisified that we know the causes here | 22:05 |
| lifeless | jam: are you? | 22:05 |
| jam | lifeless: I haven't specifically investigated how the pack is laid out, but I *think* we know what was going on. | 22:06 |
| jam | As long as we are sure of the version of bzr pqm used to push to launchpad | 22:06 |
| jam | that it was doing 'groupcompress' and not 'unordered' fetching | 22:06 |
| lifeless | spm: you used the custom build to do the push didn't you ? | 22:06 |
| lifeless | last night I mean | 22:06 |
| spm | lifeless: to do the pushes we did last night; yes. but verifying my history - one sec | 22:06 |
| lifeless | jam: that will be in the log files | 22:06 |
| lifeless | jam: however, server is 1.17 | 22:07 |
| spm | lifeless: aye. every time. revno 4667 on all 5 pushes. | 22:07 |
| jam | lifeless: I'm pretty sure for 'bzr push' it is the client version that matters here | 22:07 |
| lifeless | jam: right. 50M on balleny, 50M on the private copy on lp, 90MB on the public copy | 22:07 |
| lifeless | jam: so I think the first push was unordered | 22:07 |
| jam | lifeless: https://code.edge.launchpad.net/~jameinel/bzr/2.1b1-pack-on-the-fly/+merge/11162 whenever you want | 22:07 |
| lifeless | jam: and the mirror fetch was gc and fragmented | 22:08 |
| jam | lifeless: ah, so when I access over sftp, I'm actually getting the mirrored copy? | 22:08 |
| jam | lifeless: then +1 | 22:08 |
| lifeless | yes | 22:08 |
| lifeless | spm: please, on codehosting, run bzr pack in mirror copy | 22:08 |
| lifeless | the one with the 90MB pack | 22:08 |
| spm | sure | 22:08 |
| lifeless | it won't stop this going ugly, but it will help mitigate | 22:09 |
| spm | want a backup copy first? JIC? | 22:09 |
| lifeless | no | 22:09 |
| spm | :-) brave man | 22:09 |
| lifeless | do the same for the 1.17 1.18 2.0 public branches | 22:09 |
| spm | oki | 22:09 |
| jam | spm: Not worried about 'bzr pack' destroying things | 22:09 |
| lifeless | spm: pack happens automatically everywhere; if you have to back up before doing it, you'd have to backup before running commit | 22:09 |
| spm | ew | 22:09 |
| jam | 'bzr upgrade' is a bit more sensitive, but pack is pretty well handled | 22:09 |
| spm | right, makes sense | 22:09 |
| lifeless | spm: also, we have private master copies we can use *if* in the extraordinary event that pack went south | 22:10 |
| lifeless | so we're already backed up | 22:10 |
| spm | lifeless: this'll be using bzr 1.17 - I'm assuming that's ok | 22:10 |
| lifeless | to sumamrise | 22:10 |
| lifeless | spm: thats fine | 22:10 |
| spm | 'kk | 22:10 |
| lifeless | we think that: a) IDS didn't do a full pack during the 'upgrade', and perhaps-it-should perhaps-it-shouldn't | 22:11 |
| lifeless | and b) that fragmentation between the 1.17 GC order and the rev 4667 of trunk order turned 50MB into 90MB | 22:11 |
| lifeless | jam: https://pastebin.canonical.com/21820/ is the codehosting sizes | 22:11 |
| lifeless | 07:11:57 41000/133780 commits processed at 635/minute (:41000) | 22:12 |
| lifeless | -rw-r--r-- 1 robertc robertc 89M 2009-09-04 07:06 a6968b0190033b59553272ded45d13fa.pack | 22:12 |
| jam | lifeless: yeah, the mirrors I was aware of, and that fits right at what I'm comfortable saying "this is fragmentation issues with older versions of bzr" | 22:13 |
| jam | lifeless: especially given that the gc order pqm pushed to lp would be different than the gc order | 22:13 |
| jam | that lp thinks would be best pushing to the mirror | 22:13 |
| jam | lifeless: now to figure out why my network bandwidth isn't getting saturated while fetching from lp | 22:15 |
| jam | even in 'unordered' sorting | 22:15 |
| jam | lifeless: any ideas where to start? | 22:16 |
| spm | lifeless: https://pastebin.canonical.com/21822/ mirrors done for bzr.dev <== keep on truckin'? | 22:16 |
| lifeless | jam: get a network trace, we need data on out of order, window sizes etc | 22:16 |
| lifeless | jam: I've seen lp be a bit spotty from time to time, but we don't have a hard analysis | 22:17 |
| lifeless | spm: sweet go forward and pack | 22:17 |
| spm | on 2.0, 1.17 and 1.8? oki. | 22:17 |
| lifeless | spm: you can remove the contents of [but not the dir] obsolete packs there | 22:17 |
| lifeless | bzr will remove it itself eventualyl | 22:17 |
| jam | lifeless: of course, spm just borked my stream and it has to restart now :) | 22:18 |
| spm | I'll go for the latter option - eventual remove | 22:18 |
| lifeless | spm: kk | 22:18 |
| spm | jam: I deliberately waited till you were mid access :-P | 22:18 |
| jam | though nice to see that it did so graciously, without interruption | 22:18 |
| lifeless | jam: \o/ | 22:18 |
| lifeless | jam: should happen on the client side | 22:18 |
| lifeless | jam: unless you're using sftp | 22:18 |
| jam | lifeless: using bzr+ssh | 22:18 |
| lifeless | sorry, I meant to say 'on the server side' | 22:19 |
| jam | lifeless: yeah, it should notice the repack, and start reading from the new packs | 22:19 |
| lifeless | \o/ layers, and \o/ us | 22:19 |
| jam | _get_remaining_record_stream and all | 22:19 |
| spm | lifeless: fwiw. 2.0: -rw-r--r-- 1 codehost codehost 170K 2009-09-03 10:37 a6acd2ed3e0fa3df6e472d7476523cf7.pack <== the other file is 163K, even worth doing the pack? | 22:19 |
| lifeless | spm: oh hmm no | 22:20 |
| lifeless | ignore | 22:20 |
| KhaZ | Hello: Apologies if I shouldn't ask about fastimport here, but I'm havnig some difficulty and hope someone can help. Basically I'm trying to use the svn front end, and I'm getting: A lot of: Exporting revision 266... skipping. messages, with the result being that I don't get a valid bzr repo built. | 22:20 |
| spm | will check 1.17 and 18 to be sure | 22:20 |
| jam | lifeless: is that because it is stacked? | 22:20 |
| lifeless | jam: yes | 22:20 |
| lifeless | KhaZ: you're welcome to ask about anything :) | 22:20 |
| lifeless | KhaZ: is it the svn export that is skipping, or the bzr import ? | 22:20 |
| jam | spm: So did you do the 'bzr pack' using 1.17? | 22:20 |
| lifeless | jam: yes he did | 22:21 |
| spm | jam: aye | 22:21 |
| mneptok | lifeless: why does God not intervene to stop bad people from doing bad things? | 22:21 |
| mneptok | lifeless: (this relates to the continued use of CVS by some people) | 22:21 |
| lifeless | mneptok: because he likes a little tittle himself | 22:21 |
| KhaZ | lifeless: It's the export. If I do the left hand side of the pipe: ~/.bazaar/plugins/fastimport/exporters/svn-fast-export.py ~/dev/eddie_svn | bzr fast-import -, it still gives that message. | 22:21 |
| spm | mneptok: because that's mnepolo's job - God delegated. | 22:21 |
| lifeless | KhaZ: so, I don't know much/anything about the svn fastexport code | 22:22 |
| lifeless | uhm | 22:22 |
| lifeless | igc /might/ | 22:22 |
| KhaZ | Ah, too bad. Yeah, unfortunately the message isn't very helpful. I don't know why it's skipping exactly. | 22:22 |
| lifeless | but he won't be up for an hour and change | 22:22 |
| spm | lifeless: fwiw, 1.17 and 18 are empty on the packs | 22:22 |
| jam | lifeless: what is a good wireshark filter for excluding everything but ssh? | 22:22 |
| lifeless | KhaZ: if you just want to import to bzr, can I suggest bzr-svn's excelling svn-import command | 22:23 |
| lifeless | jam: port 22 | 22:23 |
| KhaZ | Oh. Neat. OK, I'll try out svn-import. Wasn't sure the difference. | 22:23 |
| jam | lifeless: ip.addr == 91.189.90.11 seems good enough | 22:25 |
| jam | (bazaar.lp.net) | 22:25 |
| jam | so about 18s in, it starts 'thinking'... presumably that is determining revs to send, etc | 22:27 |
| jam | lifeless: hm... I'm seeing a fair amount of 'retransmission' packets | 22:28 |
| lifeless | do you have SACK enabled? | 22:28 |
| lifeless | what OS | 22:28 |
| jam | lifeless: Windows | 22:28 |
| lifeless | yes but which one | 22:29 |
| jam | Vista Basic | 22:29 |
| jam | Current window is 259888 | 22:29 |
| jam | though it has gone down to 150 at the lowest | 22:29 |
| jam | wel, 150000 | 22:29 |
| jam | you know what, though. I'm also running in the basement, on wireless in the top floor | 22:31 |
| jam | it may just be wireless retransmission issues | 22:31 |
| jam | I don't generally notice, though | 22:31 |
| jam | And my connection looks good | 22:31 |
| jam | claims 88% signal | 22:31 |
| lifeless | HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters | 22:31 |
| lifeless | SackOpts | 22:31 |
| lifeless | whats that set to / does it exist | 22:32 |
| jam | lifeless: no SackOpts exits that I can find | 22:33 |
| lifeless | check the wireshark handhake | 22:34 |
| lifeless | was selective act enabled ? | 22:34 |
| lifeless | (in the 3 way handshake at the start) | 22:34 |
| jam | lifeless: I'm not really sure what to look for there | 22:35 |
| lifeless | so if there are lots of retransmissions | 22:36 |
| lifeless | and selective ack is off | 22:36 |
| jam | download time with bzr.dev was at least 9m45s | 22:36 |
| jam | which is a lot better | 22:36 |
| lifeless | it has to retransmit the entire missing segments | 22:36 |
| jam | of course, that is with 3x less data :) | 22:36 |
| === cprov is now known as cprov-afk | ||
| KhaZ | Hrmm. I'm tryign to run bzr with the bzr-svn import stuff, but it's giving me an error: bzr: ERROR: exceptions.ImportError: cannot import name format | 22:49 |
| lifeless | are you installing by packages, or from source? | 22:50 |
| lifeless | what does 'bzr plugins' say - is svn listed? | 22:50 |
| KhaZ | From package. Gentoo's emerge, to be precise. | 22:50 |
| KhaZ | No module named send | 22:50 |
| KhaZ | Unable to load plugin 'svn' from '/usr/lib64/python2.6/site-packages/bzrlib/plugins' | 22:50 |
| lifeless | odd | 22:51 |
| lifeless | that should write a back trace to ~/.bzr.log | 22:51 |
| KhaZ | There is more to it, but nothing suspicious except that ilne | 22:51 |
| KhaZ | What does it mean "no module named send"? That's no python module I know of. | 22:52 |
| KhaZ | easy_install doesn't know of it either. | 22:52 |
| lifeless | is there a backtrace in the log? | 22:53 |
| lifeless | about the plugin load failure? | 22:53 |
| lifeless | http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html | 22:58 |
| lifeless | bah, jamgone | 22:58 |
| lifeless | http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html | 22:58 |
| KhaZ | Ah, yeah, there is a log file there. Let me see. | 22:59 |
| === thumper is now known as thumper-afk | ||
| KhaZ | Yeah; apparently it's trying to load bzrlib.send and it doesn't exist | 22:59 |
| KhaZ | I tried that from a python interpreter, same thing. | 22:59 |
| lifeless | KhaZ: could you pastebin the trace please | 23:00 |
| KhaZ | Certainly. One moment. | 23:00 |
| KhaZ | Sorry about the delay: http://pastie.org/605095 | 23:02 |
| igc | morning | 23:02 |
| lifeless | KhaZ: what version of bzr do you have? | 23:03 |
| lifeless | KhaZ: I strongly suspect that its quite old - current versions have a bzrlib.send module | 23:03 |
| KhaZ | 1.15.1 | 23:04 |
| KhaZ | Is that old? | 23:04 |
| lifeless | current stable is 1.18, about to release 2.0 | 23:04 |
| lifeless | 1.15.1 isn't hugely old - 4 months or so. But the error you're getting says that your bzr-svn is mismatched with your bzr[lib] | 23:05 |
| KhaZ | Ah. Looks like Gentoo masks the recent versions | 23:05 |
| lifeless | hi igc | 23:05 |
| jam | lifeless: yeah, EOD for me | 23:05 |
| igc | lifeless: fast-import will handle multiple branches | 23:05 |
| jam | morning igc | 23:05 |
| igc | hi jam | 23:06 |
| jam | just started another download with the new pack-on-the-fly to see if it is any different | 23:06 |
| jam | I'm guessing not | 23:06 |
| lifeless | jam: I'll review and land stuff | 23:06 |
| jam | lifeless: sounds good | 23:06 |
| lifeless | http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html | 23:06 |
| igc | jam - do you have a moment for a very quick chat re installers? | 23:06 |
| igc | eithe online or Skype? | 23:06 |
| igc | jam: I want to know whether build-release.py is still used? | 23:07 |
| igc | jam: and whether I can test out the buildbot stuff on linux separately to packaging as an installer? | 23:07 |
| jam | igc: I don't use build-release anymore | 23:08 |
| jam | The last builds have been done purely with 'make installer-all' | 23:08 |
| igc | so it's obsolete? | 23:08 |
| jam | igc: yeah | 23:08 |
| jam | as of... 1 or 2 builds | 23:09 |
| jam | so not very obsolete | 23:09 |
| igc | ok | 23:09 |
| jam | I just made the transition | 23:09 |
| jam | I need to go now, and I haven't found my cell phone... sorry | 23:09 |
| igc | jam: do I need cygwin? | 23:09 |
| igc | jam: np | 23:09 |
| jam | igc: you need 'make' etc, cygwin being the easiest way to get it | 23:09 |
| igc | I have make | 23:09 |
| jam | I generally install cygwin + gcc+mingw32 | 23:09 |
| jam | for building for py2.4 and 2.5 | 23:10 |
| igc | ok | 23:10 |
| jam | I've started using VS 2008 for py2.6 ,though not on Kerguelen IIRC | 23:10 |
| jam | lifeless: on this transmission, my windows seems to be down to 64k | 23:10 |
| jam | and I'm still getting up-and-down on the transmission | 23:10 |
| igc | jam: ok bye for now - I'll email any other questions | 23:10 |
| jam | k | 23:11 |
| jam | igc: also 'python setup.py -c mingw32' | 23:11 |
| jam | is good to know about | 23:11 |
| jam | but there is also a 'disutils.cfg' or something like that you can set up | 23:11 |
| jam | so that it is always enabled | 23:11 |
| jam | I certainly recommend digging up my email to canonical-bazaar | 23:11 |
| jam | circa, a few months ago | 23:11 |
| jam | probably 'win32' in the title | 23:11 |
| igc | ok | 23:12 |
| lifeless | igc: 08:12:56 52000/133780 commits processed at 414/minute (:52000) | 23:13 |
| lifeless | the timing data | 23:13 |
| lifeless | is that over the last 1K | 23:13 |
| lifeless | or total time/total revs done | 23:14 |
| igc | lifeless: averaged since the start - the last minute will be a lot worse than that | 23:14 |
| lifeless | it would be interesting to see that difference | 23:14 |
| igc | lifeless: compare the time for 51k vs 52k | 23:14 |
| lifeless | be a good clue about where it goes south | 23:14 |
| lifeless | 08:08:24 51000/133780 commits processed at 421/minute (:51000) | 23:15 |
| lifeless | 05:45:33 Collecting statistics ... | 23:15 |
| lifeless | 06:07:24 Starting import of 133780 commits ... | 23:15 |
| lifeless | 06:07:31 1000/133780 commits processed at 7707/minute (:1000) | 23:15 |
| igc | lifeless: it will go south at 80k and 120k | 23:15 |
| jam | igc: it looks like the thread is 'More work on win32 installers' though it seems to have a lot more posts than I remembered | 23:15 |
| lifeless | igc: thats when you're doing a full pack yes? | 23:16 |
| lifeless | 13 minutes or so @ 40K | 23:16 |
| igc | jam: do we have the archives online? | 23:17 |
| jam | igc: I believe so | 23:17 |
| igc | lifeless: yep - full pack every 4 checkpoints by default and we checkpoint every 10k | 23:17 |
| igc | lifeless: both numbers are controllable via options | 23:17 |
| igc | jam: I'll look - thanks | 23:18 |
| lifeless | yeah, I don't think they are the problem | 23:18 |
| lifeless | but having a weighted or windowed average would be really useful | 23:18 |
| lifeless | how would you feel about that | 23:18 |
| jam | lifeless: I have a couple of pcap files now. New download was much slower (14m vs 9m) | 23:19 |
| jam | anyway, really away | 23:19 |
| igc | lifeless: I'm ok with whatever stats make sense | 23:19 |
| igc | lifeless: as a comparison, the kernel with 145k revisions took 13 hours | 23:20 |
| lifeless | igc: right, but does this make sense to you ?:P | 23:21 |
| lifeless | igc: specificalyl, changing at X/minute | 23:21 |
| lifeless | to | 23:21 |
| lifeless | in $total_time[X/minute], last 1000 in $minutes[Y/minute] | 23:22 |
| lifeless | or something similar | 23:22 |
| igc | sure | 23:22 |
| lifeless | because I think its actually doing 250/minute | 23:22 |
| lifeless | which is hugely slower and more representative [it also suggests something to be looking into] | 23:22 |
| igc | lifeless: kernel pack times fyi ... | 23:24 |
| igc | 40k: 19 minutes; 80k: 49 minutes; 120k: 108 minutes | 23:24 |
| igc | 145k: 90 minutes | 23:25 |
| igc | so 3.5 hours of the 13 in pack | 23:25 |
| lifeless | 08:12:56 52000/133780 commits processed at 414/minute (:52000) | 23:31 |
| lifeless | 08:23:55 53000/133780 commits processed at 388/minute (:53000) | 23:31 |
| lifeless | 1000 in 11m - < 100/minute | 23:31 |
| poolie | hi all | 23:37 |
| lifeless | hi | 23:38 |
| poolie | jam, hi? | 23:39 |
| moldy | hi | 23:46 |
| moldy | what exactly is the effect of being a "parent" branch of another branch? | 23:46 |
| igc | hi poolie | 23:46 |
| igc | moldy: being a parent doesn't affect a branch | 23:46 |
| igc | moldy: having a parent means there's a default location to pull from (for example) | 23:47 |
| igc | moldy: and commands like 'bzr diff -rsubmit:' show you what's changed via you started on this branch | 23:48 |
| igc | s/via/since/ | 23:48 |
| moldy | igc: it has no effect on the way the history is kept, right? | 23:48 |
| igc | moldy: right | 23:49 |
| igc | hi emmajane | 23:50 |
| moldy | igc: ok, thanks | 23:50 |
| igc | how is/was the conference? | 23:50 |
| emmajane | igc, hey | 23:50 |
| emmajane | igc, it's going well. I did my presentation today and people seemed to like it, so that's always good. | 23:50 |
| emmajane | two more days. | 23:50 |
| igc | emmajane: well done | 23:51 |
| emmajane | igc, thanks :) | 23:51 |
| igc | emmajane: square-dancing vs php right? | 23:51 |
| emmajane | igc, aye :) | 23:51 |
| emmajane | igc, at 9AM | 23:51 |
| igc | emmajane: it's never too early for square dancing :-) | 23:52 |
| igc | php on the other hand ... | 23:52 |
| emmajane | igc, that's what i thought too :) | 23:52 |
| emmajane | igc, people thought I was completely nutters but then decided I might be right. | 23:52 |
| * fullermd glances over at IRC from his PHP-writing... | 23:53 | |
| lifeless | fullermd: feeling dirty yet? | 23:53 |
| fullermd | Yet? Was it supposed to go on hiatus at some point? | 23:53 |
| * emmajane chuckles | 23:53 | |
| moldy | i have 2 branches that, according to bzr, "share no common ancester". what is the right way to make one branch the ancestor of the other? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!