| === sidnei_ is now known as sidnei | ||
| === mwhudson__ is now known as mwhudson | ||
| spiv | Hmm, babune does seem to show a bit of a speed increase in the test suite, yay (and also from the Branch.open improvement from Dublin) | 01:27 |
|---|---|---|
| spiv | Since before Dublin looks like its down to ~21min from ~24min, even though the test count has increased a bit. :) | 01:28 |
| poolie_ | hi spiv | 01:46 |
| poolie_ | that is indeed pretty cool | 01:46 |
| sidnei | hey poolie, how easy is it to split a branch while keeping history? | 02:18 |
| sidnei | #501828 | 02:19 |
| sidnei | https://bugs.launchpad.net/graphite/+bug/501828 | 02:20 |
| ubot5` | Ubuntu bug 501828 in Graphite 1.0 "Create separate branches for the webapp, carbon, and whisper" [Low,Triaged] | 02:20 |
| lifeless | poolie_: btw, just doing an experiment | 02:25 |
| lifeless | poolie_: bzr selftest --parallel=fork on my new desktop - looks like it will complete in ~ 3 minutes | 02:26 |
| lifeless | poolie_: its causing writes to the disk of 1 and 2 MB/s which is a noticable amount (especially considering most things are expected to be deleted and never hit disk) | 02:27 |
| spiv | lifeless: yeah, I've noticed that, haven't tracked it down yet | 02:27 |
| spiv | (I haven't really spent much time looking either) | 02:27 |
| lifeless | hmm, forgot --no-plugins | 02:27 |
| lifeless | 3m8 seconds, 27172 tests | 02:28 |
| spiv | There was an issue where some tests would cause writes to ~/.bzr.log, but that's fixed | 02:28 |
| spiv | lifeless: :) | 02:28 |
| lifeless | huh | 02:30 |
| lifeless | 'failed to open trace file:[Errno 12] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file' | 02:31 |
| lifeless | test stipple | 02:31 |
| lifeless | andhow, --no-plugins timing, 2m33s 23794 tests. | 02:31 |
| spiv | Yeah, that's fallout from said fix. | 02:31 |
| lifeless | s/and/any/ | 02:31 |
| lifeless | s/12/13/ | 02:31 |
| spiv | lifeless: BZR_PLUGIN_PATH=-site is my usual, includes core plugins | 02:32 |
| lifeless | want a run with that? | 02:32 |
| spiv | Why not, it won't take long ;) | 02:32 |
| lifeless | :) | 02:32 |
| lifeless | I wonder if gnome-terminal is becoming a limiting factor | 02:33 |
| lifeless | those lazr.restfulclient errors are really annoying | 02:35 |
| lifeless | 2m52s 26708 tests | 02:35 |
| spiv | Ah right, weave_fmt would be the bulk of the extra tests.. | 02:36 |
| spiv | lifeless: so 155 tests/second, not too bad. | 02:38 |
| lifeless | /8 to get tests-per-process-per-second | 02:38 |
| lifeless | 19 or so | 02:39 |
| lifeless | 2m54s in uxterm, and I was fiddling with things, - I remember we clamp our terminal IO now that I think about it :) | 02:39 |
| poolie_ | lifeless, it's about 4 minutes on my laptop | 02:45 |
| poolie_ | which lazr restfulclient errors? | 02:45 |
| poolie_ | using a tmpfs will help more | 02:45 |
| lifeless | userwarning: modjule test was already imported from <path.pyx> but <different path> is being added to sys.path | 02:45 |
| poolie_ | i think some of it is that ext4 still flushes directory creation/deletion to disk | 02:45 |
| poolie_ | even if it could be shortcircuited | 02:46 |
| lifeless | poolie_: interestingly enough, I see near-full use of my 8 cores | 02:46 |
| lifeless | poolie_: for you be 25% slower, but with 4 cores, raises some interesting questions | 02:46 |
| lifeless | poolie_: 32 or 64 bit environment ? | 02:46 |
| poolie_ | 64 | 02:47 |
| lifeless | huh | 02:47 |
| poolie_ | i haven't precisely measured it recently | 02:47 |
| lifeless | fascinating | 02:47 |
| poolie_ | it's single digit minutes | 02:47 |
| poolie_ | by contrast to about an hour on bellany :) | 02:47 |
| lifeless | naive math would suggest 6 minutes (*2 for 1/2 the cores) | 02:47 |
| lifeless | do you have an ssd? | 02:48 |
| poolie_ | yes | 02:48 |
| lifeless | that may be part of it, but we don't fsync so I wouldn't have expected it to block | 02:48 |
| spiv | But there certainly is a lot of disk IO for something that should do net I/O of approx 0 bytes... | 02:49 |
| === poolie_ is now known as poolie | ||
| === ubot5` is now known as ubot5 | ||
| poolie | lifeless, thanks for that mail review | 06:05 |
| vila | poolie: standup ? | 06:05 |
| vila | hi all ! | 06:05 |
| poolie | vila, oh, now? | 06:06 |
| poolie | i'm confused | 06:06 |
| vila | no ? | 06:06 |
| poolie | it's only 0600utc, that seems too earl | 06:06 |
| vila | ghaa, I'm the one confused then >-/ | 06:06 |
| poolie | i have it on my calendar for 2h from now | 06:07 |
| vila | I won't be able to attend at 0800 UTC | 06:07 |
| poolie | spiv, what happens next with https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634 | 06:07 |
| vila | which probably explains my confusion | 06:07 |
| spiv | poolie: the pre-req branch gets landed, in theory by the time I wake up tomorrow | 06:09 |
| poolie | vila, well, i sent mail last week with that time | 06:10 |
| poolie | can you reply with an alternative? | 06:10 |
| spiv | poolie: oh, and I guess I need to find the CSS class to use to address your tweak! :) | 06:11 |
| poolie | spiv, rockin, and then it's unblocked? | 06:11 |
| poolie | that'd be good | 06:11 |
| poolie | and also the feature flag name, if you didn't already | 06:11 |
| spiv | poolie: I think so, I'll certainly poke folks on #launchpad-dev to get it reviewed and hopefully landed | 06:12 |
| vila | poolie: yes, sorry, dunno why I kept 0800 my time instead of UTC | 06:12 |
| spiv | poolie: hmm, the feature flag is already “code.ajax_revision_diffs.enabled” | 06:13 |
| poolie | oh great | 06:13 |
| poolie | maybe i was out of date | 06:13 |
| spiv | Oh, maybe not, maybe I'm confusing the syntax? | 06:13 |
| spiv | Certainly the last time I tested it I put code.ajax_revision_diffs.enabled into +feature-rules and it worked! | 06:14 |
| poolie | ah | 06:14 |
| poolie | it's right in the tal but it's wrong in flags.py | 06:14 |
| poolie | so, you'll get a warning, and it won't be documented properly | 06:14 |
| spiv | Ah, yes, that'd be it. | 06:15 |
| fullermd | vila: Still campaigning for the Paris Meridian? :p | 06:15 |
| poolie | well, earlier is certainly fine with me, basically you need to fight it out with other people in europe | 06:16 |
| vila | fullermd: never resign ! | 06:23 |
| vila | poolie: yes :-} | 06:24 |
| Riddell | good morning Bazaar | 07:03 |
| jam | morning all | 07:04 |
| jam | vila: aren't we doing the standup today? | 07:05 |
| Riddell | no poolie or spiv either? | 07:06 |
| jam | I see poolie was here 45min ago | 07:08 |
| jam | not sure what happened | 07:08 |
| Riddell | well I can go back to sleep for half an hour then :) | 07:09 |
| oier | hi | 07:12 |
| oier | I am not sure if I am on the correct channel, but I have problems using bzr builder (the recipes in launchpad to use dailys) | 07:13 |
| oier | the problem is that I get translations exported automatically to a branch but I don't know how to merge it in the recipe | 07:14 |
| oier | if I use nest or nest-part it creates a po/po directory, which is useless | 07:14 |
| spiv | oier: this channel and/or #launchpad are good channels. | 07:14 |
| oier | and merge doesn't work because the branches are unrelated | 07:14 |
| spiv | oier: which branches? | 07:15 |
| jam | hey spiv, have you seen poolie around? I thought we switched the standup to 15min ago | 07:15 |
| oier | lp:indicator-bug and lp:~oier/indicator-bug/translations | 07:16 |
| spiv | jam: based on chatter in this channel an hour or so ago I thought it was in 45min time! | 07:16 |
| oier | in trunk I have a po directory which contains the po file, the translations branch is a po directory with the translated po files | 07:16 |
| jam | spiv: yeah, looks like it, let me check the mail thread again | 07:17 |
| spiv | oier: ah, hmm | 07:17 |
| jam | spiv: yeah, martin's last message was 8:00UTC Tuesdays | 07:17 |
| jam | I didn't pay enough attention to the actual post, vs what I felt was consensus. stupid timezones being confusing | 07:18 |
| spiv | oier: I don't think build recipes can do that atm :( | 07:18 |
| spiv | jam: agreed! | 07:18 |
| jam | so jr can sleep 40 more minutes | 07:19 |
| oier | i found a similar bug report where the status is fix released https://bugs.launchpad.net/bzr-builder/+bug/515731 | 07:19 |
| ubot5 | Ubuntu bug 515731 in bzr-builder "Support merge of two branches that have no common ancestor" [High,Fix released] | 07:19 |
| spiv | oier: as a workaround you could nest or nest-part the translations into a new directory and then make a branch of lp:indicator-bug that tweaks debian/rules to move the contents of that directory into po/ before doing anything else | 07:19 |
| spiv | oier: yeah, that bug is what nest-part was added for, but it turns out not to address every case | 07:20 |
| spiv | oier: like yours :/ | 07:20 |
| spiv | oier: probably best to file a new bug, reference that one | 07:21 |
| spiv | oier: maybe it'll be marked as a dupe, but that's ok. | 07:21 |
| oier | but isn't the fix for merging unrelated branches released? | 07:21 |
| oier | it should be working according to it, or? https://code.launchpad.net/~jelmer/bzr-builder/merge-unrelated/+merge/51425 | 07:25 |
| spiv | oier: hmm, I'm not sure that that fix would deal with the case where both sides add the same directory, like your case :( | 07:30 |
| === pjdc_ is now known as pjdc | ||
| jam | Riddell: hey, we're starting to get together now | 08:01 |
| spiv | poolie: we were just talking about you :) | 08:02 |
| poolie | hi | 08:03 |
| spiv | (on mumble) | 08:03 |
| poolie | hm :) | 08:03 |
| poolie | pulseaudio crashed! | 08:04 |
| poolie | :/ | 08:06 |
| jam | poolie: still down? | 08:08 |
| poolie | yeah | 08:08 |
| poolie | going to restart my session | 08:08 |
| jam | k | 08:08 |
| === Topic unset by poolie on #bzr | ||
| poolie | gah | 08:30 |
| === poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell and jam | UDD failures: 400 | ||
| jam | spiv: do you want to do PP on your last week ? | 08:31 |
| spiv | jam: not sure! I wouldn't be around to follow-up anything that lives beyond that week obviously. I suspect I'll be hurrying to close off as much of my current work as possible first. | 08:32 |
| spiv | It might still be a good idea though. | 08:33 |
| jam | spiv: how about you take next week | 08:33 |
| jam | seems like a lot of people are otherwise away | 08:33 |
| spiv | Ok, sure. | 08:33 |
| * spiv -> gone for the night. | 08:33 | |
| jam | spiv: have a good night | 08:33 |
| jam | spiv: I had the weeks mixed. vila is here next week, but not the 25th. so for now I have you on the 25th. | 08:35 |
| jam | We can also swap that out if we need to. | 08:35 |
| maxb | spiv: On the UDD append-revisions-only issue, do you think it's worth backing out the change and manually unblocking the resulting failed imports, or is fixing it going to be easier than it seems? | 09:05 |
| poolie | hi maxb | 09:43 |
| maxb | morning | 09:44 |
| jam | maxb: he's away for the night. I think he wants to try the 'simple' fix first, and if that doesn't work, then just back out the whole thing | 10:09 |
| jam | Riddell: you wanted to pair on some reviews | 10:09 |
| jam | let me know when you want to do so | 10:09 |
| Riddell | jam: can do if you're doing them now | 10:09 |
| Riddell | jam: mumble? | 10:09 |
| jam | Riddell: I wasn't starting them, just thinking to plan it out. But I'm happy to get on mumble with you now | 10:10 |
| jam | maxb: I wanted to find out about your "check-up-to-date" stuff if you have it | 10:10 |
| Riddell | jam: well any time is good for me including now | 10:10 |
| maxb | check-up-to-date? | 10:11 |
| jam | maxb: check if a udd packaging branch is up-to-date vs its deb packages | 10:11 |
| jam | jelmer had a branch | 10:11 |
| jam | which he said you improved by removing launchpadlib | 10:11 |
| maxb | Oh, that was mainly the discovery of how to successfully call the lp api without launchpadlib | 10:11 |
| maxb | At the time, it involved mocking up a fake OAuth header | 10:11 |
| jam | maxb: well, it was 'real' enough to get past launchpad, right? | 10:12 |
| maxb | Nowadays, the squid has been fixed, and shouldn't even require that | 10:12 |
| jam | maxb: I'd like to make sure that stuff doesn't get lost | 10:12 |
| jam | so even if it is only a hint in the right direction, it would be nice to see | 10:12 |
| maxb | http://paste.ubuntu.com/642517/ | 10:14 |
| maxb | So, if you safe that as a script, and run 'foo ubuntu/+archive/primary bzr' you'll get a familiar looking listing with only one http roundtrip | 10:14 |
| jam | maxb: so the issue with oauth... LP wants oauth for authenticated users, but for anonymous queries it shouldn't require it? | 10:15 |
| maxb | and no launchpadlib in sight | 10:15 |
| maxb | Correct - *shouldn't* - but at the time, anonymous API access was being partially broken by the squid | 10:15 |
| maxb | That, however, has since been fixed | 10:16 |
| jam | maxb: yeah, you have the oath stuff commented out in your paste, and the bzr check worked fine for me | 10:26 |
| jam | and nicely fast, too | 10:27 |
| maxb | The lazr.restful collections stuff will paginate the response at a default batch size of 75 items, I believe. | 10:28 |
| jam | [needsfixing] this is a change that is required | 10:28 |
| jam | [needsinfo] this is a change that you're asking for questions | 10:28 |
| poolie | lp is a bit confused about whether it's readonly atm | 10:29 |
| poolie | should be fixed soon | 10:29 |
| maxb | However, for the kinds of requests we need to make, we should be able to phrase the query parameters such that we are only expecting a collection of zero or one items, and thus avoid needing to reimplement any of lazr.restfulclient's paging navigation behaviour | 10:29 |
| jam | poolie: by not having a "readonly" mode, right? | 10:30 |
| jam | (just being down completely) | 10:30 |
| poolie | no, it seems to have lost people's sessions | 10:30 |
| arnetheduck | hi, I would like to replay a complete bzr history for a particular branch, running a script on the working tree for every commit (much like what git filter-branch) allows you to do...I haven't found any existing command that will do this in a simple way (I'd like to preseve commit authors, merges, renames etc), so I'm guessing I'll have to do a plugin myself - could anyone supply some useful pointers for where to look? | 10:38 |
| poolie | hi arnetheduck | 10:40 |
| poolie | just the mainline or every single revision? | 10:40 |
| poolie | oh, you want to change the tree along the way? | 10:40 |
| arnetheduck | poolie, every single revision and with a script applied for each one | 10:45 |
| poolie | probably starting a plugin to do it would be good | 10:45 |
| poolie | something like branch.iter_merge_sorted_revisions() | 10:46 |
| poolie | then for each | 10:46 |
| arnetheduck | (fixing line endings =) | 10:46 |
| poolie | wt.update(revision) | 10:46 |
| poolie | then, i guess, commit it to a separate branch | 10:47 |
| poolie | you could perhaps look at adding this into the bzr-rewrite plugin | 10:47 |
| arnetheduck | yeah, I had a quick look at that one but it wasn't obvious how to record renames for example and how to assign (one or more) parent revisions to a commit etc | 10:48 |
| arnetheduck | I'm guessing iter_merge_sorted_revisions guarantees that all commits leading up to a particular revision have been visited? | 10:50 |
| arnetheduck | getting a working tree looked simple enough so then the biggest problem would be to get the commit properties right | 10:51 |
| poolie | yes | 10:52 |
| poolie | the nice thing if you modify the working tree is that it should keep the same metadata for renames etc | 10:53 |
| poolie | i thought bzr rewrite did this though | 10:53 |
| poolie | if you come up with any kind of reusable patch that does this i'd really like to help merge it | 10:53 |
| jam | poolie: we have "bzr fast-import-filter" | 10:53 |
| jam | I don't think we have anything for rewrite yet | 10:53 |
| poolie | Riddell, thanks for the review | 10:54 |
| jam | arnetheduck: "bzr fast-export content.fi && cat content.fi | bzr fast-import-filter | bzr fast-import" I *think* works. | 10:54 |
| arnetheduck | jam, fast-import-filter only allows filtering the file list, not contents, afaict | 10:57 |
| jam | arnetheduck: probably | 10:57 |
| jam | that is the only filtering that I'm currently aware of | 10:57 |
| jam | I think adding it to replay/rebase/whatever looks good | 10:57 |
| jam | arnetheduck: did you end up signing the contributor agreement? We'd like to land: https://code.launchpad.net/~arnetheduck/bzr/bzr-log-author/+merge/63751 | 10:58 |
| arnetheduck | jam, yes I did (but I think I might have misspelled your email when cc:ing)...martin pool has a copy though. | 10:58 |
| jam | arnetheduck: no problems on my side, and martin may have already added you to the approved list. I just figured it was quickest to just ask you :) | 10:59 |
| jam | yes, martin has marked it as such | 11:00 |
| jam | I was just waiting for the script to finish running that verified it | 11:00 |
| arnetheduck | so, a) how do I add a rename to a commit (code-wise...it looked messy on my first perusal of bzr commit/bzr rename) and b) apart from properties (incidentally the ones searched by log-author=), is there anything else that should be recorded? | 11:01 |
| poolie | wt.rename ought to do it | 11:01 |
| poolie | if you don't want to add new renames to the tree, you shouldn't need to worry | 11:02 |
| poolie | the other thing you may need to take care to preserve is the revision DAG | 11:02 |
| === hunger_ is now known as hunger | ||
| poolie | in particluar if you're rewriting them you'll need to set the tree revision parents to the newly rewritte ones | 11:02 |
| arnetheduck | yeah, I'm guessing i should be committing to a separate branch essentially creating a copy (with different commit id's) | 11:03 |
| arnetheduck | and the list of renames is available on the branch object? | 11:04 |
| jam | poolie: I think arnetheduck is re-creating the ability to replay a diff | 11:05 |
| jam | arnetheduck: I think you should try to use rewrite's code that already does that | 11:06 |
| arnetheduck | also - how close to this is the rewrite plugin? not that I put very much effort into it but I didn't immedeately understand what it did (code-wise) so I stopped reading...perhaps I should take a second look? | 11:06 |
| jam | arnetheduck: it should do 90% of the work for you, which is setting up a new tree that looks just like another tree but with a new source | 11:06 |
| poolie | jelmer will be back online tomorrow, i think, and could talk to you about it | 11:06 |
| poolie | right | 11:06 |
| jam | you just need to add a hook/etc to call your code | 11:06 |
| jam | with something that can mutate the tree content as well. | 11:06 |
| jam | from what I can tell "WorkingTreeRevisionRewriter" and "RebaseState1" are things to look at | 11:08 |
| arnetheduck | I think it was the references to "rebase" that scared me off...I've never quite understood why people would want to do that =) | 11:09 |
| jam | arnetheduck: it is essentially, create a revision with this diff applied to that revision | 11:09 |
| jam | which is pretty much what you are doing, with "this diff" being custom for your use case | 11:10 |
| Riddell | jam: lp:~jr/bzr/bzr-log-author | 11:10 |
| Riddell | jam: in bzrlib/log.py at "searchRE =" | 11:12 |
| arnetheduck | I'll have another look then, thanks | 11:15 |
| poolie | good night | 11:21 |
| jam | maxb: the other thing with your script, is that if it is fast enough we can easily put it in such that it happens whenever you access a given branch | 11:25 |
| jam | rather than having a separate command. | 11:25 |
| maxb | Or, at least whenever you branch/pull/update | 11:26 |
| jam | maxb: right. is there a way to filter by series? | 11:30 |
| jam | since when you go to "ubuntu/..." you know you want the latest 'oneiric', or whatever | 11:30 |
| jam | I'm just noticing that the returned data seems oddly sorted | 11:30 |
| jam | so I'm wondering if we can be sure we have the latest | 11:30 |
| jam | maybe it is always the latest in each pocket/series/whatever? | 11:30 |
| maxb | 'distro_series': '/ubuntu/natty', for example | 11:32 |
| Riddell | jam: https://code.launchpad.net/~gary-wilson/bzr-loom/docs/+merge/66826 looks like it's ready for merging, does loom use pqm or direct merges? | 11:32 |
| jam | Riddell: direct merges | 11:32 |
| Riddell | ok, I'll do that | 11:32 |
| maxb | jam: Given that we're filtering on the "Published" status, it will be the latest (except potentially you might get two if you hit the API at exactly the moment of a new publication, I think) | 11:33 |
| jam | maxb: but the "distro series" has to be a full URI... | 11:33 |
| * maxb hugs undocumented features :-) | 11:33 | |
| maxb | Also, technically "/ubuntu/natty" is an URI | 11:34 |
| jam | maxb: I imagine it matches whatever comes back in "distro_series_link" | 11:34 |
| jam | ah, I was just doing "natty" | 11:34 |
| jam | yeah, /ubuntu/natty | 11:34 |
| jam | works | 11:34 |
| jam | and seems to be quite a bit faster | 11:34 |
| maxb | jam: However, we won't be able to make this work so well for Debian, I think, since LP never actually sets Debian publications to the Published state, they remain Pending forever | 11:34 |
| jam | well, 2-300 ms faster | 11:34 |
| maxb | As such, we have no way to conveniently get just the most recent one | 11:35 |
| jam | there doesn't seem to be anything in "Pending" for bzr | 11:35 |
| jam | but that matches: https://launchpad.net/debian/+source/bzr | 11:36 |
| maxb | There's nothing "Pending" in ubuntu, there is in debian | 11:36 |
| maxb | Well, I suppose we always have the option of just setting ws.size to 1 and trusting the sort order to do something sensible | 11:37 |
| jam | maxb: I did a query for "Pending" with no distro_series, and it came back empty | 11:37 |
| jam | maxb: trusting the sort order to do something sensible.... | 11:37 |
| maxb | Did you also change the archive to debian/+archive/primary ? | 11:37 |
| jam | I don't have that kind of faith | 11:37 |
| jam | maxb: good point | 11:37 |
| maxb | https://launchpad.net/debian/+source/bzr/+publishinghistory for example | 11:37 |
| jam | the sort order does seem to be reverse debian sort order | 11:39 |
| jam | however, that means it mixes distro_series groups | 11:39 |
| jam | but that might be ok if we start restricting by that | 11:39 |
| maxb | There is also a pocket parameter on the API call | 11:40 |
| maxb | Takes a value like '"Backports"' | 11:40 |
| jam | right | 11:40 |
| jam | so if you grab "ubuntu/natty-proposed" we have to split that into a distro-series and a pocket, right? | 11:41 |
| maxb | right | 11:41 |
| jam | "lp:ubuntu/natty-proposed/bzr" | 11:41 |
| maxb | (or do a bunch more round trips to resolve that, which somewhat defeats the point) | 11:42 |
| jam | well, something small is ok, but I do notice that getting the debian results is quite a bit slower | 11:43 |
| jam | I presume because it asks the db to sort and get everything to just return new stuff | 11:43 |
| === mrevell is now known as mrevell-lunch | ||
| === jamestunnicliff_ is now known as jamestunnicliffe | ||
| jam | ugh, my home network just decided it wasn't going to route packets to the world anymore. So now I'm on "3g". but at least I'm online | 12:41 |
| === mrevell-lunch is now known as mrevell | ||
| indigo | in my dev branch, "bzr status" is showing an uncommitted merge, but I don't remember from what branch I merged. Is there some way to find out? | 13:32 |
| indigo | i know if i commit the changes, then the branch nick will be displayed in the log, but i'd like to know without committing. | 13:32 |
| maxb | If you have it, the GUI "bzr qlog" would be a simple way of seeing it | 13:36 |
| indigo | gui? what's that? ;) | 13:36 |
| fullermd | It's what you get when you spill coffee on your punch cards. | 13:37 |
| indigo | i thought it was a way to run more terminals at a higher resolution than supported on the console. | 13:37 |
| fullermd | 'stat -v' will give you the full list of revs pending; that might point you in the right direction. | 13:38 |
| fullermd | Also: "history | grep merge" :p | 13:38 |
| indigo | yeah, stat -v gives me the log messages and dates of the pending revs, but not the branch nick | 13:38 |
| indigo | i found the branch manually, but still i'd like to know for the future | 13:39 |
| fullermd | I've often believed that --show-ids should make stat show the revids of pending merge revs (though space concerns make it not entirely obvious how). That would let you point log at 'em. | 13:41 |
| fullermd | Some way to dump info about pending merges would be handy, to be sure. Of course, the nick may or may not really tell you anything useful. | 13:41 |
| indigo | garbage in, garbage out applies for sure | 13:42 |
| fullermd | Maybe WT_FORMAT++ should include a placeholder for "URL of pending merge"... | 13:43 |
| indigo | maybe, but i'd think if information would be available in a log after a commit (like the branch nick) there should be a way to get that information without committing | 13:44 |
| fullermd | Well, since the rev is in your local repo, you can show it with log. | 13:45 |
| indigo | how do i show it without committing it? | 13:45 |
| fullermd | Just a matter of finding the revid, which the CLI doesn't expose anywhere I know of. | 13:45 |
| indigo | ah. | 13:45 |
| indigo | i would say just changing stat -v to put the branch nick in the list of pending merges would be a good solution | 13:46 |
| fullermd | (which is why qlog can do it; it just looks at the revid in the internal WT structure and shows from it) | 13:46 |
| indigo | that's where i'd think to look for the information i want, anyway | 13:46 |
| fullermd | IWBNI(tm) the full complement of 'log' options were available for that list of pending merges. Alternately, a revspec/option for log to look directly at them from there. | 13:47 |
| fullermd | ('course, that also ties into the "standardize log-like options" pile too. Whee.) | 13:47 |
| indigo | it would, but i never would have thought to use "log" to look at things i haven't committed. | 13:48 |
| indigo | i always thought of "status" as a sort of "log" for uncomitted things. | 13:48 |
| fullermd | Anyway. I have to go yell at a client for screwing up their data. Again. | 13:48 |
| indigo | put those clients in their place | 13:49 |
| fullermd | I DO have a shovel just lying around... | 13:49 |
| * fullermd didn't say that out loud. | 13:49 | |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga-coffee | ||
| === zyga-coffee is now known as zyga | ||
| === medberry is now known as med_out | ||
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| vila | maxb: I'm about to announce 2.4b5, did you have troubles upgrading the ppas or is it just lack of time ? | 16:13 |
| vila | maxb: or may be you're waiting for sid ? | 16:15 |
| === zyga is now known as zyga-afk | ||
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| maxb | vila: Oh, whoops. I just failed to notice a release going on :-/ | 17:01 |
| maxb | I'd normally wait for sid, but do work to make sid happen faster | 17:01 |
| maxb | I suggest announcing, and barring unexpected problems, I'll sort the PPA tonight | 17:04 |
| jamdahl | I've got a storage efficiency question | 17:06 |
| jamdahl | I'm working on a plugin for Excel that does version control for workbooks and VBA code using bazaar | 17:07 |
| jamdahl | the code is exported to text files for easy diff-ing, but the excel files themselves are zipped | 17:07 |
| jamdahl | looking at the size of my repos, it looks like bazaar is can't handle file deltas for zip files and instead ends up storing the equivalent of a whole new copy of the excel file with each commit | 17:08 |
| jamdahl | if I switch to a non-binary excel format, like xml, am I going to get more efficient storage? | 17:09 |
| jamdahl | even though each each individual xml excel file will be bigger than xlsm/xlsx | 17:10 |
| maxb | Hmm, it's looking like oneiric's python has broken bzr test stuff | 17:36 |
| maxb | A number of failures in the daily PPA | 17:36 |
| dobey | hey all. i have some questions about locking branches inside a process using bzrlib. is there a way to lock a branch, do everything i want with it, and then unlock it, with bzrlib, or do i *have* to unlock/lock around certain actions like merge and commit? | 17:39 |
| indigo | jamdahl: if the diffs are small, i believe the answer is "yes" | 18:02 |
| indigo | jamdahl: actually, maybe bzr does do binary deltas, but if you are zipping your files, then you will never get small diffs | 18:04 |
| indigo | jamdahl: https://lists.ubuntu.com/archives/bazaar/2006q4/019182.html | 18:05 |
| jamdahl | To be clear, I'm not zipping the files, excel format from 2007 on is a zip file. :P | 18:14 |
| jamdahl | really what I'm considering is unzipping stuff before I pass it to Bazaar | 18:14 |
| jamdahl | Running an expirment with that now, but unforunately the tons of xml files are completely choking the diff even with small changes :( | 18:15 |
| dobey | jamdahl: i'm guessing that the xml bits of msoffice/openoffice documents are not particularly well formatted | 18:20 |
| jamdahl | Opened up one of the changed files. It's all on one line... | 18:21 |
| jamdahl | 137kb of xml on one line | 18:22 |
| dobey | yep | 18:23 |
| ZyX-I | Hello. All links for 2.4 beta release on http://wiki.bazaar.canonical.com/WindowsDownloads are broken. | 18:24 |
| ZyX-I | Is there a msi installer for bzr somewhere or something other that does not require user interaction? | 18:27 |
| jamdahl | unzipping the excel files is definitely not going to work with the lousy xml formatting. Any ideas on how to avoid the storage problem? | 18:45 |
| dobey | jamdahl: i must have missed it; what is your problem exactly? | 18:45 |
| jamdahl | I've written a plugin to do version control for excel spreadsheets + the VBA inside them | 18:49 |
| jamdahl | the VBA code exports to text files that bazaar plays nice with | 18:49 |
| jamdahl | but every time the sheet changes, the whole new excel file (or close to it) gets stored because its a zip file | 18:50 |
| jamdahl | so every time I do a new commit, the repo increases in size pretty close to whatever the size of the spreadsheet is... Not particularly good | 18:50 |
| dobey | ah | 18:51 |
| dobey | unfortunately, i think the only solutions to that are "don't use msoffice" or "don't store msoffice files in bzr" :/ | 18:52 |
| dobey | unless maybe you can also write a filter or something, so that when the office file gets saved, you format the XML nicely, so you don't get this problem | 18:52 |
| jamdahl | unfortunately, it would be a pain in the ass to go into 20+ xml files for each excel document and reformat that every time after they are changed :( | 18:54 |
| dobey | jamdahl: by "filter or something" i meant "extension to excel, such that it happens when the file is saved" | 18:57 |
| fullermd | There is theoretically infrastructure in bzr to allow writing a plugin that does that for you. There's occasional talk about how to do so. | 18:57 |
| dobey | or you could do it with a bzr plug-in probably | 18:58 |
| jamdahl | development of a bzr plugin is beyond my current coding capabilities | 19:02 |
| jamdahl | I'm not terribly experienced in anything but VBA right now | 19:02 |
| jamdahl | hmmm, expirimenting with the older excel format | 19:05 |
| jamdahl | I don't think the older ones are zipped | 19:05 |
| jamdahl | gah, older format breaks too much functionality | 19:07 |
| dobey | the older format is a binary | 19:16 |
| dobey | a funky majestic binary | 19:16 |
| dobey | of course, a lot of the new format is just <xmltag>streamofbinary</xmltag> | 19:16 |
| dobey | lovely insanity, that | 19:16 |
| * dobey wonders who to talk to about bzrlib.branch.Branch locking, though | 19:18 | |
| jamdahl | binary isn't as bad as zipped :P | 19:19 |
| dobey | zip files are binaries | 19:20 |
| jamdahl | Zip files are a particularly kind of binaries that suck for deltas due to compression algorithms | 19:21 |
| jamdahl | But the truth is, (most?, many?) binary files don't binary diff that well anyway. Frequently they are compressed, which means a modification near the beginning tends to have a chain reaction over a large distance (possibly the whole rest of the file). | 19:22 |
| jamdahl | that's a quote from the page indigo linked | 19:22 |
| jamdahl | so a non-compressed binary is less-than-ideal, but better than a compressed one | 19:22 |
| dobey | well often, there's a header, and then the compressed content | 19:22 |
| dobey | and if anything changes in the content, it gets recompressed, so the whole block changes | 19:23 |
| jamdahl | Right now what I'm trying is the new binary excel format which is zipped binaries | 19:24 |
| jamdahl | I don't think the binaries that are zipped are themselves compressed | 19:24 |
| dobey | well, a lot of the data in them is probably compressed | 19:24 |
| jamdahl | Doesn't make much sense to double-compress | 19:26 |
| jamdahl | It wouldn't speak well of zip compression if that actually saved any space | 19:26 |
| === yofel_ is now known as yofel | ||
| maxb | Hrm. The armel-cross-toolchain-base UDD import really is interestingly broken | 19:39 |
| maxb | The importer has reimported several package versions multiple times onto the maverick branch | 19:40 |
| poolie | hi all | 21:48 |
| Riddell | g'day poolie | 22:43 |
| maxb | Riddell: Hi. I think I've found a problem with the new signature checking changes to log - I've had bzr qlog crashing on me because RemoteRepository doesn't implement verify_revision | 23:04 |
| maxb | I need to file a proper bug still - but since you're around :-) | 23:04 |
| maxb | or not | 23:04 |
| spiv | maxb: hmm, that suggests that a) we're missing per_repo tests for verify_revision, and b) that a quick _ensure_real shim would deal with the problem for now. | 23:13 |
| === medberry is now known as med_out | ||
| mgz | ...how do I make hg give me something I can attach to a bug? their bundles aren't very friendly. | 23:52 |
| mgz | I'm trying to get an upstream fix for bug 809048 accepted. | 23:55 |
| ubot5 | Launchpad bug 809048 in bzr (Ubuntu) "bzr crashed with AttributeError in stopTest(): '_TypeEqualityDict' object has no attribute 'clear'" [High,Confirmed] https://launchpad.net/bugs/809048 | 23:55 |
| lifeless | mgz: hg diff | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!