=== sidnei_ is now known as sidnei
=== mwhudson__ is now known as mwhudson
[01:27] <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:28] <spiv> Since before Dublin looks like its down to ~21min from ~24min, even though the test count has increased a bit. :)
[01:46] <poolie_> hi spiv
[01:46] <poolie_> that is indeed pretty cool
[02:18] <sidnei> hey poolie, how easy is it to split a branch while keeping history?
[02:19] <sidnei> #501828
[02:20] <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:25] <lifeless> poolie_: btw, just doing an experiment
[02:26] <lifeless> poolie_: bzr selftest --parallel=fork on my new desktop - looks like it will complete in ~ 3 minutes
[02:27] <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:28] <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:30] <lifeless> huh
[02:31] <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:32] <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:33] <lifeless> I wonder if gnome-terminal is becoming a limiting factor
[02:35] <lifeless> those lazr.restfulclient errors are really annoying
[02:35] <lifeless> 2m52s 26708 tests
[02:36] <spiv> Ah right, weave_fmt would be the bulk of the extra tests..
[02:38] <spiv> lifeless: so 155 tests/second, not too bad.
[02:38] <lifeless>  /8 to get tests-per-process-per-second
[02:39] <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:45] <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:46] <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:47] <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:48] <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:49] <spiv> But there certainly is a lot of disk IO for something that should do net I/O of approx 0 bytes...
=== poolie_ is now known as poolie
=== ubot5` is now known as ubot5
[06:05] <poolie> lifeless, thanks for that mail review
[06:05] <vila> poolie: standup ?
[06:05] <vila> hi all !
[06:06] <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:07] <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:09] <spiv> poolie: the pre-req branch gets landed, in theory by the time I wake up tomorrow
[06:10] <poolie> vila, well, i sent mail last week with that time
[06:10] <poolie> can you reply with an alternative?
[06:11] <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:12] <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:13] <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:14] <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:15] <spiv> Ah, yes, that'd be it.
[06:15] <fullermd> vila: Still campaigning for the Paris Meridian?   :p
[06:16] <poolie> well, earlier is certainly fine with me, basically you need to fight it out with other people in europe
[06:23] <vila> fullermd: never resign !
[06:24] <vila> poolie: yes :-}
[07:03] <Riddell> good morning Bazaar
[07:04] <jam> morning all
[07:05] <jam> vila: aren't we doing the standup today?
[07:06] <Riddell> no poolie or spiv either?
[07:08] <jam> I see poolie was here 45min ago
[07:08] <jam> not sure what happened
[07:09] <Riddell> well I can go back to sleep for half an hour then :)
[07:12] <oier> hi
[07:13] <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:14] <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:15] <spiv> oier: which branches?
[07:15] <jam> hey spiv, have you seen poolie around? I thought we switched the standup to 15min ago
[07:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:25] <oier> it should be working according to it, or? https://code.launchpad.net/~jelmer/bzr-builder/merge-unrelated/+merge/51425
[07:30] <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 :(
=== pjdc_ is now known as pjdc
[08:01] <jam> Riddell: hey, we're starting to get together now
[08:02] <spiv> poolie: we were just talking about you :)
[08:03] <poolie> hi
[08:03] <spiv> (on mumble)
[08:03] <poolie> hm :)
[08:04] <poolie> pulseaudio crashed!
[08:06] <poolie> :/
[08:08] <jam> poolie: still down?
[08:08] <poolie> yeah
[08:08] <poolie> going to restart my session
[08:08] <jam> k
=== Topic unset by poolie on #bzr
[08:30] <poolie> gah
=== 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
[08:31] <jam> spiv: do you want to do PP on your last week ?
[08:32] <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:33] <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:35] <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.
[09:05] <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:43] <poolie> hi maxb
[09:44] <maxb> morning
[10:09] <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:10] <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:11] <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:12] <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:14] <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:15] <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:16] <maxb> That, however, has since been fixed
[10:26] <jam> maxb: yeah, you have the oath stuff commented out in your paste, and the bzr check worked fine for me
[10:27] <jam> and nicely fast, too
[10:28] <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:29] <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:30] <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:38] <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:40] <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:45] <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:46] <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:47] <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:48] <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:50] <arnetheduck> I'm guessing iter_merge_sorted_revisions guarantees that all commits leading up to a particular revision have been visited?
[10:51] <arnetheduck> getting a working tree looked simple enough so then the biggest problem would be to get the commit properties right
[10:52] <poolie> yes
[10:53] <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:54] <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:57] <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:58] <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:59] <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 :)
[11:00] <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:01] <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:02] <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
=== hunger_ is now known as hunger
[11:02] <poolie> in particluar if you're rewriting them you'll need to set the tree revision parents to the newly rewritte ones
[11:03] <arnetheduck> yeah, I'm guessing i should be committing to a separate branch essentially creating a copy (with different commit id's)
[11:04] <arnetheduck> and the list of renames is available on the branch object?
[11:05] <jam> poolie: I think arnetheduck is re-creating the ability to replay a diff
[11:06] <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:08] <jam> from what I can tell "WorkingTreeRevisionRewriter" and "RebaseState1" are things to look at
[11:09] <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:10] <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:12] <Riddell> jam: in bzrlib/log.py  at "searchRE ="
[11:15] <arnetheduck> I'll have another look then, thanks
[11:21] <poolie> good night
[11:25] <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:26] <maxb> Or, at least whenever you branch/pull/update
[11:30] <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:32] <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:33] <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:34] <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:35] <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:36] <jam> but that matches: https://launchpad.net/debian/+source/bzr
[11:36] <maxb> There's nothing "Pending" in ubuntu, there is in debian
[11:37] <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:39] <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:40] <maxb> There is also a pocket parameter on the API call
[11:40] <maxb> Takes a value like '"Backports"'
[11:40] <jam> right
[11:41] <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:42] <maxb> (or do a bunch more round trips to resolve that, which somewhat defeats the point)
[11:43] <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
=== mrevell is now known as mrevell-lunch
=== jamestunnicliff_ is now known as jamestunnicliffe
[12:41] <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
=== mrevell-lunch is now known as mrevell
[13:32] <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:36] <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:37] <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:38] <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:39] <indigo> i found the branch manually, but still i'd like to know for the future
[13:41] <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:42] <indigo> garbage in, garbage out applies for sure
[13:43] <fullermd> Maybe WT_FORMAT++ should include a placeholder for "URL of pending merge"...
[13:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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.
=== 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]
[16:13] <vila> maxb: I'm about to announce 2.4b5, did you have troubles upgrading the ppas or is it just lack of time ?
[16:15] <vila> maxb: or may be you're waiting for sid ?
=== zyga is now known as zyga-afk
=== deryck[lunch] is now known as deryck
=== beuno-lunch is now known as beuno
[17:01] <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:04] <maxb> I suggest announcing, and barring unexpected problems, I'll sort the PPA tonight
[17:06] <jamdahl> I've got a storage efficiency question
[17:07] <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:08] <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:09] <jamdahl> if I switch to a non-binary excel format, like xml, am I going to get more efficient storage?
[17:10] <jamdahl> even though each each individual xml excel file will be bigger than xlsm/xlsx
[17:36] <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:39] <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?
[18:02] <indigo> jamdahl: if the diffs are small, i believe the answer is "yes"
[18:04] <indigo> jamdahl: actually, maybe bzr does do binary deltas, but if you are zipping your files, then you will never get small diffs
[18:05] <indigo> jamdahl: https://lists.ubuntu.com/archives/bazaar/2006q4/019182.html
[18:14] <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:15] <jamdahl> Running an expirment with that now, but unforunately the tons of xml files are completely choking the diff even with small changes :(
[18:20] <dobey> jamdahl: i'm guessing that the xml bits of msoffice/openoffice documents are not particularly well formatted
[18:21] <jamdahl> Opened up one of the changed files.  It's all on one line...
[18:22] <jamdahl> 137kb of xml on one line
[18:23] <dobey> yep
[18:24] <ZyX-I> Hello. All links for 2.4 beta release on http://wiki.bazaar.canonical.com/WindowsDownloads are broken.
[18:27] <ZyX-I> Is there a msi installer for bzr somewhere or something other that does not require user interaction?
[18:45] <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:49] <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:50] <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:51] <dobey> ah
[18:52] <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:54] <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:57] <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:58] <dobey> or you could do it with a bzr plug-in probably
[19:02] <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:05] <jamdahl> hmmm, expirimenting with the older excel format
[19:05] <jamdahl> I don't think the older ones are zipped
[19:07] <jamdahl> gah, older format breaks too much functionality
[19:16] <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:18]  * dobey wonders who to talk to about bzrlib.branch.Branch locking, though
[19:19] <jamdahl> binary isn't as bad as zipped :P
[19:20] <dobey> zip files are binaries
[19:21] <jamdahl> Zip files are a particularly kind of binaries that suck for deltas due to compression algorithms
[19:22] <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:23] <dobey> and if anything changes in the content, it gets recompressed, so the whole block changes
[19:24] <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:26] <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
=== yofel_ is now known as yofel
[19:39] <maxb> Hrm. The armel-cross-toolchain-base UDD import really is interestingly broken
[19:40] <maxb> The importer has reimported several package versions multiple times onto the maverick branch
[21:48] <poolie> hi all
[22:43] <Riddell> g'day poolie
[23:04] <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:13] <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.
=== medberry is now known as med_out
[23:52] <mgz> ...how do I make hg give me something I can attach to a bug? their bundles aren't very friendly.
[23:55] <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:59] <lifeless> mgz: hg diff