[00:08] <yacoob_> Hello there. Any information about 1.13 packages for osx coming soon?
[00:11] <lifeless> yacoob_: the mac folk are pretty responsive, so I'd expect something within a day or two
[00:12] <yacoob_> hit #335528:
[00:12] <yacoob_> This report is public
[00:13] <yacoob_> erp.
[00:13] <yacoob_> hit bug#335528, looked for any other version out there available.
[00:13] <lifeless> bug 335528
[00:13] <lifeless> yacoob_: upgrade your loom package
[00:13] <lifeless> yacoob_: you can also run 'bzr --builtin status' or 'bzr --no-plugins status'
[00:14] <yacoob_> ha, let's see.
[00:17] <thumper> bzr shelve rocks!
[00:18] <yacoob_> btw, I must be tired, I haven't noticed the 'dup-of' line describing the problem in detail... :)
[00:55] <yacoob_> hehe. Good thing: bzr gives you many possible models of development, to pick one that suit your needs. Bad thing: bzr gives you many possible models of development, and you need to worry which one to choose, if you don't have that much experience in the area... :)
[01:15] <Peng_> At least it's easy to switch models.
[01:17] <yacoob>  True... I think. :)
[01:18] <yacoob> for the moment I'm playing with a small pet projec, that only I work on... but I don't like that much idea of keeping my source in just working dir
[01:19] <yacoob> so I've just pushed whole branch to external drive... and now if something happens to my copy, I'll just pull from there
[01:22] <yacoob> hm, assuming I'm working with a centralized model and do some local commits - would later commit push everything as a single change, or will I have whole history pushed together?
[01:35] <lifeless> yacoob: it has all the history
[01:50] <yacoob>  any way to "crunch" it down to single change?
[01:52] <lifeless> yes - its in the user guide. May I ask why though?
[01:52] <yacoob> no real reason, just looking at the possibilities
[01:53] <lifeless> ok
[01:53] <lifeless> so our log shows it crunched down
[01:53] <lifeless> even while the full detail is preserved under the covers
[01:58] <yacoob> I wonder how painful a checkout is, when the history is large... assuming we do want the history
[02:26] <lifeless> jml: so, we can do push of a revision in 18 seconds now
[02:26] <lifeless> jml: which makes 11seconds a rather large fraction :P
[02:27] <Peng_> It takes 18 seconds to push 1 revision? What are we talking about?
[02:27] <lifeless> Peng_: its not 36 for two, if thats concerning you :P
[02:27] <jml> lifeless: I was looking at our data on this today
[02:27] <lifeless> Peng_: 'bzr push' in an existing branch with one new commit on it
[02:27] <lifeless> Peng_: via bzr+ssh
[02:28] <spiv> Peng_: pushing 1 new revision to an existing branch in a shared repo via bzr+ssh, including SSH handshake, from Sydney->London.
[02:28] <spiv> 18s, but also 18 HPSS calls, co-incidentally.
[02:28] <Peng_> Oh, from Sydney to London.
[02:29] <spiv> Yeah, that part is rather key :)
[02:29] <mwhudson> spiv: 18s includes ssh set up time?
[02:30] <spiv> Also, there are actually two SSH handshakes there, it was a push to people.ubuntu.com.
[02:30] <spiv> mwhudson: yes.
[02:30] <mwhudson> spiv: oh good :)
[02:30] <spiv> mwhudson: if launchpad had 1.13 I'd use it ;)
[02:31] <mwhudson> spiv: bazaar.staging.launchpad.net will soon enough
[02:31] <mwhudson> staging can be really slow for other reasons though
[02:31] <spiv> mwhudson: that would be lovely.
[02:48]  * fullermd frowns.
[02:48] <fullermd> Is this redirect of distfiles to launchpadlibrarian new?
[02:49] <lifeless> fullermd: I don't think so; its to prevent XSS
[02:49] <jml> is there a builtin command that does 1 hpss call?
[02:49] <lifeless> jam has one in a plugin I think
[02:49] <jml> 1 r/o call preferably
[02:50] <fullermd> Hm.
[02:50] <lifeless> https://code.edge.launchpad.net/~bzr/bzr-hello/trunk
[02:50] <jml> lifeless: thanks
[02:50] <fullermd> It's breaking the port download, which explicitly doesn't follow redirects   :|
[02:50] <fullermd> Never did that before, even earlier this week.
[02:50] <lifeless> oh. have ports changed then ? ::P
[02:51] <jml> whomp!
[02:52] <lifeless> ?
[02:52] <fullermd> I don't think so...   I'm checking as fast as I can swallow the bile from running cvs ann...
[02:52] <jml> lifeless: bzr hello stacktraces
[02:52] <lifeless> ouch
[02:52] <spiv> I have one too, https://launchpad.net/bzr-ping :P
[02:53] <fullermd> Not in a couple years at least...   the line setting that arg hasn't been touched since 07.
[02:53] <spiv> jml: and mine doesn't backtrace ;)
[02:53] <fullermd> And it worked earlier this week when I tested the RC.
[02:53] <lifeless> AFAIK there hasn't been a rollout this week
[02:53] <lifeless> spm: ^
[02:54] <lifeless> fullermd: given today is monday and all
[02:54] <jml> spiv: thanks.
[02:54] <fullermd> Are the librarian links stable (or stable enough 'till the next release)
[02:54] <fullermd> It was probably Wed or Thur when I did it...
[02:54] <fullermd> mtimes say Thurs.
[02:54] <spiv> jml: FWIW I just got 6.477s to bzr ping bzr+ssh://bazaar.launchpad.net/
[02:55] <jml> spiv: that's roughly what I get.
[02:55] <jml> (5.6, 5.8, 6.2)
[02:55] <lifeless> jml: how long do you get for 'bzr ping lp:bzr'
[02:55] <spiv> fullermd: which librarian links?
[02:55] <jml> using the lp: url takes it up to 7.6, 7.8, 8.0
[02:56]  * igc lunch
[02:56] <fullermd> The 302 to launchpadlibrarian.net for the release tarball.
[02:56] <spiv> Which 302?
[02:56] <spiv> (I think I'm missing some context)
[02:57] <jml> lifeless: so, uhh, I guess that means that launchpad page loads are expensive :P
[02:57] <lifeless> fullermd: what url are you giving ports today
[02:57] <lifeless> jml: but but but these are not full pages, they are ajaxy, they must be faster right?
[02:57] <lifeless> oh damn, there goes my sarcastic side again. Meep
[02:58] <fullermd> http://pastebin.ca/1361926
[02:58] <fullermd> (does the same with code.launchpad, which is what bzrtools is using; it's failing now too)
[02:58] <spiv> fullermd: ah, on Launchpad, as opposed to bazaar-vcs.org or something
[02:58]  * jml files a bug on bzr-ping
[02:58] <fullermd> Well, last I heard release tarballs weren't going on b-v.o anymore anyway   :)
[02:59] <jml> oh, it doesn't use lp as its bug tracker
[02:59]  * jml uses IRC instead
[02:59] <jml> spiv: ping should also be able to send N hpss requests
[02:59] <lifeless> jml: thats just a bad default, assume  it uses it
[03:00] <spm> lifeless: we did have a rollout to crowberry on friday. Was a CP for jml/mwh's bzr connections fix. Is possibly related?
[03:00] <lifeless> spm: what else was included though? the main app is at issue, not code hosting per se
[03:00] <poolie> hi all
[03:00] <spiv> fullermd: AFAIK /bzr/1.13/1.13/+download/bzr-1.13.tar.gz should be a stable URL.  Also, the target of that redirect should exist for as long as the Launchpad web UI offers bzr-1.13.tar.gz for download.
[03:01] <spiv> fullermd: does that tell you what you want to know?
[03:01] <lifeless> jml: ping 'fixed' to use lp
[03:01] <fullermd> I guess...   I'll just have to resolve it manually and use the librarian links.
[03:01] <fullermd> Port fetch explicitly disables redirect-following.
[03:02] <lifeless> fullermd: how does port fetch handle sf?
[03:02] <spiv> It would be nice if Launchpad served that data to you directly rather than giving a redirect.
[03:03] <fullermd> It just lists the mirror explicitly.
[03:04]  * fullermd grabs a random example.
[03:04] <lifeless> fullermd: can you just turn it on for this, I mean, sha1 isn't trivially broken [yet]
[03:04] <fullermd> Not really, no.
[03:04] <spiv> Then using the librarian URL directly seems about the same.
[03:04] <fullermd> I mean, I probably COULD override the fetch args in the port Makefile, but that's REALLY unfriendly to the layering.
[03:05] <spiv> But ideally I think port fetch would rely on the checksum rather than lack of HTTP redirect...
[03:05] <lifeless> fullermd: args = echo $args | sed -e ....
[03:05] <lifeless> :P :] :>
[03:05] <fullermd> Too late, due to make's makeage  :p
[03:06] <fullermd> It does use a checksum to verify the file after download.  The comments suggest one reason redirects are flat disabled is because of sides that use a 302 to implement their 404's.
[03:06] <lifeless> fullermd: ugh, breaking a standard to deal with broken sites
[03:06] <lifeless> FAIL
[03:07] <lifeless> turn it on, sites with 404 as 302 will get a sha fail, everyone wins
[03:07] <fullermd> That's slightly above my paygrade   :p
[03:07] <lifeless> [I appreciate its not trivial to do this, but really. HTTP Nazi hat on now]
[03:09] <fullermd> Ah, there's where it started.  1.306, 1999-03-08.
[03:09] <fullermd> Now I can avoid touching cvs ann for another 5 years, hopefully...
[03:20] <AfC> I have today discovered that in Red Hat land they use the term "re-base" to mean upgrading the version of a package they are shipping to a newer (sometimes even latest!) release.
[03:20] <AfC> This is exciting.
[03:20] <lifeless> its analagous at least
[03:21] <AfC> Well, seeing as how I never figured out what Git rebase did, nor how Bazaar's implementation of same worked, really, it's all the same to me :)
[03:21] <AfC> I'm just pleased to hear that they do, from time to time, upgrade their packages.
[03:22] <fullermd> Sounds like a scurrilous rumor to put you off your guard.
[03:25] <AfC> fullermd: very likely
[03:25] <AfC> fullermd: but still, given that it looks like I'm going to be building, deploying, and maintaining a largish enterprise installation on RHEL over the next few months, I'll happily take false hopes.
[03:27] <Peng_> The more hope you have, the more you can be disappointed.
[03:28] <AfC> I know. Isn't the universe a wonderful place?
[03:28] <fullermd> Yeah.  I've tried crushing the spirit of a pessimist before.  It just has no flavor.
[03:34] <lifeless> fullermd: did you add all-spice?
[03:38] <fullermd> Nah, that's a little coarse for the usage.  Cumin and paprika, more like.
[05:30] <fullermd> Ah, found What Changed to cause the redirect issue.  Pfeh.
[05:33] <lifeless> fullermd: ...
[05:33]  * lifeless shakes his mind reading gizmo, its bust
[05:34] <fullermd> Upgraded by system over the weekend.
[05:34] <fullermd> Which fixed a bug in fetch(1) that cause the "don't-follow-redirects" arg to have no affect on http_s_
[05:35] <fullermd> And no effect, either.
[05:35] <fullermd> Just goes to show, fixing bugs always screws things up...
[05:37] <lifeless> :)
[05:37] <lifeless> it also shows that the don't-follow-redirects setting wasn't affecting you :P
[05:37] <fullermd> Yah.  It was only working on http.
[05:38] <fullermd> Which didn't have any effect on grabbing bzr{,tools}, so it was masked.
[05:38] <lifeless> I know
[05:38] <lifeless> just saying, delete the setting entirely, it'll be fine :)
[05:39] <fullermd> That promises a very long discussion.  I'm not sure I have the gumption to try and ram that through...
[06:36] <BasicOSX> Looks like release announcement did not make it to -announce, someone needs to approve it?
[06:36] <BasicOSX> sleep
[07:03] <Kamping_Kaiser> Would this be enough information to file a bug with? its me trying to commit using bzr in an svn repo http://paste.debian.net/30664/
[07:04] <Kamping_Kaiser>  /seems/ to be reproduceable - cd into svn dir -> try and commit -> segfault.
[07:04] <lifeless> Kamping_Kaiser: sure, on bzr-svn please
[07:04] <Kamping_Kaiser> lifeless, ok, thanks.
[07:04] <lifeless> Kamping_Kaiser: jelmer will want your subvertpy version, platform (i386/adm64 etc) and libsvn versions I suspect
[07:05] <Kamping_Kaiser> lifeless, ok, i'll be sure to include them. are bugs filed 'announced' here or should i link after filing it?
[07:09] <lifeless> they aren't, because folk get mailed
[07:15] <lifeless> spiv: LOL I broke the retry-tests by making packs much more efficient :P
[07:21] <spiv> lifeless: :)
[07:21] <spiv> lifeless: I was wondering what happened to your merge...
[07:21] <lifeless> specifically I got rid of a reset() call in _refresh_data
[07:22] <lifeless> so now it merges. hmm
[07:28] <Kamping_Kaiser> lifeless, thanks for the help, bug is now filed.
[07:32] <lifeless> Kamping_Kaiser: my pleasure
[07:32] <lifeless> spiv: so, fixed by 'reset; refresh_data()' :P
[07:32] <lifeless> spiv: hate this too-good code.
[07:34] <lifeless> spiv:   File "/home/robertc/source/baz/integration/bzrlib/tests/test_remote.py", line 1934, in test_ok_with_real_repo
[07:34] <lifeless>     client._calls)
[07:34] <lifeless> AssertionError: not equal:
[07:34] <lifeless> a = [('call', 'PackRepository.autopack', ('quack/',)),
[07:34] <lifeless>  ('pack collection reload_pack_names',)]
[07:34] <lifeless> b = [('call', 'PackRepository.autopack', ('quack/',))]
[07:34] <lifeless> from bzrlib.tests.test_remote.TestRemotePackRepositoryAutoPack.test_ok_with_real_repo
[07:35] <Peng_> That eliminated a round-trip?
[07:35] <lifeless> Peng_: changed from a private interface to a public one, round trips are the same
[07:35] <lifeless> Peng_: this is test fallout I fear
[07:36] <lifeless> mock objects, your best friend, your worst enemy
[07:41] <lifeless> spiv: do you want to see these test changes?
[07:41] <lifeless> :!bzr diff | diffstat
[07:41] <lifeless>  test_knit.py       |   34 ++++++++++++++++------------------
[07:41] <lifeless>  test_remote.py     |   10 +++++++---
[07:41] <lifeless>  test_repository.py |    1 +
[07:41] <lifeless>  test_smart.py      |    4 ++++
[07:41] <lifeless>  4 files changed, 28 insertions(+), 21 deletions(-)
[07:45] <lifeless> spiv: no answer == land it :P so am
[07:52] <spiv> lifeless: sorry, was busy thinking about pork like a tyrant day... :P
[07:54] <spiv> lifeless: if it's just adjusting tests in obvious ways (e.g. I imagine that the test_remote fix was pretty trivial), then +1
[07:56] <lifeless> spiv: mmm bacon explosion mmm
[07:57] <lifeless> spiv: not entirely, let me pastebin the deed
[07:57] <lifeless> http://paste.ubuntu.com/131855/
[08:00] <spiv> lifeless: hmm, please adjust the test_remote change to append something like 'pack repository refresh_data' rather than reload_pack_names.  It's just an arbitrary string, but I'd rather it more-or-less described the direct action...
[08:01] <lifeless> spiv: yeah. I'll have to land that later though
[08:01] <spiv> lifeless: but otherwise it looks ok to me.
[08:25] <CaMason> hi guys. Is there any nice way to do a visual diff on Windows? I have BeyondCompare installed, but using `bzr diff --using=BCompare.exe` gives me 1 file at a time
[08:26] <SuperMMX> Hi, guys, I just upgraded to 1.13 to try the filtered view, but it seems that it has no effect at all. In my understanding, filtered view will only generated some part of the working tree, right ?
[08:28] <SuperMMX> Will it only show the the contents in a directory DIR if I do "bzr view --name MyView DIR" ?
[08:31] <lifeless> CaMason: I thought bzr had visual diffing builtin on windows
[08:32] <CaMason> via the tortoisebzr thing? That doesn't work for me (64-bit)
[08:32] <lifeless> SuperMMX: it currently only affects what the commands *do* not what is put on disk; also make sure you have followed ian's notes about it as it needs a in-development tree format
[08:32] <lifeless> CaMason: oh :(
[08:32] <CaMason> although bizarely, the icons do show up if I use a file browser within an application :o
[08:33] <SuperMMX> lifeless: sure, the working tree format is upgraded to development-wt5.
[08:34] <SuperMMX> lifeless: ... it seems that I misunderstand the feature totally  at first
[08:35] <sabdfl> what's the best format for brisbane-core tests?
[08:35] <SuperMMX> I thougth it will reduce the diskspace which is with very hight priority in my feature wishlist for bzr.
[08:39] <lifeless> sabdfl: we're currently looking at gc-chk255{,-big}, not that you need to set NO_LABELS in the code to avoid parsing a lookup table that we're going to either remove or have partial-parsing on soon
[08:39] <lifeless> s/not/note/
[08:39] <SuperMMX> But I think it should not be very hard to add that function. It will be great to only work with a small set of files in the same tree.
[08:40] <lifeless> gnight all
[08:41] <spiv> lifeless: g'night
[08:41] <spiv> lifeless: btw, with my patch landed, tests all pass with InterOtherToRemote removed
[08:41] <Peng_> lifeless: Good night.
[08:42] <mwhudson> Peng_: do you ever sleep?
[08:44] <fullermd> Sleep is for wimps.
[08:45] <fullermd> Happy, healthy, well-rested wimps, but wimps nonetheless.
[08:52] <jml> so, my flatmate got a cold the day I got back from travel
[08:52] <jml> I may well be cursed.
[09:14] <Peng_> mwhudson: Disturbingly frequently.
[10:06] <fullermd> Oh blah, merge --force is still broken.
[10:18] <thrope> i have a bzr-svn co of a svn repo which contains a move (everything was moved into a sub directory). now bzr log on a file only gives entries up to the move, but svn log on the same file in a svn checkout shows the full history (including before the move)
[10:18] <thrope> is there a way to get bzr to track the full history?
[10:19] <thrope> (i thought bzr should handle renames well - git shows the full log correctly in a git-svn branch if i give it the --follow option, is there something similar for bzr?
[10:30]  * SamB would suggest that thrope file a bug -- if only he were still here
[10:31] <SamB> thrope: ah!
[10:31] <SamB> file a bug, maybe?
[10:31] <thrope> hi - sorry having some computer issues
[10:31] <SamB> I'm pretty sure bzr-svn is supposed to handle that fine
[10:32] <thrope> i thought so - but I thought i'd check first
[10:32] <SamB> well, oh, but does SVN give the full log?
[10:32] <thrope> yep
[10:32] <SamB> good
[10:32] <SamB> git isn't really an indication since it doesn't track renames ...
[10:33] <SamB> ... it just figures them out after the fact
[10:35] <Peng_> thrope: Is the repo public?
[10:35] <thrope> yep
[10:35] <thrope> http://pyentropy.googlecode.com/svn/trunk/
[10:35] <Peng_> thrope: Ask jelmer (when he comes online) and/or file a bug.
[10:35] <thrope> ok
[10:35] <thrope> i'll wait for jelmer
[10:36] <thrope> the file is trunk/pyentropy/pyentropy/pyentropy.py (I am just learning about python packages - it hink this will change)
[10:36] <SamB> hehehe
[10:37] <SamB> pyentropy.pyentropy.pyentropy?
[10:37] <thrope> first one is just a dir
[10:37] <thrope> because I keep something else in the repository
[10:37] <thrope> guess it should be pyentropy/trunk/pyentropy/pyentropy.py
[10:38] <wgrant> I don't think bzr-svn does do svn 'renames' at the moment.
[10:38] <wgrant> As svn doesn't do renames.
[10:38] <SamB> what else (besides the wiki) do you keep in the repository?
[10:38] <wgrant> It copies and deletes.
[10:38] <thrope> wgrant: it was a svn move
[10:38] <thrope> another small module call femaxent
[10:38] <wgrant> svn move is copy + delete.
[10:38] <thrope> it is related
[10:39] <Peng_> bzr-svn could detect copy+delete as a rename.
[10:39] <wgrant> And bzr can't track copies.
[10:39] <wgrant> It could.
[10:39] <wgrant> There's a bug about it.
[10:39] <SamB> I guess you should subscribe?
[10:39] <thrope> yep trying to find it
[10:40] <thrope> got it
[10:41]  * SamB personally errs on the side of reporting Invalid bugs, on the theory that most Invalid bugs are actually problems with the documentation ;-)
[10:42] <SamB> (or other code)
[10:43] <SamB> thankfully, jelmer seems to agree with me so far
[10:46] <thrope> also I was wondering if I can push two related bzr native branches into svn in such a way that they share history properly
[10:46] <thrope> (ie donthave doubled up commits)
[10:47] <SamB> thrope: did you try?
[10:47] <thrope> I figured it would involve pushing up to where they diverged to one place is svn, doing an svn copy, rebasing the branches to that copy
[10:47] <thrope> or something like that
[10:47] <thrope> I tried the naive way - pushing them both to different dirs, but there was no shared history (all the common commits appeared twice in svn)
[10:47] <Peng_> "bzr native branches"? Why deal with svn at all then?
[10:47] <SamB> oh
[10:48] <SamB> Peng: well ... is that any reason for it not to work?
[10:48] <thrope> I thought you could store bzr branches in svn with bzr-svn
[10:48] <thrope> started as a seperate thing, but now I want to put it in the main repo (which is svn)
[10:48] <thrope> I guess it doesn't really matter about the repeated commits - I will just push the two branches
[10:48] <thrope> but I wondered if it would be possible
[10:49] <SamB> file a bug?
[10:49] <thrope> its a question really
[10:49] <thrope> i dont think it should work the naive way -  i think i have to push the common bits, then do a rebase or something
[10:49] <SamB> I think maybe there should be a command for that?
[10:50] <SamB> or at least commands to help
[10:53]  * Peng_ goes to bed.
[11:00] <Leonidas> bzr log --format gnu-changelog
[11:00] <Leonidas> bzr log --format gnu-changelog
[11:00] <Leonidas> bzr: ERROR: no such option: --format
[11:00] <Leonidas> Well, something's broken with 1.13
[11:08] <fullermd> Has log ever had a --format?  It's got a --log-format...
[11:10] <spiv> fullermd: Not AFAIK.
[11:10] <spiv> Leonidas: I think that's a typo in the NEWS file :(
[11:11] <spiv> ISTR a patch on the list about it, but I guess it didn't make it in.
[11:11] <Leonidas> ok.
[11:12] <spiv> Leonidas: Leonidas it's bzr log --log-format gnu-changelog, as fullermd says.
[11:13] <spiv> Leonidas: "bzr log --gnu-changelog" works too, as "bzr help log" says.
[11:22] <spiv> lifeless: http://people.ubuntu.com/~andrew/bzr/simplify-interrepo-stack removes InterRemoteToOther and InterOtherToRemote and has all tests passing.
[11:22] <spiv> lifeless:  2 files changed, 4 insertions(+), 78 deletions(-)
[11:22] <spiv> lifeless:  :)
[12:50] <Leonidas> spiv: yes, indeed.
[13:11] <vadi2> How can I make it so when I merge and commit, the commit(s) message from the merged branch show up in the main one?
[13:16] <jpds> vadi2: It does, as subcommits.
[13:16] <vadi2> Where?
[13:17] <vadi2> Ah, just lp is not displaying it
[13:17] <vadi2> okay thanks
[13:18] <jpds> eg, http://paste.ubuntu.com/131965/ - but yeah, LP doesn't show it.
[15:00] <newz2000> Hi, can I add a bzr branch inside another project I'm working on which is also version controlled?
[15:00] <newz2000> (bzr add seems to do nothing in this case)
[15:18] <beuno> newz2000, right, it ignores any branches inside branches
[15:19] <newz2000> is there a way around that?
[15:23] <beuno> no, abentley is going to work on nested trees soon
[15:23] <beuno> which is what you want
[15:24] <newz2000> :-(
[15:24] <newz2000> That'll be a cool feature when it's done.
[15:25] <abentley> beuno: I've already started work, in fact.
[15:25] <beuno> ah, that's even better!
[15:25] <beuno> hi abentley
[15:25] <abentley> beuno: hi
[15:41] <lamont> when will https://edge.launchpad.net/~bzr/+archive/ppa have 1.13 (bzr and bzrtools)?
[16:07] <Kobaz> you're killing me
[16:08] <Kobaz> er
[16:08] <Kobaz> wrong channel
[16:08] <Kobaz> what's the recommended commit/push emailer plugin
[16:54] <jam> vila: good evening
[16:55] <vila> jam: hi ! How do you know I'm jetlagging :-)
[16:55] <jam> I'm doing pretty good, all things considered
[16:55] <jam> I managed to sleep on the plane at an appropriate time, and then stay up to ~9pm my first day back
[16:55] <jam> So I'm probably 95% transitioned by now.
[16:56] <jam> vila: I just remembered that we had talked about doing a phone call everyday
[16:57] <jam> of course we missed the original time by about 3hrs, but I  wondered if you were still interested today
[16:57] <vila> I couldn't resist and slept 16hours yesterday, yet, I fall sleeping looking the perfmeter while toying with parallelized selftest (truth is watching the 8 curves is pretty hypnotic)
[16:57] <jam> :)
[16:57] <vila> jam: not today, I'm abot to stop, but tomorrow certainly
[16:57] <jam> ok
[16:59] <vila> jam: regarding parallel selftest, lifeless sketch is working, some rough edges (unavailable feature and know failures are missed and the test suite doesn't seem to end)
[17:04] <jam> wow....
[17:04] <jam> good news for LP folks
[17:04] <jam> I just did a test conversion of LP branch to CHK255-big
[17:04] <jam> Orig source was 861MB, right after conversion, it dropped to 248MB, after doing "bzr pack" I'm down to 133MB
[17:08] <vila> jam: wow, now *that* is significant  :-)
[17:08] <jam> I'm running 'repo-details' to make sure it is all accurate, but yeah, nice results
[17:11] <rockstar> jam, that's awesome.
[17:13] <NfNitLoop> what's chk255-big?  :)
[17:14] <jam> NfNitLoop: the 'brisbane-core' work we've been working on for the past 6-8 months
[17:14] <jam> split-inventory + groupcompress delta compression + a specific page layout
[17:15] <NfNitLoop> aah, cool.
[17:15] <NfNitLoop> sorry, just eavesdropping and was curious. :)
[17:15] <jam> yeah
[17:15] <jam> Its something we'll probably be moving into a 'development' format in bzr.dev in the next month or two
[17:15] <NfNitLoop> cool. :)
[17:16] <jam> bzr.dev itself packed from something like 100MB down to ~25MB, IIRC
[17:16] <jam> not quite as impressive, though still nice
[17:31] <Tak> if I have credentials stored in authentication.conf, shouldn't bzr automagically use them when I try to branch or whatever?
[17:32] <zsakr> I need to write a hook script that will notify me by email every time someone commits a file in /trunk. I already have the email part working, but I'm not sure how to make the conditional statement to check if the commit is in /trunk.
[17:33] <jam> Tak: there may be times when using a user in a URL triggers the code that tries to use a password
[17:33] <jam> I certainly agree it is a bug if you need user@, but it may be a workaround you can use
[17:33] <Tak> I can't get it to use it with or without user@
[17:34] <Tak> this is for sftp transport
[17:34] <Tak> at least, I'm testing with sftp transport
[17:35] <jam> Tak: well, if you are using openssh as your ssh provider (the common case), we have no way to pass it a password
[17:35] <jam> you might try "BZR_SSH=paramiko"
[17:35] <jam> for security, openssh uses a direct connection to your terminal to prompt for a password
[17:36] <zsakr> jam: any idea?
[17:36] <jam> zsakr: Can you just check the branch url?
[17:36] <jam> if thebranch.base.endswith('/trunk') ?
[17:36] <Tak> interesting
[17:38] <jam> Tak: I would certainly recommend using ssh keys and an ssh-agent under those circumstances, rather than paramiko
[17:38] <jam> but you can use a password if you prefer
[17:40] <Tak> well, I'm attempting to use the authentication api generically - I just happen to be testing with an sftp transport because that's what I have on hand that's passworded
[17:41] <Tak> it appears to fail with paramiko as well
[17:43] <jam> Tak: did you use "export BZR_SSH" ?
[17:43] <Tak> yeah, and the console output is different, signifying that it's not using openssh
[17:48] <jam> Tak: I don't use it myself, so I'm not 100% sure how to configure everything. Though I know that http and ftp get more testing, since there aren't many alternatives there
[17:48] <jam> I would have you chat with vila, since he implemented most of the auth work, but I think he stopped for today
[17:48]  * Tak nods
[17:48] <Tak> vila: ping ;-)
[19:24] <rockstar> Is there a branch format register somewhere that will let me get all the current formats?
[19:28] <beuno> man, bzr's progress bar is so awesome now
[19:28] <LarstiQ> rockstar: bzrlib.bzrdir.format_registry?
[19:29] <LarstiQ> rockstar: or specifcally branch formats?
[19:29] <jelmer> 'evening beuno, larsitq
[19:29] <jelmer> *larstiq
[19:30] <rockstar> LarstiQ, anything I can iterate over will do.
[19:31] <beuno> hey hey jelmer
[19:31] <beuno> how's it going?
[19:31] <LarstiQ> rockstar: [] ;P
[19:32] <LarstiQ> hey jelmer, beuno :)
[19:32] <LarstiQ> jelmer: I started an identi.ca account!
[19:32] <beuno> jml, thank you again for lp-open
[19:32] <beuno> hola LarstiQ!
[19:32] <LarstiQ> beuno: and indeed, mbp deserves much kudos for the progress bars
[19:33] <LarstiQ> rockstar: the thing is, every domain object (the big three) has it's own formats, and then a combination of those is also known as a format
[19:33] <jelmer> beuno: pretty good, looking at finally putting that first bzr-git release out
[19:33] <jelmer> LarstiQ: whoa
[19:33] <beuno> jelmer, a lot of excitement around that
[19:34] <LarstiQ> rockstar: so, for formats in that registry, bzrlib.bzrdir.format_registry.get('default').get_branch_format()
[19:34] <LarstiQ> rockstar: but you might miss non-bundled branch formats
[19:34] <rockstar> LarstiQ, is 'default' a format string?
[19:35] <LarstiQ> rockstar: yeah, from the format_registry.keys() list
[19:36] <LarstiQ> rockstar: if you are sure it is branch formats, and not repository or workingtree ones, I think only 6 and possibly 5 are 'current'
[19:36] <LarstiQ> ie, bzrlib.branch.BzrBranchFormat{6,5}
[19:37] <rockstar> LarstiQ, so I need to be able to specify a format string, and determine whether a branch with that format string needs upgrading.  Maybe that'll help you give me clues.
[19:37] <mwhudson> LarstiQ: isn't it branch7 that adds stacking?
[19:37] <rockstar> mwhudson, the source would say so
[19:37] <LarstiQ> mwhudson: if it does, it's hiding
[19:38] <LarstiQ> hmm, maybe import didn't get to it properly
[19:38] <rockstar> LarstiQ, bzrlib.branch.BranchFormat7 is the first that overrides supports_stacking to return True
[19:38]  * LarstiQ quizzicaly looks at ipython
[19:38] <rockstar> LarstiQ, so you see my dilemma.
[19:38] <LarstiQ> rockstar: I sit corrected.
[19:39] <LarstiQ> rockstar: ok, I'd look at the code in bzrlib that detects when things need upgrading.
[19:40] <rockstar> LarstiQ, yeah, looking at BzrDir.needs_format_conversion right now
[19:40]  * LarstiQ assmebles dinner
[20:01] <mwhudson> abentley: good morning, bundlebuggy seems to be down
[20:02] <abentley> mwhudson: restarted
[20:02] <mwhudson> abentley: thanks
[20:19] <schmichael> hm, committed a 45MB json file, pulled it into another repo & its empty
[20:19] <schmichael> the second repo is 1.13rc is that makes a difference
[20:30] <Peng_> schmichael: What's empty? The entire repo?
[20:30] <Peng_> schmichael: Maybe the branch doesn't have a working tree? Run "bzr checkout".
[20:32] <schmichael> Peng_: oh sorry, turns out i'm crazy
[20:32] <schmichael> turns out piping nothing to a file overwrites it ;)
[20:32] <schmichael> so um... bzr is fine
[20:32] <Peng_> Ah.
[20:32] <schmichael> better than fine really
[20:32] <schmichael> the .bzr directory is only 6.7MB!!!
[20:41] <Peng_> mwhudson: ping?
[20:42] <mwhudson> Peng_: hi
[20:42] <mwhudson> Peng_: what's broken in launchpad trunk now? :)
[20:42] <Peng_> mwhudson: The changelog page. :)
[20:42] <mwhudson> Peng_: how so?
[20:42] <Peng_> (You meant Loggerhead, right?)
[20:43] <mwhudson> er, yeah
[20:43] <Peng_> mwhudson: When I click the down arrow, it doesn't display anything. +revlog gives back an error page.
[20:43] <mwhudson> hm
[20:43] <mwhudson> saying what?
[20:44] <Peng_> List index out of range on changes[0].
[20:44] <Peng_> mwhudson: http://paste.pocoo.org/show/jE4QV4sihEBPkHGle9p2/
[20:44] <mwhudson> that means the revid is wrong
[20:45] <mwhudson> oh god, is this a bzr-svn branch or something?
[20:45] <mwhudson> i wonder if there are quoting issues
[20:45] <Peng_> mwhudson: Yeah, it is.
[20:45] <mwhudson> bing!
[20:45] <mwhudson> ok, should be easy to fix
[20:46] <mwhudson> Peng_: http://pastebin.ubuntu.com/132182/ <- try this?
[20:48] <Peng_> Hold on.
[20:54] <Peng_> mwhudson: Didn't help.
[20:54] <mwhudson> Peng_: did you reload the changelog page before trying again?
[20:55] <Peng_> mwhudson: I should have.
[20:55]  * mwhudson goes hunting for a bzr-svn branch
[20:56] <mwhudson> Peng_: it works for me :/
[20:56] <Peng_> Yes, I did reloa.d
[20:57] <mwhudson> Peng_: i guess it's going to be long and painful, but can you paste the +revlog url that lh is trying to access?
[20:58] <Peng_> mwhudson: /loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/%2Brevlog/svn-v4%3A152afb58-edef-0310-8abb-c4023f1b3aa9%3Abranches/lighttpd-1.4.x%3A2418
[20:58] <Kobaz> what's the recommended commit/push email plugin
[20:58] <Peng_> Wait.
[20:59] <Peng_> mwhudson: Well, that was the original bad URL from before I patched it.
[21:00] <mwhudson> Peng_: the patch definitely fixes browsing a bzr-svn branch for me
[21:00] <Peng_> Hum.
[21:00] <mwhudson> (even proxied through apache)
[21:05] <Kobaz> noone has a favorite commit emailer?
[21:06] <LarstiQ> Kobaz: bzr-email if mail from the location where you work is fine
[21:06] <Kobaz> what about when someone does a push to a central repo
[21:07] <LarstiQ> Kobaz: bzr-email if that's done via a smartserver
[21:07] <Kobaz> k
[21:07] <Kobaz> i have bzr going to apache with some funky python somethingorother module
[21:07] <Kobaz> i think it's smartserver
[21:07] <LarstiQ> Kobaz: bzr-hookless-email if not. Nicholas Allen has recently been doing work in this area too (I still have to read and reply to those threads..)
[21:07] <LarstiQ> Kobaz: right, that then should be able to execute server side hooks
[21:08] <Kobaz> PythonHandler bzr-smart::handler
[21:09] <Kobaz> so anyways
[21:09] <Kobaz> i've never installed a plugin
[21:09] <Kobaz> there's a bazillion files when you click on 'code' on launchpad
[21:10] <LarstiQ> Kobaz: two approaches:
[21:10] <LarstiQ> Kobaz: 1) an OS provided bzr-email 2) cd ~/.bazaar/plugins; bzr branch bzr-email email; bzr plugins | grep email
[21:10] <Kobaz> are there debian packages?
[21:10] <LarstiQ> Kobaz: basically, if you installed bzr via a package management system, do the same for bzr-email
[21:11] <LarstiQ> Kobaz: yes
[21:11] <Kobaz> k
[21:11] <Kobaz> bzr-email - Notification email plugin for Bazaar
[21:11] <Kobaz> oooOooOoo
[21:11] <Kobaz> okay, installed
[21:11] <Kobaz> now what
[21:12] <Kobaz> how would i configur eit
[21:12] <Kobaz> heh
[21:12] <Peng_> mwhudson: Oddly enough, another bzr-svn branch works even without your patch.
[21:12] <LarstiQ> Kobaz: `bzr help email` should be a start
[21:12] <Peng_> mwhudson: (It works with the patch, too.)
[21:13] <mwhudson> Peng: which is the one that fails?
[21:13] <LarstiQ> Kobaz: or /usr/share/doc/bzr-email/README
[21:13]  * mwhudson hopes it's fairly small
[21:13] <Kobaz> k
[21:13] <LarstiQ> Kobaz: either set the options in the branch.conf you care about, or the ~/.bazaar/{bazaar,locations}.conf of the user the smartserver runs as
[21:14] <Peng_> mwhudson: http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/ (but I reverted that Loggerhead install to an older version to work around this)
[21:14] <Kobaz> k
[21:14] <Peng_> mwhudson: Is 2100 revisions small?
[21:14] <mwhudson> Peng: if i bzr branch from that url, will i be talking to loggerhead?
[21:15] <mwhudson> Peng_: small enough i guess
[21:15] <Peng_> mwhudson: You can "bzr branch" from it, though Bazaar will warn about some wacky redirects.
[21:15] <mwhudson> Peng_: i guessed http://bzr.mattnordhoff.com/bzr/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/, seems to work
[21:16] <Peng_> mwhudson: fwiw, the branch passes "bzr check"
[21:16] <Peng_> mwhudson: Both should work.
[21:16] <mwhudson> ok
[21:21] <Kobaz> i broke it
[21:21] <Kobaz> http://pastebin.com/m2b818964
[21:24] <LarstiQ> Kobaz: that's very weird
[21:24] <mwhudson> Peng_: ok, can reproduce
[21:24] <LarstiQ> Kobaz: you branch, commit, push, and they're not compatible?
[21:24] <Kobaz> apparently
[21:24] <Peng_> mwhudson: Oh, cool.
[21:25] <LarstiQ> Kobaz: /tmp isn't secretly in a shared repository?
[21:25] <Kobaz> nope
[21:25] <LarstiQ> Kobaz: relevant ~/.bzr.log entries?
[21:25] <Kobaz> nothing interesting that i can see
[21:25] <Kobaz> i'll paste it
[21:26] <Peng_> mwhudson: So does that mean your escaping patch is unnecessary?
[21:26] <mwhudson> Peng: no, it's wrong :)
[21:27] <Kobaz> http://pastebin.com/m4970ae9a
[21:27] <Peng_> Wait, no it's not necessary or no it is necessary?
[21:27] <mwhudson> >>> bzrlib.urlutils.escape('/')
[21:27] <mwhudson> '/'
[21:27] <mwhudson> Peng_: a different patch is necessary
[21:27] <Peng_> mwhudson: Ah.
[21:27] <mwhudson> that ^ surprises me
[21:28] <Kobaz> LarstiQ: both are Repository branch (format: pack-0.92)
[21:28] <LarstiQ> Kobaz: what version of bzr and the apache foo?
[21:28] <Kobaz> Bazaar (bzr) 1.10 Python interpreter: /usr/bin/python 2.5.2
[21:28] <Kobaz> on both
[21:29] <Kobaz> apache 2.2.9
[21:29] <Kobaz> using bzr-smart.py and modpywsgi.py
[21:30] <Peng_> mwhudson: So escaping / as well would fix it?
[21:30]  * LarstiQ looks at bug reports
[21:30] <mwhudson> yes
[21:30] <mwhudson> i think so
[21:31] <Peng_> mwhudson: urllib.quote(s, safe='')
[21:32] <mwhudson> except that freaking 404s
[21:32] <mwhudson> what's going on
[21:32] <mwhudson> !?
[21:32] <mwhudson> apache is 404ing me
[21:34] <Kobaz> [Mon Mar 16 17:33:31 2009] [error] [client 207.255.24.91] File does not exist: /home/web/bzr/playground/.bzr/checkout
[21:34] <Kobaz> i'm getting that in my apache logs
[21:34] <Kobaz> maybe that's bad?
[21:34] <LarstiQ> Kobaz: it's not bad per se
[21:35] <LarstiQ> Kobaz: does -Dhpss reveal anything?
[21:35] <Kobaz> what am i giving that to?
[21:36] <Kobaz> bzr?
[21:36] <LarstiQ> Kobaz: yeah, with the push
[21:36] <Kobaz> KnitPackRepository('file:///usr/home/tmp/playground/.bzr/repository/')
[21:36] <Kobaz> (no details)
[21:36] <Kobaz> HPSS calls: 9 <bzrlib.transport.http.SmartClientHTTPMedium object at 0x84f9eec>
[21:37] <LarstiQ> Kobaz: (from `bzr help debug-flags`)
[21:37] <Kobaz> ah
[21:37] <LarstiQ> Kobaz: the details should be in ~/.bzr.log
[21:38] <mwhudson> Peng_: i think i hate paste
[21:38] <Kobaz> oh
[21:38] <Kobaz> whoops
[21:38] <Kobaz> i was using https://
[21:39] <Kobaz> i need to use bzr+https://
[21:39] <Kobaz> maybe there should be a note about that in the error output
[21:39] <Kobaz> Pushed up to revision 18.
[21:39] <LarstiQ> Kobaz: that, or fix it so that isn't necessary
[21:39] <Kobaz> i forgot i needed to use bzr+https... i haven't played with a new repo in a while
[21:39] <Kobaz> true
[21:39] <Peng_> mwhudson: You could switch back to CherryPy. :D
[21:39]  * Peng_ hides
[21:39] <LarstiQ> Kobaz: if that is still in the case in 1.13, please file a bug
[21:40]  * LarstiQ falls asleep
[21:40] <mwhudson> Peng_: maybe cherrypy3 would induce less homicidal rage
[21:42] <mwhudson> but also apache is screwing me over here
[21:42] <mwhudson> http://localhost:10101/bzr/lighttpd-1.4.x%2Fchanges gets me the same page as http://localhost:10101/bzr/lighttpd-1.4.x/changes
[21:42] <mwhudson> which is annoyting
[21:42] <mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x/changes proxies to the above just fine
[21:43] <mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x%2Fchanges gets me an apache 404 page
[21:43] <mwhudson> despite
[21:43] <mwhudson> <Location "/bzr/">
[21:43] <mwhudson>         ProxyPass http://127.0.0.1:10101/bzr/
[21:43] <mwhudson> being in my apache config
[21:44] <Kobaz> okay
[21:44] <Kobaz> 1.13 is okay with https://
[21:44] <Kobaz> oh wait
[21:44] <Kobaz> no
[21:44] <Kobaz> it died
[21:44] <Kobaz> it looked like it was going
[21:48] <Peng_> mwhudson: Apache isn't even proxying it back? That's strange..
[21:48] <Kobaz> so bzr-email isn't fireing off when i do a commit
[21:48] <mwhudson> Peng_: http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes !!
[21:49] <mwhudson> (what the heck!?)
[21:49] <lifeless> Kobaz: have you configured it?
[21:49] <Peng_> mwhudson: Does it explain why it does that?
[21:49] <mwhudson> Peng: no
[21:49] <mwhudson> i guess it's some harebrained security thing
[21:50] <Peng_> Yeah, probably.
[21:50] <mwhudson> maybe i'll just urlencode everything twice :)
[21:50] <Peng_> Or tell people to turn it off. :D
[21:50] <Kobaz> lifeless: yeah i set up the branch/branch.conf with some of the options
[21:50] <Peng_> I wonder if Lighttpd does the same thing?
[21:50] <Kobaz> lifeless: i added: post_commit_sender and post_commit_to
[21:50] <Kobaz> is there anytnig else i need
[21:51] <mwhudson> that works
[21:51]  * mwhudson sighs
[21:52] <Kobaz> would i have to reload apache?
[21:52] <yacoob> hm... I can't checkout/branch/pull part of the tree, can I?
[21:54] <mwhudson> Peng: try this barrel of fun: http://pastebin.ubuntu.com/132206/
[21:57] <Kobaz> lifeless: are there any other config files i need to monkey with other than branch.conf
[21:58] <mwhudson> Peng_: yeah, it's some lame security thing, as predicted http://mail-archives.apache.org/mod_mbox/httpd-users/200312.mbox/%3CPine.WNT.4.58.0312041453240.1444@Poste3947.hec.ca%3E
[21:59] <lifeless> Kobaz: are  you using it locally or ona server? On a server bzr-email doesn't see 'commit' as such, rather it seespushes
[22:00] <Peng_> mwhudson: Why is this only impacting +revlog, not anything else? Luck?
[22:00] <mwhudson> Peng_: we don't stick revids in urls very often any more
[22:00] <Kobaz> lifeless: server
[22:00] <igc> morning all
[22:00] <Kobaz> i push to the server and nothing happens except the push
[22:00] <Peng_> mwhudson: Sure, but you used to do it all the time.
[22:01] <Peng_> mwhudson: This patch works for me (just over localhost, no web server)
[22:01] <mwhudson> Peng_: yes, but now bzr-svn changed the way it does revids
[22:01] <lifeless> Kobaz: you need to set post_commit_push_pull=True as well
[22:01] <Peng_> mwhudson: Ah.
[22:01] <lifeless> Kobaz: run 'bzr help email' - if it does not document the post_commit_push_pull setting then you need a newer bzr-email plugin
[22:01] <Kobaz> do i need to put it under a specific section?
[22:01]  * Peng_ notes that Lighttpd doesn't do this security thing.
[22:02] <Kobaz> i dont have post_commit_push_pull in the help
[22:02] <lifeless> Kobaz: lastly, you need to be using the native bzr protocol - bzr:// or bzr+ssh:// or bzr+http:// for this to work
[22:02] <Kobaz> yeah, i a
[22:02] <Kobaz> m
[22:02] <Kobaz> okay, i upgraded bzr-email
[22:03] <Kobaz> still no workey
[22:03] <lifeless> did you add post_commit_push_pull=True ? (you put that where your other settings are)
[22:03] <Kobaz> yea
[22:03] <lifeless> hmm, odd
[22:04] <Kobaz> post_commit_sender, post_commit_to, post_commit_push_pull
[22:04] <lifeless> hi igc
[22:04] <Kobaz> are the only things i have in branch.conf
[22:04] <Kobaz> do they need to be under a specific section?
[22:04] <Kobaz> or just anywhere in the file
[22:04] <lifeless> top level, no sections at all
[22:05] <Kobaz> any kind of debugging on the server i can turn on?
[22:05] <Kobaz> to make sure it's actually loading the plugin, and etc
[22:05] <lifeless> the ~/.bzr.log file will have some info
[22:05] <lifeless> (on the server)
[22:07] <lifeless> hmm, looks like we don't list all the found plugins
[22:07] <lifeless> well, you can ssh to the server - "ssh <server> bzr plugins"
[22:07] <Kobaz> nothing in the log
[22:07] <Kobaz> k
[22:07] <Kobaz> email is listed in plugins
[22:07] <lifeless> ok, its finding it
[22:08] <Kobaz> i'm using apache with smartserver... if that makes a difference
[22:08] <lifeless> Kobaz: ah; hmm
[22:08] <lifeless> Kobaz: johnf-inodes did the same config as you a week or so ago
[22:09] <lifeless> he came up with this patch: https://code.edge.launchpad.net/~johnf-inodes/bzr-email/server_support
[22:09] <lifeless> I haven't reviewed it yet, but as he's using it at his organisation, I'm fairly sure it works :P
[22:11] <Kobaz> mm
[22:15] <Kobaz> okay so, i have that in now
[22:15] <Kobaz> still doesn't do anything :(
[22:16] <lifeless> uhm
[22:16] <lifeless> you're running under apache
[22:16] <lifeless> does the account apache is runnign bzr as, have the plugin installed (or did you install it globally?)
[22:16] <Kobaz> globally
[22:16] <Kobaz> i backed up the original one
[22:17] <Kobaz> oooo
[22:17] <Kobaz> i restarted apache
[22:17] <Kobaz> there it goes
[22:17] <lifeless> yay
[22:23] <poolie> lifeless, spiv, igc, for myself, i'm going to send the sprint report, finish the ui-related branches i did while travelling and on friday and generally pick up pieces
[22:23] <Kobaz> i'm a gonna have to go and learn python now
[22:24] <Kobaz> the bzr-email output isn't as purty as svnmailer
[22:24] <igc> poolie: can you re-review my/jam's dirstate patch please?
[22:24] <poolie> sure
[22:27] <lifeless> Kobaz: yes, thats true, there is probably a patch in https://code.edge.launchpad.net/bzr-email somewhere
[22:27] <lifeless> I didn't realise how many branches had collected :P
[22:28] <lifeless> igc: have you considered changing ls instead ?
[22:28] <lifeless> so that it does non-recursive by default
[22:29] <Kobaz> i should update my loggerhead too, i broke it somehow
[22:30] <igc> lifeless: ?
[22:31] <lifeless> igc: re: 'ls is slow'
[22:31] <igc> lifeless: my goal is a faster iter_entries() and ...
[22:32] <igc> to find places where iter_entries() could be replaced by a faster method, e.g. one not calculating paths if the path is never used
[22:32] <lifeless> igc: both iter_entries and iter_entries by dir can do partial tree as well as full tree
[22:32] <lifeless> igc: via the from_dir and specific_file_ids parameters; it may need more work than just paging the full thing in
[22:32] <igc> lifeless, but they have explicit constraints on order
[22:33] <igc> lifeless: sure
[22:33] <lifeless> also, I'm confused, because I would have thought its the same amount of work either way - or are the pages being read multiple times?
[22:34] <igc> lifeless: iter_changes explicitly walks from the root down - it's the children calculations that are the slow bit
[22:36] <igc> lifeless: I'm yet to look at jam's code but I'm not surprised he got much faster results by calculating children in one pass rather than each time
[22:36] <lifeless> igc: All I'm saying, is its surprising that .children is slow, its meant to be fast, and that iter_entries is not just-full-tree.
[22:36] <lifeless> igc: beyond that its in your court :)
[22:36] <lifeless> separately, I'm sorry, but I had to bb:resubmit your check patch
[22:37] <lifeless> it removes a downwards sha1 validation
[22:37] <igc> lifeless: I didn't see that and just submitted it to pqm. Can you cancel it for me.
[22:37] <igc> please?
[22:38] <CardinalFang> Er, what am i doing wrong?  make new project. ... "bzr init .; bzr add .; bzr commit -m 'Initial import.';"
[22:38] <lifeless> I've wanted to make check faster too, but I stopped at that point; it needs something like a text_key->sha1 mapping held open
[22:38] <lifeless> igc: stopped it
[22:38] <CardinalFang> -> bzr: ERROR: No such file: ('TREE_ROOT', 'foo@bar-1234-1234blahblah')
[22:39] <lifeless> then we can get all the texts, get their sha1, and make sure it matches
[22:39] <igc> lifeless: I'm confused. I didn't take out the call to ie.check()
[22:39] <lifeless> CardinalFang: get rid of the '.'s, you don't need them
[22:39] <CardinalFang> Huh.  I do for "add", I think.  Okay.  Retrying.
[22:39] <lifeless> igc: oh. I may have misread, let me read again
[22:40] <lifeless> CardinalFang: you don't for add, or for init
[22:40] <lifeless> CardinalFang: in general bzr assumes ., or $(bzr root) for any command that takes a path
[22:40] <lifeless> CardinalFang: with a few key exceptions
[22:41] <CardinalFang> ("revert")
[22:41] <lifeless> CardinalFang: and in fact, 'bzr revert .' is != 'bzr revert' because the '.' says the tree only, and that means we don't revert metadata
[22:41] <CardinalFang> :)
[22:42] <lifeless> igc: oh totally my bad
[22:42] <igc> lifeless: if you prefer, I could walk the inventory via "entry in inv" and use id2path() to find paths. That might be safer?
[22:42] <lifeless> igc: go for it, its good. I was indulging in wishful thinking it appears
[22:42] <igc> in check_revision_tree
[22:42] <igc> lifeless: np. I'll resubmit
[22:42] <CardinalFang> lifeless: Hrm, could my problem be a shared repo I have in the parent?
[22:43] <lifeless> igc: I was hoping you'd removed the key issue I have
[22:43] <lifeless> CardinalFang: possibly, is it a rich root format by chance?
[22:43] <lifeless> CardinalFang: you tried with no '.''s?
[22:44] <CardinalFang> lifeless: Yes, same thing.
[22:44] <lifeless> CardinalFang: please run with -Derror, you'll get a backtrace
[22:44] <CardinalFang> /usr/local/lib/python2.5/site-packages/bzrlib/revisiontree.py(82)iter_files_bytes()
[22:44] <CardinalFang> -> raise errors.NoSuchFile(e.revision_id)
[22:45] <CardinalFang> top of stack.
[22:45] <lifeless> CardinalFang: thats all?
[22:45] <CardinalFang> (I have BZR_PDB set -- assuming that does the same.)
[22:45] <lifeless> CardinalFang: no, it doesn't
[22:45] <CardinalFang> Er, no.
[22:45] <lifeless> BZR_PDB puts you into a debugger
[22:45] <lifeless> hit bt
[22:45] <lifeless> and you'll get the full stack
[22:47] <CardinalFang> Ah, okay.  Not your fault.  It's in my stuff.  Thanks, lifeless.  Sorry for the noise.
[22:49] <lifeless> CardinalFang: you have a plugin or some such ?
[22:50] <CardinalFang> Yes.  It lacks the special case for first revision in some diff code.
[22:50] <lifeless> heh
[22:52] <thrope_> is launchpad supposed to be open for public use?
[22:52] <lifeless> thrope_: it is
[22:52] <thrope_> I tried to create a project there to mirror a google code svn repo but it just says 'pending review'
[22:52] <lifeless> thrope_: anyone can use it for open source projects
[22:52] <thrope_> who reviews it and when?
[22:52] <lifeless> code imports require a review
[22:52] <CardinalFang> All after I updated bzr on two machines at once, and horrors! one of my first operations broke!  Silly me.
[22:52] <lifeless> the code import team
[22:53] <thrope_> lifeless: but if I push it from a bzr branch no review is needed?
[22:54] <lifeless> thrope_: right; when we import we do a lot of traffic to other sites, and we're the ones grabbing the code - we need to confirm the details, check the licence etc
[22:54] <thrope_> ok
[22:54] <lifeless> if you push you are required to meet the terms of service
[22:54] <lifeless> which include only pushing code you legally can etc etc
[22:54] <thrope_> but the import will track the svn repo automatically, so I guess its better to wait
[22:55] <lifeless> anyhow, if you ask a question on answers.launchpad.net/launchpad-bazaar, one of the guys will get to it soon
[23:16] <Peng_> mwhudson: Thanks for figuring out and fixing my Loggerhead issue. :)
[23:16] <mwhudson> Peng_: thanks for being the loggerhead canary :)
[23:17] <mwhudson> Peng_: i don't suppose you want to test the new trunk with IE?
[23:31] <Peng_> mwhudson: Sorry, no Windows boxes, and I'm not installing WINE. :P
[23:31] <mwhudson> Peng_: fair enough :)
[23:32] <rockstar> mwhudson, later today I can try it with the Windows VM.
[23:32] <mwhudson> rockstar: cool, don't stress about it
[23:32] <mwhudson> but if you have time, neat!
[23:33] <Peng_> mwhudson: I suppose I could break into my father's place and steal his laptop... :)
[23:33] <mwhudson> i can usually use my other half's work laptop
[23:33] <mwhudson> but she's not here this week
[23:34] <mwhudson> um what
[23:34] <mwhudson> xchat just fell over :(
[23:34] <Peng_> Well, you didn't miss anything.
[23:38] <lifeless> 10:29 < mwhudson> but she's not here this week
[23:38] <lifeless> 10:29 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has quit [Remote closed the connection]
[23:38] <lifeless> 10:30 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has joined #bzr
[23:38] <lifeless> 10:30 < mwhudson> um what
[23:38] <mwhudson> cool
[23:41] <mwhudson> do you have to give Repository.iter_files_bytes a revision id that touched the file you're asking for?
[23:41] <lifeless> yes
[23:42] <lifeless> generally, don't use iter_files_bytes
[23:42] <lifeless> use RevisionTree.iter_files_bytes
[23:43] <mwhudson> fair enough
[23:43] <lifeless> because RevisionTree knows what you need :P
[23:43] <mwhudson> i was hoping to avoid loading the inventory
[23:43] <mwhudson> but yes, working first
[23:43] <lifeless> well
[23:43] <lifeless> how would you figure out the text you want without the inventory
[23:44] <lifeless> develop on chk formats, you'll get a much better picture
[23:44] <mwhudson> yeah, fair enough
[23:50] <jml> so, I'm pulling down bzr.
[23:51] <jml> err, launchpad.
[23:51] <jml> and the progress bar says 6MB (& it's around 50% complete). what does this number mean?
[23:52] <jml> I find it strange to think that ten hours worth of changes to trunk could total more than 12MB
[23:54] <lifeless> jml: well, there's nearly 50% overhead in the plain vfs methods
[23:55] <jml> lifeless: it ended up being ~25MB
[23:55] <jml> lifeless: I guess that'll go down once Launchpad upgrades its bzr
[23:55] <lifeless> yes
[23:55] <jml> lifeless: is the number total throughput or just downloaded bytes?
[23:55] <lifeless> total
[23:56] <lifeless> up + down for-all transports
[23:56] <lifeless> so total IO except local-disk isn't reported
[23:56] <jml> *nod*