[00:02] <markh> jam: the win32 binaries I'm putting together will have at least a couple of patches from 1.6 (setup.py/inno) - how do you feel about me also keeping those other test suite changes in?  But if you think its important we only apply strictly necessary patches I'll back them out of my local tree.
[00:03] <jam> hi markh
[00:03] <markh> hi john
[00:03] <jam> I'd rather have it be stock 1.6 if at all possible
[00:04] <jam> For example, getting those patches in, would be something to get into 1.6 final
[00:04] <markh> I guess you'd say that, which is why I thought I better ask ;)  np
[00:04] <jam> And would have been something I would have liked mentioned earlier....
[00:04] <jam> Supporting multiple versions is a real pain whenever there is skew
[00:04] <markh> what would you have liked mentioned earluer?
[00:04] <jam> markh: that you are going to need the setup.py/inno patches for the win32 release
[00:05] <jam> So I would rather bring in something with a bit of cruft if it is going to be the *official* version anyway.
[00:05] <jam> Though I'd really rather not bring in cruft :)
[00:05] <markh> these are the same patches I've previously sent for the build process.
[00:05] <spiv> jam: here
[00:06] <jam> So... standup meeting for 2008-08-13
[00:06] <markh> with yet more tweaks as I find issues in testing, such as uninstall problems, etc
[00:06] <jam> spiv: what are you working on today and yesterday
[00:06] <jam> markh: I understand the patches you are describing, I wish you had nominated them as 1.6 patches.
[00:06] <jam> Since you are going to use them for a 1.6 release
[00:07] <jam> hence.... they need to be in 1.6
[00:07] <markh> they aren't complete - I last made a change 3 days ago to it
[00:07] <spiv> Yesterday I got the improved testing docs merged, reviewed some of lifeless's stuff, and made a bit of progress on the HPSS effort tests.
[00:07] <spiv> Today I'm going to focus on the effort tests, plus mentally willing 1.6 to get released ;)
[00:07] <jam> markh: I would rather you focused on getting something complete, that can be a 1.6 release, than having it perfect.
[00:08] <jam> We can make it perfect for 1.7
[00:08] <spiv> 1.7 isn't very far away, after all.
[00:08] <jam> markh: I'll be the 1.7 manager, and if I have any say about it, we'll follow a strict timetable
[00:08] <jam> so pushing 1.6 back
[00:08] <jam> means that 1.7 will release the next day
[00:09] <jam> spiv: ok, today was focused on getting 1.6rc2 out the door
[00:09] <jam> which was successful
[00:09] <markh> I don't see a huge issue in me releasing my "bzr + tortoise" binaries called "1.6" when they are infact 1.6 + 2 build/installer related patches
[00:09] <markh> with zero changes to bzr itself
[00:09] <spiv> jam: hooray!
[00:09] <jam> markh: Because I can't do "bzr co http://bazaar-vcs.org/bzr/bzr.1.6" and get what we released as bzr-1.6-win32
[00:10] <jam> markh: aka, I can't easily *reproduce* your work
[00:10] <jam> It is all on *you*, and I'd rather have it in the system
[00:11] <jam> markh: If you feel it isn't really worth merging, perhaps it could be a bzr-1.6-win32 branch or something
[00:11] <jam> but I'd really rather avoid that.
[00:11] <markh> if I publish those 2 patches, and those patches are only related to the binaries built that include tortoise, then I really don't share your concern.  Release a stand-alone binary without tortoise using the existing setup.py if it bothers you that much
[00:11] <jam> I *really* want a snapshot we could use.
[00:12] <jam> markh: I don't want you to be the only person who can make a release of the official binaries. I think that is a valid concern.
[00:12] <jam> I think for development processes
[00:12] <jam> having the release be
[00:12] <jam> tag the branch
[00:12] <jam> 'make dist'
[00:12] <jam> publish results
[00:12] <jam> is a wonderful workflow
[00:12] <jam> Having it be
[00:12] <jam> make dist
[00:12] <jam> then apply 3 patches
[00:12] <jam> then make win32-installer
[00:13] <jam> etc
[00:13] <jam> is not a good *process*
[00:13] <jam> which is what I'm trying to avoid.
[00:13] <jam> spiv: Tomorrow is more triaging to make sure we are ready for 1.6-final, as well as getting my stuff together for 1.7 Metronome emails
[00:13] <jam> (something we have also been missing)
[00:13] <jam> TWiB should also be happening tomorrow
[00:13] <jam> as I've missed it for 2 weeks now.
[00:14] <jam> rockstar: ^^
[00:14] <jam> And I'd *like* to get to bringing the btree code into core bzr
[00:14] <jam> I may not get that far.
[00:15] <jam> lifeless: speaking of which, I'd like to hear your thoughts on a 1.6-final that had the log regression.
[00:15] <jam> Martin seemed to feel it was a critical blocker
[00:15] <jam> but he's not here to expand on that
[00:15] <spiv> TWiB?
[00:15] <spiv> Oh, right
[00:15] <jam> This Week in Bazaar
[00:15] <markh> yes, I agree its not a good workflow and I don't propose it as an ongoing process.  Regardless, I consider myself appropriately scolded
[00:15] <jam> markh: So make them public, I'll merge them for 1.6-final
[00:15] <jam> and the problem is solved :)
[00:16] <jam> As long as they are *usable*
[00:16] <jam> You've convinced me about bundling TBZR
[00:16] <jam> And you've almost convinced me about paramiko
[00:16] <markh> that wasn't your approach when you reviewed them last time!
[00:16] <jam> markh: I need a release
[00:16] <jam> that causes friction :)
[00:16]  * awilkins can build the win32 stuff (up to the python installers so far)
[00:16] <jam> I don't want to use an ad-hoc release unless we must.
[00:17] <jam> awilkins: I can build the installers, but I would like to have our "official" build, which will be TBZR + qbzr, etc.
[00:17] <jam> Either we get it for 1.6
[00:17] <jam> or it gets delayed to 1.7 IMO
[00:17] <awilkins> Hmm.
[00:17] <markh> I'll get it to you in an hour
[00:17] <jam> I'd rather not have an ad-hoc build for 1.6
[00:17] <awilkins> Is qbzr better than Olive?
[00:17] <jam> markh: If they are as unintrusive as you say, I'll be okay bringing them in for 1.7
[00:17] <johnf> anyone about that can help me track down #254797, _read_bytes not defined when using smart protocol
[00:17] <jam> awilkins: It is more Windows-like
[00:18] <jam> as it is built on QT
[00:18] <jam> there are tradeoffs between the two
[00:18] <jam> qlog is better than bzr viz (IMO)
[00:18] <jam> but gannotate is better than qannotate
[00:18] <awilkins> bzr viz is what I use most
[00:18] <jam> awilkins: qlog allows folding merges
[00:18] <awilkins> Hows the conflict dialog?
[00:18] <jam> which is *huge* for me.
[00:18] <spiv> johnf: I can
[00:18] <jam> awilkins: I don't know that qbzr has conflict handling yet.
[00:18] <spiv> johnf: in a few minutes
[00:19] <johnf> spiv: cheers
[00:19] <jam> spiv: I ran into that for _urllib when BB was not giving proper 404's by the way.
[00:19] <awilkins> I have a patch to the bzr-gtk conflict window for starting my favourite win32 merge tools
[00:19] <jam> spiv: anything else?
[00:19] <jam> (for standup)
[00:19] <markh> awilkins: wrt qbzr and tortoise, its probably fair to say we see better potential in qbzr, rather than thinking qbzr is already more "complete"
[00:19] <jam> markh: Sounds good. I'll look forward to reading them tomorrow. If you are up late, I'd love to chat with you a bit
[00:19] <jam> both about the locking issues you were seeing
[00:19] <markh> and more potential specifically in the context of tortoise!
[00:19] <jam> and about your development, etc.
[00:20] <awilkins> Anyway, bed time
[00:20] <jam> But now is family time
[00:20] <markh> np - thanks
[00:20] <jam> I might also be around in a couple hours depending on when everyone sleeps.
[00:20] <markh> The good thing is that all these branches is actually giving me real experience doing non-trivial merges :)
[00:20]  * jam => away
[00:20] <spiv> jam: interesting
[00:21] <spiv> jml: no, not for the standup, thanks!
[00:22] <n[ate]vw> is there any way to copy/move a file WITH HISTORY between projects?
[00:22] <jml> spiv: not for what standup?
[00:22] <n[ate]vw> I'm developing an app with components I'd like to eventually move into separate libraries
[00:25] <lifeless> jam: reply, with worked example, which I think is what you wanted
[00:25] <n[ate]vw> bzr move cannot move between branches, which would be where I'd expect to see that, but was wondering if projects within a combined repo gave any benefits like that
[00:25] <lifeless> jam: catch you later
[00:26] <lifeless> jam: I know that martin would really like to avoid the log regression
[00:26] <lifeless> I'm not sure how to do that :P
[00:26] <james_w> n[ate]vw: that's not possible as far as I know
[00:26]  * markh wonders what will happen if he sneaks in a transparent version of bzr.ico rather than the one that is in the branch...
[00:28] <n[ate]vw> james_w: so no plugins could either? basically, I'd be nice to take files like MyFloatStuff.c and MyMathStuff.c and put them into a separate "NumberLibrary" project without losing the histories
[00:29] <james_w> n[ate]vw: not possible. You could take a branch and delete everything else from the branch and just have the two files from that point on
[00:31] <n[ate]vw> that might work alright, especially if bzr ever gets horizons (?) or whatever they call branching just a recent history
[00:32] <james_w> stacked branches are in 1.6, history horizon is a way off
[00:33] <lifeless> uhm
[00:33] <lifeless> bzr split
[00:33] <lifeless> kthxdone
[00:34] <james_w> lifeless: your rules patch still has "respectively" in the docs, now for a singular item
[00:35] <n[ate]vw> james_w: seems like I just skimmed something about stacked branches, but do you have a link?
[00:35] <n[ate]vw> lifeless: excellent, thanks
[00:36] <lifeless> james_w: thanks
[00:36] <markh> I gotta love "merge --reprocess" - it took a 74 line conflict region down to the 1 line it really is :)
[00:37] <spiv> jml: your nick is too close to jam's :(
[00:37] <spiv> jml: at least for these pre-coffee fingers.
[00:37] <jml> spiv: you know the solution to that!
[00:38] <lifeless> cut off the fingers!
[00:38] <n[ate]vw> james_w: n/m found http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html which was enough of a memory jog, I think I saw that in the checkouts help or something
[00:39] <n[ate]vw> oh, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-stacked-branches is where I saw it, FTR
[00:39] <lifeless> abentley: are you around ?
[00:40] <lifeless> abentley: my fix to iter_changes to be consistent has found a bug in diff that would show up on non-dirstate trees
[00:40] <lifeless> abentley: but I'm not sure of the right behaviour
[00:47] <rockstar> jam, TWiB is acknowledged, with high priority.
[00:49] <lifeless> markh: what does bundling mean?
[00:49] <lifeless> markh: I hoep it doesn't mean 'import into trunk' ?
[00:49] <markh> one sec...
[00:49] <johnf> spiv: so it looks like medium.py is calling read_bytes on HTTPTransportBase but it's only implemented in SmartClientHTTPMediumRequest so maybe the read bytes should be on getsmartmedium??
[00:50] <johnf> I'm totally poking in the dark here of course since I have no understanding of how this all fits together :)
[00:50] <mwhudson> lifeless: i don't think abentley is aroudn
[00:51] <lifeless> johnf: what bzr version?
[00:52] <johnf> lifeless: 1.6rc2 and  bzr.dev seems to exhibit the same bug
[01:02] <spiv> johnf: Ok, I'm looking into this one now.
[01:02] <johnf> spiv: let me know if I can help at all
[01:02] <johnf> spiv: I'm happy to look into it if pointed in the right direction
[01:04] <spiv> johnf: I think I have an idea about what's going on
[01:04] <spiv> johnf: I landed a change in 1.6 that tidied up a bunch of the logic around _read_bytes in bzrlib/smart/medium.py
[01:05] <spiv> johnf: part of that I think was moving methods from the mediumrequest into the medium
[01:05] <johnf> spiv: that makes sense
[01:05] <spiv> It wouldn't surprise me if the HTTP code didn't quite keep up.  I thought I had fixed it (I definitely remember touching the HTTP code during that work), but I guess our test coverage is a bit lacking here.
[01:11] <spiv> Ah, I think SmartClientHTTPMediumRequest needs to implement read_line
[01:11] <markh> lifeless: the bzr binary will bundle a few other binaries too (bzr-svn, qbzr, tortoise).  The bzr.dev trunk's setup.py will get that capability, but no other code will be imported.  Is that what you were asking?
[01:11] <spiv> Otherwise the default implementation falls back to calling that method on the medium, which is unimplemented in this case.
[01:12] <lifeless> markh: cool; I was wondering if you intended to drop a copy of paramiko into the trunk etc
[01:12] <lifeless> markh: that would have been concerning
[01:13] <markh> lifeless: nope - just setup.py will kinda assume it is in-place when you make binaries
[01:14] <lifeless> markh: windows binaries right ?
[01:14] <markh> correct
[01:14] <lifeless> kool
[01:15] <markh> from a QA POV, we probably need to get the the point where setup.py nominates *exactly* what is bundled and fails if anything isn't there.  It shouldn't be possible to "forget" to include something - but that can wait...
[01:21] <lifeless> spiv: bug 257730
[01:22] <spiv> johnf: ok, I have a probable fix in hand
[01:23] <spiv> johnf: http://rafb.net/p/XvhCPc82.html
[01:23] <spiv> lifeless: that looks like the same bug, thanks
[01:24] <lifeless> yah
[01:26] <spiv> jam: I'm going to ask for the fix I'm doing for #254797 to go in 1.6
[01:32] <rick_h_> lifeless: ping
[01:33] <lifeless> hi
[01:33] <rick_h_> hey, first, thanks for the help on the article. The feedback from the head editor was great and it'll be out in pymag in sept
[01:33] <rick_h_> got bumped up a month
[01:34] <lifeless> cool
[01:34] <rick_h_> I got asked to do a follow up article and I was thinking of covering a couple of workflows. Mainly a centralized (for the svn folks) and decentrailzed with share mainline
[01:34] <rick_h_> as I think those two are pretty common/useful for a large group out there
[01:34] <lifeless> sounds good
[01:34] <rick_h_> is that your take or would another workflow better show off bzr or anything?
[01:34] <lifeless> uhm
[01:35] <lifeless> I think you should write about things you've experienced or played with
[01:35] <lifeless> or helped people with
[01:35] <rick_h_> ok, definitely
[01:37] <spiv> It doesn't help that pycurl tests give (55, 'select/poll returned error') on my laptop.
[01:41] <johnf> spiv: that did the trick. Thanks
[01:48] <spiv> johnf: it has a bug, though :)
[01:48] <spiv> johnf: you may also be able to work around it by prefixing "nosmart+" to the http:// URL.
[01:49] <spiv> johnf: I'll send a polished patch to the list fairly shortly.
[01:49] <johnf> spiv: except I'm using a smart server bzr+https://
[01:49] <spiv> Ah, in that case not so much :)
[01:49] <spiv> (The buglet is that there's a "return bytes" line in the _get_line function that needs to be "return bytes, ''"
[01:50] <spiv> )
[01:50] <spiv> (Probably not significant in normal use)
[02:01] <Peng_> Whoever just branched from my server (LP?) managed to download half of a 2 MB pack once, then the entire pack twice. Good going, bzr.
[02:01]  * Peng_ is away now.
[02:01] <lifeless> Peng_: bleep
[02:02] <lifeless> Peng_: same IP ?
[02:05] <spiv> Peng_: That would be me and my squid proxy I think.
[02:05] <spiv> Peng_: sorry!
[02:06] <lifeless> spiv: upgrade it :)
[02:06] <spiv> lifeless: get it backported to hardy (or point me to a PPA I guess...)
[02:06] <lifeless> spiv: feh
[02:07] <spiv> lifeless: that's my attitude too ;)
[02:07] <lifeless> spiv: need a review for that patch"
[02:07] <lifeless> ?
[02:07] <lifeless> also, my rules one needs a review
[02:08] <lifeless> and I'm wondering if we should file a bug on python for that 'cant write 80MB on smb reliably' bug
[02:08] <spiv> lifeless: I will need a review soon, not quite yet.
[02:09] <spiv> lifeless: hmm, probably.  what happens exactly?  Large writes get an EINVAL sometimes?
[02:09] <lifeless> 22 whatever that is
[02:10] <lifeless> bug 255656
[02:12] <spiv> lifeless: yeah, I'd bugger a file
[02:12] <spiv> lifeless: I wouldn't be very optimistic about it getting fixed, but you never know...
[02:15] <jonnydee> lifeless: hi, regarding your solution to bug ﻿255656: I was told here that the solution is considered to be just a workaround for a bug in python....
[02:16] <jonnydee> and that workarounds are not likely to be merged into bzr 1.6
[02:16] <Peng_> Ah, Squid. That would explain it.
[02:17]  * Peng_ goes back to being away.
[02:17] <jonnydee> what do you think? will there be a achance to get it merged into future revision (for the case python's bug doesn't get fixed)
[02:17] <Peng_> spiv: You owe me $0.003 in wasted bandwidth!
[02:18] <spiv> Peng_: I'll have to buy you 1 mL of beer sometime...
[02:28] <lifeless> jonnydee: its a bug
[02:29] <lifeless> jonnydee: bzr supports python 2.4, so we have to fix it in bzr
[02:39] <jml> rockstar: btw, did you end up doing much with that plugin you were writing in Dunedin?
[02:40] <rockstar> jml, yes, but I haven't polished it.  I didn't think there was much interest in it, so it got to my needs, and I quit.  :)
[02:40] <rockstar> Would you like me to make an official lp project for it?
[02:41] <warren> hmm, is there a way for me to edit the checkin message after it was committed?
[02:41] <jml> rockstar: do you have a published branch at least?
[02:41] <rockstar> jml,  no
[02:41]  * rockstar is ashamed
[02:43] <jml> rockstar: +junk!
[02:43] <rockstar> jml, yea yea...
[02:43] <Peng_> warren: If you haven't pushed yet, and it's the most recent revision, you can uncommit and recommit.
[02:44] <warren> someone else committed it, but I want to edit the commit message before pushing it to the real trunk
[02:45]  * Peng_ goes back to being away.
[02:47] <mwhudson> Peng_: you don't seem to be very good at being away
[02:51] <jml> lifeless: so, we still hacking on Saturday?
[02:51] <jml> if so, where, when and can RAOF come too?
[02:53] <lifeless> I want to buy lingua latina
[02:53] <lifeless> I think lynne would probably appreciate a little space, so not here
[02:53] <lifeless> sure RAOF would be good company too
[02:54] <RAOF> Howdie.
[02:54] <RAOF> My place _could_ work.  Possibly.  There's a table and couch and stuff.
[02:55] <lifeless> RAOF: where is your place?
[02:55] <RAOF> Kensington.  That makes it quite some way from both you and jml
[02:55] <lifeless> indeedy
[02:56] <lifeless> jml: whats your place like?
[02:56] <jml> internetless.
[02:56] <lifeless> jml: where are you now?
[02:56] <jml> lifeless: spiv & Mary's place
[02:56] <lifeless> ah
[02:56] <lifeless> and next week ... ?
[02:57] <jml> probably still up at Andrew & Mary's -- I've got a key.
[02:59] <lifeless> well, there is a possibility. If spiv and mary would be happy with that.
[02:59] <lifeless> I'll check in with Lynne when she gets home about doing it here
[03:01] <jonnydee> lifeless: ahh, ok -- thanks, taht's good news :)
[03:13] <Leefmc> Question: Does bzr have any problem with many commits? Ie, are tiny commits about fixing little bugs, etc, acceptable in BZR?
[03:14] <james_w> Leefmc: absolutely
[03:14] <Leefmc> james_w: K
[03:15] <pickscrape> Anyone else used "Editra" before? I just learned of it today and it appears to have bzr support out of the box.
[03:18] <jml> lifeless: Kensington isn't that far away.
[03:20] <markh> where has spiv gone?
[03:21] <markh> or going? :)
[03:22] <markh> oh bugger - I see I should have put a 1.6 in the subject line for BB to see it targets 1.6...
[03:23] <spiv> lifeless: if it means the plants get watered, then we can probably cope with that...
[03:24] <spiv> markh: I'll be spending a couple of weeks in the South Island of NZ
[03:24] <markh> ahh, nice :)
[03:24] <spiv> markh: and trying not to cut my head open with a snowboard ;)
[03:24] <markh> oh that's right - you do that regularly?
[03:25] <spiv> Not very, which is probably the problem...
[03:25] <markh> :)
[03:27] <spiv> lifeless: fix for #254797 sent to the list, btw
[03:27] <lifeless> spiv: cool
[03:29] <lifeless> jml: I know where spivs place is better
[03:30] <markh> let's all party at spiv's while they are gone!
[03:53] <lifeless> jam: welcome back :)
[03:53] <jam> lifeless: well, for a bit at least
[03:53] <lifeless> so I sent in a patch, its really quite tiny
[03:56] <fullermd> Mmph.  Has check gotten slower?
[03:56] <jam> lifeless: so you basically just changed it so there are *no* per-branch config items?
[03:56] <ToyKeeper> Hmm, I thought there was some easy, obvious way to split a subdir with history into a new branch, but I don't see it.
[03:56] <jam> I thought the point was to not version them
[03:56] <jam> not to disable them completely
[03:57] <lifeless> jam: Martin's request was to disable it rather than not-version
[03:57] <lifeless> as he says:
[03:58] <lifeless> If this is not baked yet then I think it would be cleaner to remove
[03:58] <lifeless> the feature of reading from this file, rather than specially blocking
[03:58] <lifeless> it out from being committed.  We could still perhaps allow a branch or
[03:58] <lifeless> plugin for trying filters to turn it back on.
[03:58] <jam> ah, I do remember that.
[03:58] <jam> Good enough I guess.
[03:58] <jam> I still disagree with it, and I don't quite feel that Ian agrees, but I can accept the "lets postpone for now"
[03:58] <lifeless> thank you
[03:59] <lifeless> I'll merge that patch to trunk now then?
[03:59] <jam> lifeless: please don't tie up the pqm yet :)
[03:59] <jam> If I'm lucky, I'll get the 1.6 stuff merged that people want
[03:59] <jam> and we can do a rc3 by tomorrow
[03:59] <jam> so -final doesn't have to be delayed.
[04:03] <lifeless> that would be good
[04:03] <lifeless> I'll merge the rules after you go then
[04:04] <jam> lifeless: It seems your patch is built on bzr.dev, not bzr 1.6
[04:04] <lifeless> do you want me to merge it to trunk and 1.6, or you'll do the cherrypick ?
[04:04] <jam> So I'll cherry pick it
[04:04] <jam> and you can merge it directly to trunk
[04:04] <lifeless> ok
[04:04] <beuno> mwhudson, hi
[04:04] <beuno> I just addressed your review on my diff branch
[04:04] <lifeless> jam: on inventories; does my worked example demonstrate the things you were concerned about ?
[04:04] <mwhudson> beuno: hi
[04:05] <fullermd> lifeless: Did you ever get a chance to look back at bug 255155 (knit file permissions)?
[04:05] <mwhudson> beuno: oh right
[04:05] <lifeless> fullermd: no, I haven't
[04:05] <mwhudson> beuno: i still think the diff should be against compare_revid if there is one
[04:05] <lifeless> fullermd: can you upgrade to packs ?
[04:05] <beuno> mwhudson, and see 2 remaining bugs. The javascript one, I can squash tomorrow. bug #243415, not so sure about where to start
[04:05] <jam> lifeless: Well you mention "minor variations" which doesn't seem to fit well with validators and "deterministic" values
[04:05] <lifeless> jam: I say that if we *don't do X* there would be
[04:06] <lifeless> jam: the sentence before described X
[04:06] <beuno> mwhudson, aaaaaaaaaaaah, I see.  I understand what you meant now.  I tend to ignore the fact that we have compare_id, since the UI for it is so ugly
[04:06] <fullermd> lifeless: Well...   _can_.  would rather not, for non-technical reasons.
[04:06] <mwhudson> beuno: yeah, but ...
[04:06] <lifeless> fullermd: you have users using bzr < 0.92 ?
[04:07] <fullermd> lifeless: No, but it means a soft-flag day of making everyone upgrade their branches (or swallow abysmal performance).  And there'll be a hard flag coming up shortly when the next and rich-root-capable standard format comes along (in 1.2 or something soon like that)
[04:07] <lifeless> fullermd: the problem with permissions is they don't really work well enough
[04:08] <lifeless> fullermd: huh? why would there be a performance hit?
[04:08] <fullermd> I'd rather only ram that through once.
[04:08] <fullermd> Because pulling from packs into knits was life-threateningly slow, at least last time I tried.
[04:08] <fullermd> Re-annotating and all.
[04:08] <lifeless> fullermd: please try again, it should not be
[04:08] <lifeless> fullermd: make sure you have the C extensions
[04:09] <beuno> mwhudson, I'll address the compare_id bit. Any ideas for #243415?
[04:09] <fullermd> Hm.  I'll try to fiddle with that tonite...
[04:09] <mwhudson> beuno: well, serve-branches still doesn't actually have a logging section, does it?
[04:09] <lifeless> fullermd: slower-than-normal yes, life threatening slow - no, jam fixed that weeks ago
[04:10] <beuno> mwhudson, it looks like it does, yes
[04:11] <markh> jam: thanks for the approval.  Shall I upload my current rc2 binary directly to launchpad for the project and mail the bzr list, to try and get some feedback in time for a final?  Or would you prefer more controlled testing by people first?
[04:11] <mwhudson> beuno: well, not one that sets up logging to a file ... ?
[04:11] <lifeless> jam: this was the quote I think:"If we add a
[04:11] <lifeless> constraint to the usual LPC rules that we must bubble compression
[04:11] <lifeless> opportunities as high up the tree as possible, then yes. If we don't, I
[04:11] <lifeless> think it is possible to have minor variations."
[04:11] <jam> spiv: ugh... I just hit something nasty
[04:11] <lifeless> jam: I was trying to be complete, possibly adding confusion.
[04:11] <jam> I'm using bzr-email on a bound branch over bzr+ssh
[04:11] <jam> and it seems to be doing the log on the bzr+ssh branch
[04:11] <jam> and taking *forever*
[04:12] <jam> markh: well, if beuno is up for it, we may have a 1.6rc3 tonight/tomorrow early
[04:12] <jam> with your changes in it
[04:12] <beuno> mwhudson, doesn't line 48+ do that?   http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/210?file_id=servebranches.py-20080618011543-s6ydx5c3bl38zap6-1
[04:12] <markh> my rc2 binary has only those changes you just approved.
[04:12] <markh> (oh - and an icon with a transparent background ;)
[04:13] <beuno> jam, I can do rc3 tomorrow morning, sure  (~10hs)
[04:13] <beuno> mwhudson, ignore me, it seems it doesn't
[04:13] <jam> markh: ... what did I just mention about having the official build as part of core? :)
[04:13] <beuno> mwhudson, I'm tired  :)
[04:13] <mwhudson> beuno: fair enough :)
[04:13] <beuno> mwhudson, so, not for 1.6?
[04:14] <mwhudson> beuno: so loggerhead _should_ have logging and the logging _should_ capture tracebacks...
[04:14] <mwhudson> beuno: but yeah
[04:14] <beuno> mwhudson, ok, different bug to address
[04:15] <beuno> mwhudson, how does releasing 1.6 this week sound?
[04:15] <mwhudson> beuno: awesome!
[04:15] <beuno> \o/
[04:15] <beuno> jelmer even packaged it, so I can probably upload it to PPA
[04:17] <beuno> pickscrape, how's your branch coming along?  can you make it this week?
[04:22] <jam> lifeless, spiv: I would really like to include a NEWS entry with your changes.
[04:22] <jam> Especially for "reasons why we went past an rc" I feel each commit should have a NEWS entry.
[04:23] <jam> Could you write up a simple one for me?
[04:23] <lifeless> sure, I guess
[04:23] <mwhudson> beuno: that's a point
[04:23] <mwhudson> beuno: how is loggerhead's NEWS doing?
[04:23] <beuno> mwhudson, well, it's...  uhm...  we try not to push it too hard
[04:24]  * beuno adds another task to his ToDo list
[04:24] <mwhudson> i guess we should write some stuff
[04:24] <mwhudson> beuno: oh, also, we have the issue that if i merge the current loggerhead trunk to launchpad's codebase
[04:24] <mwhudson> beuno: it will go blue
[04:24] <mwhudson> we should, um, do something about that
[04:25] <beuno> mwhudson, ah, yeah, I'd have to merge && revert && commit. If you point me at the branch tomorrow, I'll merge it in
[04:25] <mwhudson> beuno: ah yeah, that'll work
[04:31] <Jucato> good day/evening. is there a logout equivalent to bzr launchpad-login?
[04:31] <lifeless> Jucato: I don't think so
[04:31] <lifeless> jml: ^
[04:31] <jam> lifeless, markh, beuno, spiv: Well, after just submitting all 3 patches to the wrong branch (and having them all merged), I'm re-submitting them to the correct branch, and going to bed. I'll work on 1.6rc3 tomorrow.
[04:31] <RAOF> Jucato: What would it do?
[04:31] <lifeless> jam: :P
[04:32] <lifeless> jam: what branch did they land on ?
[04:32] <markh> jam: ack - thanks!
[04:32] <jam> lifeless: bzr.dev
[04:32] <lifeless> jam: also, re - log
[04:32] <Jucato> before I used bzr launchpad-login <username>, this command worked: bzr checkout lp:~ubuntu-core-doc/ubuntu-doc/kubuntu-intrepid. after logging in, I get this error
[04:32] <Jucato> bzr: ERROR: Repository KnitPackRepository ('file:///home/jucato/kubuntu-intrepid/.bzr/repository') is not compatible with repostiory RemoteRepository(bzr+ssh://jucato@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/kubuntu-interpid/.bzr/)
[04:32] <lifeless> jam: do you have a minute before you go, I can work on it over your night
[04:32] <spiv> jam: hmm, bzr+ssh should be unaffected by my changes
[04:32] <spiv> jam: so I'm not sure why bzr-email would be slower...
[04:32] <spiv> jam: good night.
[04:32] <jam> lifeless: I've got a bit
[04:32] <lifeless> RAOF: I think it would remove your credentials
[04:32] <jam> just don't expect high quality discussions :)
[04:33] <lifeless> jam: so, AIUI we previously called 'file_vf.versions()' which did the _prefix iteration triggering a full read
[04:33] <jam> lifeless: something like that, yes
[04:34] <lifeless> I propose a patch to do the following:
[04:34] <Jucato> hm.. I just nuked ~/.bazaar and it works now again.. but the reason I logged in was because I got the note "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
[04:34] <lifeless> two things
[04:34] <jam> spiv: I don't know that you specifically effected it, or if it just that 'bzr log bzr+ssh' is really poor
[04:34] <lifeless> if the regions-unparsed ever reaches zero, convert the in memory structure to a full-buffered one.
[04:35] <lifeless> actually no, rephrasing
[04:35] <RAOF> Jucato: That error looks like you've got an already-existing directory?  Does it work trying to checkout to a new directory?
[04:36] <lifeless> there is an open bug spiv was looking at on kubuntu-docs
[04:36] <Jucato> RAOF: nope. I even rm -rf'ed the contents of that directory
[04:36] <lifeless> I think its something what vis-a-vis repo format preservation
[04:37] <Jucato> RAOF: I got it working for now by nuking ~/.bazaar. I'll wrestle with the problem again when I need to push something :/
[04:38] <lifeless> jam: actually, scratch that - you go to bed, I'll get some stats together
[04:38] <jam> lifeless: I think there are 2 performance bugs
[04:38] <lifeless> jam: any particular size repo you were testing on?
[04:38] <jam> 1 is that we don't trigger buffering
[04:38] <jam> lifeless: http://people.ubuntu.com/~jameinel/mysql-unpacked.tar.bz2
[04:39] <lifeless> thats going to hurt me isn't it
[04:39] <jam> lifeless:  a mysql repository, with an "optimally unpacked" layout
[04:39] <jam> its 652 MB
[04:39] <lifeless> only got 700M free on disk
[04:39] <jam> lifeless: It shows up with bzr.dev
[04:39] <lifeless> I can't even download an untar it ;)
[04:39] <jam> lifeless: so there is the "if we hit all of history, buffering is faster" bug
[04:40] <jam> lifeless: and there is the "requesting all (file_id, revision_id) tuples" from a knitpack repo issue.
[04:40] <jam> I don't know which is the bigger issue
[04:40] <lifeless> whats the second one?
[04:40] <jam> lifeless: misses in the knitgraphindex
[04:40] <jam> it has to bisect search for every non-existing key, into every pack file
[04:40] <lifeless> right
[04:40] <jam> so 20 pack files, require 2 bisect searches * N missing keys
[04:41] <jam> 'require 20 * N'
[04:41] <lifeless> its the same problem
[04:41] <lifeless> ok
[04:41] <lifeless> go sleep, I'll see if I can generate a hack for 1.6/.dev
[04:41] <jam> I suppose a dict lookup miss is significantly faster
[04:41] <jam> lifeless: just don't over-engineer it for a regression quickfix :)
[04:42] <lifeless> jam: we need to fix it
[04:42] <lifeless> I jave 4 and a bit hour until I raid, so there is time
[04:43] <beuno> mwhudson, pushed the changes with compare_revid.  I'm heading to bed now, and start tomorrow with the remaining bug + NEWS updates
[04:43] <mwhudson> beuno: excellent
[04:43] <beuno> (what I did feels a bit hackish though)
[04:44] <jam> lifeless: I just feel that if we could get a peak into the per-file graph, we could do it a lot cheaper by walking the ancestry
[04:44] <jam> without having to buffer_all.
[04:44] <lifeless> jam: but we do that
[04:44] <jam> lifeless: by grabbing every possible key, which is bad for KnitGraph.
[04:45] <lifeless> we do modified_text_versions = branch.repository.texts.get_parent_map(text_keys)
[04:45] <lifeless> jam: the thing is, we've already walked the graph once to do the revision sorting
[04:45] <jam> graph.iter_ancestry([known_tip])
[04:45] <jam> lifeless: different graph
[04:45] <lifeless> jam: I know
[04:46] <lifeless> jam: its much better on IO to do what we do today, simply sorting by size to have the largest index first would probably reduce most of the pain
[04:46] <jam> certainly loading all .tix indices is bad when you want just a single file_id
[04:46] <jam> I don't know that _iter_prefix is smart enough about how it does it, though.
[04:46] <lifeless> jam: its better on IO compared to just walking, because just walking is steps latency
[04:46] <lifeless> _prefix is dumb but fixable
[04:47] <lifeless> but we're not using _preix now
[04:47] <jam> _prefix is dumb, but fixable, and 3x faster than get_all() :)
[04:47] <lifeless> is NEWS, or builtins.py better you think ?
[04:47] <lifeless> jam: uhm, prefix is basically get_all
[04:47] <jam> lifeless: actually, you want something that changes relatively little versus the whole tree
[04:48] <lifeless> rules.py? :P
[04:48] <jam> lifeless: but done *in order* (I meant to say get_parent_map(all))
[04:48] <lifeless> _prefix is better because it reads the whole .tix
[04:49] <JonCruz> hi
[04:49] <jam> lifeless: _prefix is better because it does 1 linear read into a dict cache, serves results from there (though we may not actually hit the per-file graph much after that point)
[04:50] <jam> rather than bisecting an in-memory structure 10,000 *20 times
[04:50] <JonCruz> Perforce revision graph... http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html
[04:50] <lifeless> jam: yes, and it does those details because it reads the whole tix
[04:50] <jam> I think we both have a feel
[04:50] <jam> I'll welcome a patch
[04:50] <lifeless> jam: I'm talking big picture, you're talking fine detail
[04:50] <lifeless> I'll see if I can get something sensible for you to consider
[04:53] <jam> JonCruz: you might take a look at the "qbzr" plugin and "bzr qlog". It allows you to collapse and expand branches, which works a lot better when you have the 100s of branches that we have with bzr
[04:53] <jam> (i'm personally responsible for >200 feature branches of bzr)
[04:53] <JonCruz> the functionality is one of the nicer parts.
[04:53] <JonCruz> jam: it's a little hard to explain without actually using it
[04:54] <jam> JonCruz: I didn't mean to start much of a conversation, I'm really tired and heading to bed
[04:54] <jam> I just thought I'd point you to something.
[04:54] <JonCruz> I'd checked them out a while back
[04:54] <lifeless> jam:
[04:55] <james_w> hey JonCruz
[04:55] <jam> lifeless: ?
[04:55] <lifeless> http://rafb.net/p/gbv3vY51.html
[04:55] <jam> JonCruz: it does look interesting, but I don't see it scaling above 4 or so branches
[04:55] <jam> certainly, above 3 the lines start having to cross somewhere
[04:55] <JonCruz> Oh, it scales easily to dozens of branches
[04:56] <JonCruz> I've used it with some large enterprises
[04:56] <lifeless> 22 seconds with that patch
[04:56] <james_w> I asked JonCruz to step in, as he was saying that this perforce viewer is great, and so I wanted to find out why so that the bzr gui tools could improve
[04:56] <lifeless> testing without
[04:56]  * beuno is off to bed.  night everybody!
[04:56] <JonCruz> one aspect is that navigator window in the corner. Allows for zooming in and out
[04:56] <lifeless> 34 without
[04:56] <lifeless> so its possibly sufficient
[04:57] <jam> lifeless: looks interesting, unfortunately rafb.net doesn't let me copy and paste easily, I'll test on my mysql repo
[04:57] <JonCruz> the shapes also show merge, copy, branch start, branch end, etc.
[04:58] <JonCruz> pick-any-two-and-diff is also handy
[04:58] <james_w> the navigator is interesting
[04:58] <james_w> ah, it's not file based as I thought, it's just perforce being different
[04:58] <spiv> jam: firefox/epiphany copy & pastes from that rafb.net page just fine for me...
[04:59] <JonCruz> it
[04:59] <JonCruz> it's a bit file oriented... but it would be nice to track code blobs in a similar fasion.
[04:59] <JonCruz> that tool helps significantly when tracking down bugs in software that's been around for a bit
[04:59] <james_w> it's more of a canvas this I think, which would be a bit of work, but if the benefits are there and rely on that then it may be necessary
[05:00] <JonCruz> also it focuses things for those with a spacial way of thinking, as opposed to the list-based approach of http://qbzr.googlegroups.com/web/qlog.png
[05:00] <JonCruz> list-based is also good
[05:01] <james_w> diff between any two is something that I know is missing in bzr-gtk, and there is an open bug I think
[05:01] <jam> spiv: I seem to get a consistent "malformed patch" with my cut-and-paste attempts
[05:01] <JonCruz> so in that p4v view the revision numbers are across the top. In the QBzr one they are down the left
[05:02] <spiv> jam: huh, weird.
[05:02] <abentley> lifeless: pong
[05:02] <lifeless> hey
[05:02] <lifeless> I mailed the list
[05:02] <lifeless> jam: was it faster?
[05:02] <jam> lifeless: still copying the repo to this disk
[05:02] <lifeless> oh heh
[05:03] <JonCruz> their "blame" tool is also nice live  http://www.perforce.com/perforce/products/tours/p4v/p4v_time_lapse_view_7.html
[05:03] <jam> lifeless: and, of course, getting distracted trying to actually 'patch' rather than do it manually.
[05:03] <lifeless> rafb used to allow text access
[05:03] <lifeless> I wonder why they don't anymore
[05:03] <james_w> jelmer: http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html <- you can ask me to explain tomorrow if you don't have the scrollback
[05:04] <mwhudson> hm, somewhere to steal loggerhead ideas from!
[05:05] <JonCruz> Oooh. their main page has some videos  http://www.perforce.com/perforce/products/p4v.html
[05:05] <JonCruz> I guess I should check if those are helpful
[05:07] <jam> lifeless: "time bzr log" goes from 40s => 28s, versus 28.8 for bzr.1.3
[05:07] <lifeless> jam: so its a win ?
[05:08] <jam> lifeless: "time bzr log file" seems to be around 43s, which would be a definite win over the 2m+ from before
[05:08] <jam> I'll finish testing, but yeah, it looks like a big win
[05:08] <lifeless> ok
[05:08] <lifeless> it may not be sufficient
[05:08] <jam> so, for bzr1.3 it was 35s for 'bzr log file' versus 43s.
[05:08] <lifeless> but as its implementing a TODO from the original design :)
[05:08] <jam> So you aren't *quite* there
[05:09] <lifeless> ok
[05:09] <lifeless> mysql is a very big tree
[05:09] <jam> but I'm willing to take 43s versus 2min +
[05:09] <lifeless> its likely that if you print
[05:09] <jam> and accept a small regression
[05:09] <lifeless> len(key), self.key_count()
[05:09] <lifeless> you'll see a ration below 20
[05:09] <lifeless> *ratio*
[05:11] <jam> lifeless: sure, and the code you wrote doesn't take into account how much you've already read, right?
[05:11] <JonCruz> james_w: yes. It appears that their screencast video on the revision graph is helpful  http://filehost.perforce.com/downloads/media/rg/rg.html
[05:11] <lifeless> jam: right
[05:11] <jam> lifeless: but it is 2 min 27s without your patch
[05:11] <lifeless> jam: I aimed for quick
[05:11] <jam> for 'bzr log file'
[05:11] <james_w> JonCruz: cool, thanks, I'll take a look tomorrow
[05:11] <mwhudson> heh heh, diff -r <revno of the last loggerhead release> is bigger than diff -r 1 for loggerhead currently :)
[05:11] <jam> lifeless: So I think it passes my thresholds
[05:11] <lifeless> does it help annotate?
[05:13] <james_w> JonCruz: thanks for the pointers, I've got to sleep now, I'll swing by if I have any more questions
[05:16] <jam> lifeless: so for the *big* packs, I see 59632 35579 0.60
[05:16] <jam> aka, the 60,000 revisions are always >1/20th of the size of a text index
[05:16] <lifeless> that will do _buffer_all :P
[05:16] <jam> even optimally packed
[05:17] <lifeless> I'm not sure why its staying slower then
[05:17] <markh> hrm - its seems that pycurl will wait up to 15 minutes before deciding a read had died and retrying it?
[05:17] <jam> lifeless: there are other queries that aren't triggering it, but I'm not going to dig into it all. I'll check annotate.
[05:17] <markh> s/up to//
[05:18] <lifeless> markh: that smells like tcp
[05:18] <markh> 2 errors pulling from bzr.dev so far == 30 mins
[05:18] <jam> lifeless: well, first hand says "within the noise"
[05:19] <jam> 7.8 for bzr 1.3, 7.9 with your patch, 8.3 for bzr.dev
[05:19] <jam> so likely it helps
[05:19] <jam> but the margins are pretty small
[05:19] <jam> lifeless: ATM, I would give BB:approve, but I think I should sleep first :)
[05:20]  * jam => to bed
[05:20] <lifeless> jam: gnight
[05:27] <lifeless> abentley: I think bb is talking to itself
[05:27] <lifeless> abentley: :P
[05:28] <abentley> lifeless: joy.
[05:37] <lifeless> abentley: what do you think about the diff 'added but missing' issue?
[05:38] <abentley> lifeless: Dunno.  i've been fixing BB.
[05:38] <lifeless> ah
[05:38] <lifeless> can I run it past you ?
[05:40] <abentley> Sure
[05:40] <abentley> This the iter_changes bug?
[05:41] <lifeless> yeah
[05:41] <lifeless> fixing dirstate to do what inventory based ones does made a diff test break
[05:41] <lifeless> the diff test did
[05:41] <lifeless> add('foo')
[05:41] <lifeless> rm('foo')
[05:41] <lifeless> diff -> wanted no outout, status 0
[05:42] <lifeless> now it shows garbage -
[05:43] <lifeless> kind change, mode change
[05:43] <lifeless> which is strictly correct but not very useful
[05:44] <lifeless> I think 'added' with no content would be a better display for diff
[05:45] <abentley> lifeless: So the iter_changes behavior sounds correct.  The diff behavior sounds whack.  We've usually treated missing files as though they had been removed.
[05:46] <abentley> So I would expect diff to produce no output.
[05:46] <lifeless> ah
[05:47] <abentley> "added with no content" might be more sensible if you land a patch requiring files to be manually removed.
[05:47] <abentley> But diff has never tried to be as informative about file status as "status".
[05:47] <lifeless> well, such a patch seems to be contentious :)
[05:48] <lifeless> sure, I can make it do nothing
[05:48] <abentley> Cool.
[05:48] <lifeless> I know diff != status
[05:48] <lifeless> but deliberately hiding seems a little strange to me
[05:49] <lifeless> I'll get on hiding it though
[05:50] <abentley> What would you expect the behavior to be for "removed-but-not-deleted" files?
[05:50] <abentley> IIRC it's the same as "removed-and-deleted".
[05:51] <lifeless> well diff shows a full content removal
[05:51] <lifeless> and assumes no content change
[06:07] <lifeless> abentley:
[06:07] <lifeless> [06:07] <lifeless> --- bzrlib/diff.py      2008-06-11 03:56:46 +0000
[06:07] <lifeless> +++ bzrlib/diff.py      2008-08-14 05:07:18 +0000
[06:07] <lifeless> @@ -874,7 +874,9 @@
[06:07] <lifeless>                  return path.encode(self.path_encoding, "replace")
[06:07] <lifeless>          for (file_id, paths, changed_content, versioned, parent, name, kind,
[06:07] <lifeless>               executable) in sorted(iterator, key=changes_key):
[06:07] <lifeless> -            if parent == (None, None):
[06:07] <lifeless> +            # The root does not get diffed, and items with no known kind (that
[06:07] <lifeless> +            # is, missing) in both trees are skipped as well.
[06:07] <lifeless> +            if parent == (None, None) or kind == (None, None):
[06:07] <lifeless> seem reasonable ?
[06:08] <abentley> lifeless: Yes, that seems fine.
[06:09] <abentley> lifeless: is \> a special string in regexes?
[06:09] <lifeless> in some engines yes
[06:10] <lifeless> \<foo\> is 'match the word foo
[06:10] <abentley> I'm trying to decode what '\[MERGE\>' would match using python's engine.
[06:11] <abentley> I would expect it to match only "[MERGE>"
[06:12] <lifeless> hmm
[06:12] <lifeless> try \\> ?
[06:12] <lifeless> no, thats wrong
[06:12] <lifeless> but I mean, perhaps the \ is being caught by python
[06:12] <lifeless> r'\[MERGE\>' vs u'...'
[06:15] <abentley> Okay.
[06:15] <lifeless> abentley: do I have bb:approve from you for that little patch?
[06:15] <lifeless> if so, I can land the iter_changes fix
[06:15] <abentley> lifeless: Could you pastebin it so I can see it in context?
[06:16] <lifeless> that was the entire thing
[06:16] <abentley> lifeless: I figured, but I wanted to see where it fit in the existing file.
[06:16] <lifeless> I mean, its independent of the iter_changes fix, because its already broken for WT3 trees
[06:17] <lifeless> but I can pastebin the whole branch if thats what you mean
[06:18] <abentley> I meant just pastebinning the patch, so that it's in a form I can appy.
[06:19] <lifeless> http://pastebin.com/pastebin.php?dl=d62ba1f07
[06:22] <mwhudson> jeepers
[06:22] <mwhudson> etag support for loggerhead in about 10 minutes
[06:23] <lifeless> nice
[06:24] <mwhudson> ah, not quite
[06:25] <lifeless> not really an either-or thing is it ?
[06:26] <mwhudson> well
[06:26] <mwhudson> i guess supporting etags isn't
[06:26] <mwhudson> but it's not much use unless i generate some too :)
[06:26] <abentley> lifeless: bb:approve
[06:27] <mwhudson> and the changelog view's isn't quite brain-dead simple
[06:27] <mwhudson> and actually, i only did the templated stuff so far
[06:27] <lifeless> abentley: thanks!
[06:33] <jml> lifeless: so, Hornsby's out. Let's go to Kensington (or alternatively go Internetless at mine, pending confirmation with flatmate.)
[06:34] <lifeless> ok
[06:38] <mwhudson> lifeless: can you point me to something that explains what a 'weak etag' is?
[06:40] <mwhudson> i guess i should generate weak etags, as my tags won't change on template upgrades
[06:44] <lifeless> a datestamp is a weak etag
[06:44] <lifeless> a hash is a strong one
[06:47] <mwhudson> lifeless: ta, i found an rfc which made some kind of sense
[06:48] <mwhudson> lifeless: should i support if-modified-since and so on, or would you say etags suffice?
[06:48] <lifeless> why are you doing this?
[06:48] <lifeless> 13.3.3 rfc 2616 btw
[06:48] <mwhudson> so we can usefully put squid in front of it
[06:48] <lifeless> oh right
[06:49] <lifeless> IMS yes, definitely
[06:50] <lifeless> squid will probably be sending IMS
[06:50] <lifeless> rather than IAM
[06:50] <lifeless> sorry, IM
[06:51] <jml> lifeless: is there a reason why TestCase.make_branch and friends don't accept URLs?
[06:51] <lifeless> jml: yes
[06:51] <jml> lifeless: what is it?
[06:52] <jml> (because it's making my life hard)
[06:52] <lifeless> because we want one test to run on different transports
[06:52] <lifeless> what do you need to do that you are having trouble doing ?
[06:52] <jml> lifeless: I want to make a branch at a specific URL.
[06:53] <jml> lifeless: I can do this, but it would be more convenient if I could use make_branch.
[06:53] <lifeless> jml: obviously; I was being a bit more general
[06:53] <jml> lifeless: oh, ok.
[06:53] <jml> lifeless: so, I want to make a branch in a test in a place that Launchpad will find it.
[06:54] <mwhudson> lifeless: right, that's what i was reading, good to have it confirmed though
[06:55] <mwhudson> nice timing, freenode
[06:55] <lifeless> jml: go on
[06:56] <jml> lifeless: I am writing an acceptance test to show that Launchpad stacks branches that it mirrors.
[06:57] <lifeless> jml: I can tell you what I would do
[06:57] <lifeless> (other than making lp less picky for testing) :)
[06:57] <jml> go ahead
[06:57] <lifeless> I would set self.transport_readonly_server to HttpServer
[06:58] <lifeless> (as ChrootedTestCase does)
[06:58] <lifeless> but uncondiitonally
[06:58] <lifeless> then
[06:58] <lifeless> self.make_branch('foo')
[06:58] <lifeless> and the url to give lp is
[06:58] <lifeless> self.get_readonly_url('foo')
[06:58] <lifeless> it will be an http url
[06:59] <jml> that's not the branch I'm worried about creating.
[06:59] <lifeless> ok
[06:59] <jml> the branch I want to create is the stacked-on branch.
[06:59] <lifeless> this is an acceptance test right?
[06:59] <jml> yes.
[07:00] <lifeless> so why isn't make_branch(foo), make_branch(bar), lp.mirror(foo), lp.mirror(bar) reasonable?
[07:02] <jml> there are reasons.
[07:03] <lifeless> ok
[07:27] <lifeless> ohohoh I just had a thought
[07:27] <spiv> lifeless: those can be dangerous
[07:27] <lifeless> if we used another char
[07:27] <lifeless> or perhaps two columns
[07:27] <lifeless> we can sensibly do diff after a merge
[07:28] <lifeless> say two chars
[07:28] <lifeless> -1foo
[07:28] <lifeless> -2bar
[07:28] <lifeless> + gam
[07:28] <lifeless> (parent 1 had foo, parent 2 had bar, we have gam)
[07:29] <lifeless> alternatively
[07:29] <lifeless> - foo
[07:29] <lifeless> +Mbar
[07:29] <lifeless> + gam
[07:29] <lifeless> basis has foo
[07:29] <lifeless> the merge had bar
[07:29] <lifeless> we have gam
[07:30] <lifeless> I think the former is more useful, because unchanged local lines from the merge can just not be shown
[07:31] <spiv> Sounds interesting.
[07:31] <spiv> So, a slightly richer diff format, essentially?
[07:31] <spiv> That can represent more than just texts from {old,new}
[07:44] <lifeless> spiv: yeah
[07:45] <lifeless> I often want to know 'did I resolve this well'
[07:45] <lifeless> and I think this would let me figure that out
[07:46] <spiv> I often want to know that too.
[07:46] <lifeless> did my rm patch get reviewed?
[07:47] <spiv> I did review it.
[07:48]  * spiv checks the email escaped the laptop
[07:48] <lifeless> ah
[07:48] <spiv> jam and I both voted tweak.
[07:48] <spiv> (for different issues :)
[07:49] <luks> hm, what about using the diff's merge format?
[07:49] <luks> er
[07:49] <luks> I mean git's merge format
[07:49] <spiv> (And yes, my mail escaped)
[07:50] <lifeless> spiv: 'deletes' is wrong
[07:55] <spiv> lifeless: huh?
[07:56] <lifeless> your tweak, my mental grammar filter is objecting to using deletes
[07:56] <spiv> lifeless: I just checked, jml's mental grammar matches mine
[07:57] <lifeless> I think you're both wrong.
[07:58] <lifeless> now I need to go looking for singular verbs with plural subjects
[07:58] <spiv> lifeless: Shall I ask my linguist? :)
[07:58] <lifeless> sure, though I'm looking for rationale not assertion
[07:58] <lifeless> and she may not have time/interest to dig up a explanation
[07:59] <spiv> I'll find out if she does.
[08:00] <lifeless> bzr is singular
[08:01] <lifeless> delete is the verb
[08:01] <lifeless> bzr is doing the deletion
[08:01] <jml> lifeless: it's just a bad sentence.
[08:01] <spiv> (that's the official diagnosis ;)
[08:01] <lifeless> so bzr is the subject, and thus subject-verb agreement ->
[08:01] <lifeless> jml: so lets reword id
[08:02] <jml> sure.
[08:02] <jml> "Break any of these rules sooner than say anything outright barbarous." etc
[08:03] <lifeless> it will have to wait, I have things to do before 6
[08:03] <spiv>     This makes bzr stop tracking changes to the specified files.  It will also
[08:03] <spiv>     delete them if they can easily be recovered using revert.
[08:04] <spiv> (That's my quick attempt at improving it)
[08:04] <lifeless> anyhow, suject-verb agreement is why 'bzr delete' is correct, IMO
[08:05] <spiv> Yeah, I eventually managed to parse it the way necessary to see that.  My very strong intuition was otherwise.
[08:05] <spiv> Do you like my rewrite?
[08:05] <lifeless> so, 'bzr will also delete them ..' would work better in your restated sentence; using 'it' means more backtracking
[08:05] <lifeless> other than that its fine.
[08:05] <spiv> Sure.
[08:05] <spiv> +1 on that.
[08:06] <lifeless> thanks
[08:13] <lifeless> bbiab
[08:16] <compubomb> question, does bzr have issues with version control involving binary versions ?
[08:17] <compubomb> as opposed to say text.
[08:17] <spiv> Nope.
[08:17] <compubomb> spiv: so it just stores the entire file of the binary right ?
[08:17] <compubomb> i believe with txt files version control apps generally use diff / patches right ?
[08:17] <spiv> "bzr diff" will decline to show you anything useful, but it'll store the versions just fine.
[08:18] <spiv> bzr's internal storage format isn't patch files.
[08:18] <spiv> That said, it is currently optimised for text files with newlines bytes.
[08:19] <compubomb> spiv: but you can use it with binaries though right ? i'd imagine it does some kind of hash to determine modification.
[08:19] <spiv> So it won't (currently) store them very efficiently.  Depending on the way the file changes it could easily just store the whole file for each new version.
[08:20] <compubomb> spiv: okay, that was what i was wondering on.
[08:21] <Peng_> Nonetheless, it's not like it's broken, it's just somewhat inefficient.
[08:26] <gour> i'd like to use bzr-svn to fetch some svn repos. what is the current situation if one wants to use it with svn-1.4.6?
[08:26] <gour> (without patching svn)
[08:29] <spiv> I believe the current bzr-svn trunk (and most recent beta release?) doesn't need any patching of svn
[08:29] <spiv> Check the README I guess.
[08:39] <gour> release is supposed to happen soon?
[08:40] <Peng_> gour: Yeah, pretty soon. See the mailing lsit.
[08:40] <Peng_> (I think)
[08:42] <gour> god
[08:42] <gour> *good
[10:45] <ubuntu_> hi, why should I choose bazaar over git?
[10:46] <gour> ubuntu_: simpler UI and safer
[10:46] <gour> ubuntu_: that's why i migrated from darcs to bzr instead to git. ymmv
[10:46] <ubuntu_> what do you mean by simpler UI and safer?
[10:46] <gimaker> ubuntu_, and it works with Launchapd (if you do open source stuff) :)
[10:47] <gour> ubuntu_: just count how many commands are there in git, read about its model and see how can you shoot yourself in the foot ;)
[10:48] <gimaker> ubuntu_, why not try both out and choose the one which you're more comfortable with? I tested mercurial and bzr, and bzr just felt a lot more smooth to work with.
[10:48] <ubuntu_> i use git at the moment. it's fast and actually it's quite easy to use.
[10:48] <ubuntu_> i heard of bzr not being as fast as git.
[10:48] <gour> true. but i do not work on linux kernel :-)
[10:48] <gimaker> ubuntu_, it's not. how big is your source tree?
[10:48] <gimaker> and how many revisions does it have?
[10:49] <ubuntu_> well my source tree is like one rails project, so it wouldn't matter i guess.
[10:49] <gour> ubuntu_: with darcs i started using it after 5mins. bzr is similar - check http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[10:50] <gimaker> ubuntu_, It's pretty snappy with a ~1000 file 1200 revisions repository, so you should be okay too.
[10:50] <gour> ubuntu_: nice and orthogonal command set supporting many different workflows...(d)vcs should be a tool i do not have to think to much, but just use it
[10:51] <ubuntu_> but another thing is, that just what i read and heard is that git is used by far more projects than bzr...
[10:51] <gimaker> I thought all the concepts was a bit confusing at first - shared repos, checkouts, lightweight.. ahh!
[10:51] <gour> ubuntu_: that's also true. m$ windoze is used by far more users than linux, but i don't care :-)
[10:52] <ubuntu_> i love my mac.
[10:52] <ubuntu_> ;)
[10:53] <gour> :-)
[10:54] <ubuntu_> another thing: is it possible in bazaar to "change" the history? overwrite a commit, change the commit message etc.
[10:54] <gimaker> ubuntu_: one selling point for bzr is its plugin system - rumor has it git doesn't support plugins?
[10:55] <gimaker> ubuntu_: it's possible... afaik, it's not super-simple in the general case
[10:56] <ubuntu_> ok. thanks to all! i'll give bzr a try.
[10:57] <gimaker> ubuntu_: in the common case ("doh, i forgot to add file X" or "man, that commit message was really retarded") it's very simple: just "bzr uncommit", fix what went wrong and re-commit
[10:58] <ubuntu_> yeah that's the simple case. but if it's "doh, that commit message is retarded" on commit 16 and we're at 24?
[10:59] <luks> then you will have to rewrite the history, which will screw everybody who branched from you
[10:59] <gimaker> ubuntu_: it's doable, but a bit more involved.
[10:59] <luks> revision history in bzr is immutable
[10:59] <ubuntu_> is it documented on bazaar-vcs.org ?
[10:59] <luks> if you need to do a change like this, you need to make a new history
[11:00] <gimaker> ubuntu_: not that I know.
[11:00] <gimaker> ubuntu_: one (painful) way to do it is to "bzr uncommit" repeatedly
[11:00] <gimaker> ubuntu_: another way is to use the rebase plugin
[11:02] <gimaker> it should be pretty simple, something along these lines ;) bzr branch -r 16 some_branch fix_msg; bzr uncommit; bzr ci -m "New and improved commit message"; cd some_branch; bzr rebase -r17.. ../fix_msg
[11:03] <gimaker> but since you're a git-guy I guess you all about rebasing already?
[11:03] <luks> rebase wouldn't help you in this case
[11:04] <luks> the replay command from the rebase plugin would
[11:05] <gimaker> right, where replay command = bzr rebase :p
[11:05] <gimaker> hmm.. this is interesting. what's the difference between replay and rebase?
[11:06] <luks> maybe I misunderstand what bzr rebase -r does, but I really hope it does not drop revisions
[11:07] <luks> replay is mass cherrypicking
[11:07] <luks> rebase replays your local commits on top of a specified branch
[11:08] <gimaker> luks, it doesn't. AFAIK, rebase does the same thing.
[11:08] <luks> the same thing as what?
[11:08] <gimaker> as replay
[11:09] <luks> no
[11:09] <gimaker> so what's the difference?
[11:09] <luks> didn't I just say it?
[11:09] <luks> but as I said, I'm not sure what `bzr rebase -r` does
[11:10] <gimaker> luks: Maybe, but I'm not exactly sure what "mass cherrypicking" means..
[11:10] <luks> bzr merge -c X OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X
[11:10] <gimaker> replay seems  to be undocumented (bzrtools 1.3 something) so it's kind of hard to tell if the difference :)
[11:10] <luks> bzr merge -c X+1 OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X+1
[11:10] <luks> etc.
[11:11] <luks> ehm, and what does bzrtools have to do with this? :)
[11:11] <gimaker> eh, sorry.. rebase 0.3 :)
[11:11] <luks> rebase, by definition, should change the base of your local commits
[11:12] <luks> that means it would not drop the revision with incorrect message
[11:14] <gimaker> I *think* I see the difference now. It seems it's just a matter of syntax/workflow."
[11:15] <gimaker> replaying revisions A..B from branchA onto branchB <=> rebasing branchB on branchA
[11:15] <luks> well, you are wrong, but I'm not going to argue :)
[11:15] <luks> that is true in some specific case, not in general
[11:16] <gimaker> luks: ok, I'll take your word for it - I'm a rebase noob.
[11:18] <gimaker> maybe, in the future, there will be documentation to enlighten me on the difference ;)
[11:21] <luks> gimaker: http://rafb.net/p/ZfTkuu17.html
[11:21] <luks> is this more clear?
[11:22] <luks> or http://rafb.net/p/jE4zBV41.html to be more precise
[11:23] <luks> as the new revision just look like the originals, they are not identical
[11:25] <gimaker> wouldnt "(in branch B) bzr replay -r 3..4 A" be the same as "(in branch B) bzr rebase -r3.. branchA" ?
[11:25] <gimaker>  
[11:26] <gimaker> sorry, I meant (in branchA) bzr rebase -r3.. branchB
[11:27] <gimaker> that should also yield A->B->E->F->C'->D' ?
[11:28] <ubuntu_> definitely too much rebasing here ;)
[11:28] <gimaker> agreed ;)
[11:30] <luks> I don't know what -r in rebase does
[11:33] <gimaker> luks: rebase -rA..B OTHER will replay A..B from the current branch on OTHER.
[11:33] <luks> gimaker: just tried it, /tmp/branchB$ bzr rebase -r3.. ../branchA/ still results in A - B - C - D - E' - F'
[11:33] <luks> so, no, it doesn't :)
[11:33] <luks> and it will definitely not apply it on OTHER
[11:35] <luks> hm, I honestly don't understnad `rebase -r`
[11:36] <luks> bzr rebase -r4.. ../branchA is A -> B -> C -> D -> D' -> E' -> F'
[11:36] <luks> but E was never a parent of D, so I don't know what's going on
[11:37] <luks> er, I mean D parent of E
[11:39] <luks> oh, sorry, ignore me, I did something wrong
[11:39] <luks> bzr rebase -r4.. ../branchA will drop the revision E, and the result will be A -> B -> C -> D -> F'
[11:40] <luks> I'm surprised it drops the revision so easily though
[11:40] <gimaker> luks: yes, but rebase -r3.. should give you A->B->C->D->E'->F', no?
[11:40] <luks> gimaker: yes, as I said above
[11:41] <gimaker> luks: but after playing a bit with it i can see that you're right...
[11:41] <luks> so -r in rebase basically means that you can manually specify the 'common anccessor'
[11:41] <luks> which can be destructive
[11:41] <luks> (really destructive, not just rewriting history)
[11:42] <gimaker> you can also use the --onto argument to specify where A..B should be rebased
[11:44] <gimaker> luks: thanks for clarifying the replay command! it might provide quite useful indeed
[11:45] <luks> gimaker: well, in the end it looks like you can get the same result using rebase, so technically you don't need it :)
[11:46] <luks> but for the original question I'd still prefer the (for me) more obvious way: bzr branch -r X A B; cd B; bzr uncommit; bzr commit; bzr replay -R X+1 ../A
[11:46] <luks> bzr replay -R X+1.. ../A
[11:46] <gimaker> luks: hehe yeah, that was my point all along :)
[11:46] <gimaker> but it's more involved, so I think I'll prefer the replay-way in the future :)
[11:46] <luks> yeah, I didn't realize rebase can drop revisions in the process
[11:57] <gimaker> maybe these things should be documented somewhere - how to change an old commit message, or how to collapse/remove the first X revisions of the history (which is something I recently did, and it wasn't very obvious)
[12:00] <luks> yeah, most bzr people don't agree with history modifications, but if users do it according to a document at they won't screw up so badly :)
[12:02] <gimaker> luks: after trying it, I can see why they don't agree with it :) But it's useful in some cases, e.g. if you're just making a personal project public and want to remove the first 100 commit messages which just says "lol butts" or similar nonsense.
[12:03]  * Kinnison recommends not being daft enough to commit with that kind of message :-)
[12:06] <gimaker> Kinnison: it's bound to happen. Put a VCS in the hands of couple of fresh students and there you go!
[12:07] <Kinnison> They'll learn
[12:07] <Kinnison> And having the mistake immortalised for all time will help them to learn that just because you were a numpty at one time, doesn't mean you can't improve
[12:08] <Kinnison> You can't change the fact that at one point you were idiotic enough to think that "lol butts" was a sensible commit message, so why encourage people to hide it like it's a dirty secret or something?
[12:10] <gimaker> Kinnison: Here's a better reason: http://wiki.freebsd.org/VCSFeatureObliterate
[12:14] <Kinnison> gimaker: Legal encumberances are about the only reason I can see to change history. Also, in a DVCS, I firmly believe that once you have allowed a revision to reach the wild, attempting to disavow its existence is counterproductive.
[12:16] <LeoNerd> Even Arch/TLA had a long discussion on the website about why changing history is bad
[12:16] <gimaker> Kinnison: Not every DVCS is employed "in the wild", e.g. usage in closed-source shops. There was another case where an employee had put some improper comments about a (female) coworker in a commit message. It went to court ... and the company ended up wanting the commit message removed.
[12:17] <Kinnison> Hmmm
[12:17] <gimaker> I can agree that it's usually a bad idea, but as someone else put it "when you need it, you really need it".
[12:17] <Kinnison> I guess. I'm still against promoting the concept though.
[12:17] <luks> gimaker: if the coworker has a local branch, there is no way to remove it from there
[12:18] <gimaker> luks: That's not the point, the point is that the company "did their duty" (and I think it was a centralized VCS).
[12:19] <luks> gimaker: sure, but with DVCS it's not so easy to do such a change globally
[12:20] <luks> e.g. in case of FreeBSD, everybody in the world would had to redownload the whole history and destroy all old copies
[12:20] <luks> which seems almost impossible thing to do
[12:23] <gimaker> There's still a difference... I'm not a lawyer, but if you illegally provide some content you probably get a "take down notice", and not a demand to erase all copies of that file.
[12:24] <luks> hm, right
[12:27] <gimaker> it's also useful if you have sensitive business secrets somewhere in your repository (commit messages or not), and then want to distribute the repository to a third party
[12:28] <gimaker> e.g. "Added feature X. This will enable us to easily implement secret feature Y in product Z later on."
[12:29] <Kinnison> That's what non-disclosure and similar agreements are for
[12:30] <gimaker> Kinnison: That does help if you decide to open-source parts of your codebase
[12:31] <gimaker> GPL and NDAs don't mix and match :)
[12:49] <TemplePrime> i have a bazaar repo set up on my work computer, however after work i wanna export my work into a tar so I can take home and continue at home. Problem is, starting a new repo at home to host my files would erase my rev logs. Is there a way to transfer repos from one PC to another?
[12:50] <gimaker> TemplePrime: if you copy the .bzr directory as well you'll get the rev logs too
[12:50] <luks> the preferred way is to use a computer to which you can connect from both places, and use 'bzr push'
[12:51] <LarstiQ> TemplePrime: branch or repository? In the first case, `bzr push`.
[12:51] <luks> but if you don't have such a server, just making a tarball of the directory should be fine
[12:51] <TemplePrime> computers are not connected, so making a tarball then, but I have to have even the same user on both machines?
[12:52] <luks> no
[12:52] <TemplePrime> wow, bzr is flexible
[12:52] <LeoNerd> cp -r one of them (you only need the .bzr directory within it), shove it on e.g. a USB stick, then   bzr merge /path/to/usbstick
[12:52] <luks> do both run the same operating system?
[12:52] <TemplePrime> luks, yeah
[12:52] <luks> the only problem would be moving windows working tree to linux or vice versa
[12:52] <luks> then it's not a problem
[12:52] <TemplePrime> no, they both have linux
[12:53] <LeoNerd> So.. don't move the working tree :)
[12:53] <LeoNerd> And use the merge/push trick so you can deal with divergent history and whatnot...
[12:53] <luks> yeah, repository on a usb stick is a good idea
[12:53] <uws> Hey guys. I want to share a bzr branch with a colleague
[12:53] <uws> we're both in the same unix group
[12:53] <LarstiQ> uws: umask?
[12:53] <uws> can I somehow make sure all the files are  foo:ourgroup  ug+rwX,o+rX   when I push?
[12:53] <TemplePrime> LeoNerd, I tarball the whole repo and extract it in my home directory, that's it?
[12:54] <LeoNerd> TemplePrime: No need even there. cp -r it to the USB stick. Take it home. Do not move it off.. instead, run   bzr merge /path/to/the/USB/repo  from your home machine's workdir
[12:54] <LeoNerd> Let bzr pull the changes out from the USB stick, don't you manaully trash it
[12:55] <LeoNerd> (merge or pull or whatever is required)
[12:55] <LeoNerd> In fact.. when at work, don't cp -r, that's silly.. bzr push it :)
[12:55] <luks> usually pull, since he can't work on both places at the same time :)
[12:55] <uws> LarstiQ: How would that work with bzr+ssh or preferably sftp:// ?
[12:55] <LeoNerd> Depends.. sometimes I forget
[12:55] <TemplePrime> LeoNerd, on my home machine I dont have even bazaar installed, after I install it dont I need to whoami and init stuff?
[12:55] <LeoNerd> TemplePrime: Oh probably, yes...
[12:56] <luks> TemplePrime: you do need bzr whoami, but not bzr init
[12:56] <TemplePrime> the init and the whoami need to be the same right?
[12:56] <luks> init creates a new branch, but you already have one
[12:56] <luks> no, they don't
[12:56] <TemplePrime> true, so only whoami
[12:57] <luks> bzr push/pull from an usb stick is really the best option
[12:57] <TemplePrime> i'll tarball it an email it to myself, dont have usb ports on the server
[12:57] <luks> you can use `bzr send` too
[12:57] <luks> if you already have the branch on both computers
[12:57] <TemplePrime> luks, they are not connected to each other
[12:58] <luks> oh, right
[13:08] <ToyKeeper> Does bzr have a way to split a subdir into a new branch, retaining only that subdir's history?
[13:09] <ToyKeeper> I haven't found one...  the 'split' command seems to basically rename subdir => . and delete everything else, but doesn't change the history at all.
[13:10] <ToyKeeper> I'm basically looking for the opposite of the 'merge-into' command.
[14:33] <mheld> hey
[14:34] <mheld> does anybody know of any frontends for bzr like http://www.versionsapp.com/ ?
[14:35] <beuno> mheld, bzr-gtk?
[14:35] <mheld> for OS X?
[14:35] <mheld> without using fink/macports
[14:35] <james_w> there's bzrx or something
[14:35] <james_w> bazaarx maybe
[14:36] <james_w> http://elliotmurphy.com/2008/06/06/bazaarx/
[14:36] <james_w> hey beuno
[14:37]  * beuno waves at james_w
[14:39] <mheld> i like the concept of bazaarX, but I don't really see how I could install this on 20 computers easily/quickly
[15:01] <fbond> Is this a problem?  "Standalone tree (format: unnamed)"
[15:01] <fbond> This is a loom.
[15:07] <strk> /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py:57: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5. Branch.hooks.install_hook('post_commit', branch_commit_hook)
[15:07] <strk> just upgraded bzr to Bazaar (bzr) 1.6rc2
[15:08] <fbond> Oh, I guess all of my looms claim to have format "unnamed".
[15:09] <fbond> strk: I don't think you need to worry about deprecation warnings.
[15:09] <fbond> strk: They can safely be ignored, unless you are the author of the plugin using the deprecated API.
[15:33] <jam> strk: When we get to a full release, we suppress deprecation warnings
[15:33] <jam> it is just for developers and people running bleeding edge
[15:33] <jam> so that the authors know they need to fix stuff for the release
[15:33] <jam> strk: and 'bzr-email' has a fix if it releases a new version.
[15:34] <jam> (the code is done and in trunk, it just needs to be packaged.)
[15:34] <strk> thanks
[15:58] <strk> AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'
[15:58] <strk> bzr viz ...
[16:04] <awilkins> strk: Sounds like you need to update your bzr-gtk plugin to a more recent one
[16:06] <strk> I'm using the custom repository
[16:07] <strk> http://ppa.launchpad.net/bzr/ubuntu hardy main
[16:07] <strk> got prompted to upgrade bzr but not bzr-gtk
[16:11] <jvloothuis> I am trying to merge two unrelated branches with; bzr merge -r 0..-1 ../unrelated-branch      unfortunenately I get an error about Repository KnitPackRepository not being compatible with the other (both are knitpack's), any tips?
[16:14] <luks> are you sure one of them isn't rich-root-pack?
[16:16] <jvloothuis> luks: thanks for the tip, you are right
[17:08] <jam> beuno: ping, I'm submitting the 1.6rc3 to PQM now, it will be a bit and I'll have a 1.6rc3 tarball to package.
[17:09] <beuno> jam, cool. I'll try and get to that ASAP
[17:09] <jam> beuno: I'll make sure to ping you again when I've uploaded the tarball
[17:09] <luks> is this the last 1.6 RC?
[17:09] <jam> I just wanted to alert you that it was coming soon
[17:09] <jam> luks: With any luck
[17:09] <beuno> jam, thanks  :)
[17:09] <jam> I wanted to do it quickly to give an rc a bit of time before -final
[17:17] <jam> abentley: do you have a 1.6 release of bzrtools that we can get packaged?
[17:21] <abentley> jam: I released bzrtools 1.6 in June
[17:21] <jam> abentley: is it still compatible with 1.6rc?
[17:22] <jam> It at least seems that ~bzr/ppa only has the 1.5 packages
[17:23] <jam> and ~bzr-beta doesn't have any bzrtools
[17:23] <jam> beuno: any chance you would feel comfortable packaging bzrtools as well?
[17:23] <abentley> jam: yes.
[17:25] <beuno> jam, yeah, I did it last time too.  Just need time.  I'll upload it around 1.6 for sure
[17:26] <jam> beuno: k. I would put it in the beta-ppa for now to go along with the 1.6 releases. This will also let us easily copy it into the official repo when 1.6 is final
[17:26] <jam> If you could do bzr-gtk as well, it would be nice, but I'm not going to make you do *everything* :)
[17:26] <jam> Did Martin usually do bzr-gtk?
[17:26] <beuno> no, jelmer did
[17:27] <beuno> and, bzr-gtk may be trickier as it may have varied dependencies
[17:27] <beuno> I'd rather we try and trick jelmer into doing that one
[18:01] <bzr> hi, is it possible in bazaar to checkout to the working directory (like in git)?
[18:33] <jam> beuno: 1.6rc3 upleading now
[18:41] <beuno> jam, great, I have some stuff to finish, and then I'll get to that
[18:43] <jam> beuno: it is at http://edge.launchpad.net/bzr/1.6/1.6rc3/+download/bzr-1.6rc3.tar.gz for your downloading convenience
[18:44]  * beuno conveniently downloads it
[18:46] <compubomb> how do i tell bzr to ignore a group of folders involved a directory structure ?
[18:46] <compubomb> i have a bunch of source, but also a lot of images, the images are not important.
[18:47] <cody-somerville> bzr ignore
[18:48] <compubomb> cody-somerville: so > bzr ignore foldername1/ foldername2 /foldername3 filename4 etcnum
[18:50] <cody-somerville> compubomb, you can also use patterns
[18:50] <cody-somerville> "bzr help ignore" <-- great info about it
[18:52] <compubomb> cody-somerville: every time i accidentially do commit without giving it a message, it loads up a text editor on my system that i don't use(not important) but what is pissing me off is i don't know how to save the information that is in this box in order to execute the full commit.
[18:52] <compubomb> do i save a file or something ?
[18:52] <compubomb> i don't see a filename.
[18:53] <cody-somerville> Yes, save without modifying the filename
[18:53] <compubomb> yup, didn't work
[18:53] <compubomb> :/
[18:53] <cody-somerville> You can change the editor by changing the EDITOR environment value
[18:53] <compubomb> what is annoying me is it's using jed
[18:54] <compubomb> cody-somerville: i did env | grep "EDITOR" and it's not even in there.
[18:54] <compubomb> wtf would bzr use jed ?
[18:55] <cody-somerville> There are several commands in debian based distributions use the "alternatives" system so that scripts and what not can run them and it'll use the preferred alternative.
[18:56] <cody-somerville> This may be the case with bazaar. I'm not a bazaar developer so I don't know :P
[18:58] <jam> compubomb: we use VISUAL, EDITOR, and BZR_EDITOR
[18:58] <jam> Otherwise we fall back to "/usr/bin/editor" which is in the alternatives system
[18:58] <jam> then vi, pico, nano, joe
[18:58] <hsn_> how to check plugin version?
[18:58] <jam> I'm guessing your distribution has "jed" set as the default editor
[18:58] <jam> when you run "/usr/bin/editor"
[18:58] <jam> hsn_: If they export it, just do "bzr plugins"
[18:59] <jam> hsn_: Not all plugins give a version string, though
[18:59] <hsn_> thanks
[19:00] <hsn_> is there way to check if i have one plugin in path multiple times?
[19:00] <jam> hsn_: If the plugin is available via different names, it will probably give a conflict at import time
[19:00] <jam> if it is the same name
[19:00] <jam> we have specific precedence
[19:01] <jam> ~/.bazaar/plugins takes precedence over system-installed plugins
[19:01] <luks> btw, why is bzr loading plugins from /usr/lib/python2.5/site-packages/bzrlib/plugins if I don't use that bzrlib?
[19:01] <luks> it might have incompatible plugins, so it's probably not a good idea
[19:05] <compubomb> jam: ty, just removed the symlink to /etc/alternatives/editor and chnaged it to vim
[19:06] <compubomb> anyone happen to know where i could find a tutorial on setting up bzr with trac on ubuntu ?
[19:06] <compubomb> i installed the trac-bzr package but it just installed a folder on my system, didn't do any configuration to apache i believe.
[19:08] <jam> luks: IIRC, it is setup to search the "Arch independent plugin path" because some people install multiple architectures side-by-side. So you end up with bzrlib installed in /usr/lib-x86/python... and you need to import the python modules from /usr/lib/python...
[19:09] <jam> luks: otherwise, I agree that when running out of the source tree, it may be good/bad to import site packages.
[19:09] <luks> jam: yeah, I know it was introduced then, but it doesn't seem logical
[19:09] <luks> I have maybe 0.90 in /usr/lib/python and I use 1.6 from my homedir
[19:09] <luks> if I had a globally installed plugin for the 0.90 version, it would break my 1.6 local install
[19:09] <compubomb> what interfaces other than trac are good for bazaar interfacing ?
[19:10] <compubomb> bleh, i mean like bug/ticket systems etc.
[19:10] <hsn_> is there way to disable plugin for example by renaming its directory to something?
[19:11] <luks> jam: one thing, if I sent a patch to ignore plugins named __init__, is there a change of getting it approved? it currently fill .bzr.log because it tries to load bzrlib/plugins/__init__.py and bzrlib/plugins/__init__.pyc
[19:11] <luks> for me actually twice, from my homedir and from /usr/lib/python...
[19:11] <compubomb> is there like a launchpad for local systems ?
[19:13] <luks> compubomb: I don't think there is anything integrated
[19:13] <luks> trac is probably the best choice if you want all-in-one solution
[19:14] <jam> hsn_: I rename them into a subdir
[19:14] <jam> (happens to be called DEACTIVATED)
[19:15] <jam> luks: probably I'd review a patch
[19:15] <compubomb> luks: i installed trac-bzr but i don't know how to access it online, i'm not used to working with python apps. i found the directory in "/usr/share/trac"
[19:15] <jam> I don't feel like 4 lines in .bzr.log is "filling the log" but it is a bit ugly
[19:15] <compubomb> do i have to do setup.py install ?
[19:15] <compubomb> i'm not sure wtf i'm doing.
[19:15] <luks> jam: well, not really "filling the log", but for most commands it's the only output
[19:15] <compubomb> trac has these directories in it "cgi-bin/  conf/  htdocs/  plugins/  templates/  wiki-default/  wiki-macros/"
[19:16] <luks> every time I look at bzr.log I see four "Plugin name __init__ already loaded" entries for each command
[19:16] <luks> compubomb: sorry, I don't know
[19:20] <compubomb> luks: np, i asked in #trac, hopefully they will be kind enough to help me and not be like rftm.
[19:20] <compubomb> sometimes, you need floaties before you get your stride.
[19:20] <compubomb> rftm=rtfm
[19:21] <compubomb> rtfm is the equivalent of learning how to read and someone hands you a dictionary and says go at it tiger, and people expect you to be superman off the bat.
[19:22] <luks> I think trac has some nice tutorials on their wiki
[19:22] <luks> for all deployment methods
[19:29] <compubomb> luks: yea, they have it for svn
[19:39] <pickscrape> compubomb: http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/48?file_id=readme-20061211191445-unb1b1y5dhltbwy7-2
[19:40] <pickscrape> Once trac and the plugin are both installed, look at line 56 of that file and apply the required changes to trac.ini
[19:40] <pickscrape> That tells trac to use the plugin for version control instead of its built-in svn layer
[20:07] <rockstar> jam, TWiB in 15?
[20:12] <nixternal> does bzr have a function similar to svn:externals? and if so, can it do files or multiple files instead of complete directories?
[20:14] <jam> rockstar: I'm syncing right now, then i'll reboot and we're on
[20:14] <rockstar> jam, sounds great
[20:19] <nixternal> jam: you still in Chicago?
[20:19] <nixternal> never mind, I did a whois
[20:19] <nixternal> you going to barcamp this weekend?
[20:27] <jam> nixternal: I didn't even know it was happening, and yes i'm still in Chicago.
[20:30] <jam> rockstar: rebooting
[20:37] <jam> nixternal: to your earlier question, bzr doesn't really have a replacement for svn:externals yet, and the proposed one would be at a directory level
[20:37] <jam> not for individual files
[20:38] <nixternal> so that means I have more work in front of me here at work :)
[20:39] <jam> rockstar: ready? i'm starting up gobby now
[20:39] <rockstar> jam, I is ready
[20:41] <nixternal> jam: http://barcampchicago.com - Saturday and Sunday, all day and night, free food and beer, live music, good talks, and some hacking
[20:41] <nixternal> last year totally rocked and this year is looking good already
[20:41] <nixternal> it is over at UIC
[20:41] <jam> nixternal: sounds fun, hopefully I can make it around children's b-day parties
[20:42] <nixternal> heh, this is b-day party weekend in chicago...my neice's is saturday, but barcamp won there :)
[20:51] <beuno> thumper, ping
[21:13] <Toranin> wow, svn2bzr (dumpfile version) is slow on long histories.  Looks like it's going to run for about a week by the time it completes at this rate
[21:30] <beuno> lifeless, interesting thing just now. I tried to index the launchpad branch, and it brought my core2duo to it's knees. I control+c'd, and it kept on going until I killed the PID manually.  Is that expected?
[21:30] <phoenix3051> Is there a way to removed ignored file patterns from the ignore file on a per project basis. For example in the default configuration bzr will ignore *.a & *.o but for a certain project I don't what this to happen.
[21:30] <jam> TWiB is available: http://jam-bazaar.blogspot.com/
[21:31] <jam> phoenix3051: you can edit ~/.bazaar/ignore, but that will change all branches
[21:31] <jam> phoenix3051: you can always specifically add files
[21:31] <jam> by doing "bzr add filename.a"
[21:31] <jam> it is just that "bzr status" won't show them, or "bzr add" won't add them automatically.
[21:36] <phoenix3051> Jam: adding them by hand would be a nightmare as there are approx ~10k files.
[21:36] <jam> phoenix3051: "find . -name '*.a' -print0 | xargs -0 bzr add"
[21:36] <jam> takes a few seconds?
[21:38] <phoenix3051> oh never thought of that because I was running the test on a windows machine, of to get cygwin installed now :)
[21:43] <jam> phoenix3051: I think on windows you could still do "bzr add */*.a */*/*.a" etc
[21:43] <jam> I don't know if we support "**/*.a" on win32
[21:44] <jam> no we don't
[22:18] <awmcclain> Hrm... does 1.6 break tracbzr?
[22:20] <pickscrape> Not that I've experienced
[22:20] <awmcclain> pickscrape: I'm getting a mysterious AttributeError: 'BzrDirNode' object has no attribute 'path'
[22:21] <pickscrape> I'll try updating mine and see if I get anything similar
[22:24] <awmcclain> My apt-fu is really bad. What's the easiest way to downgrade my bzr version? apt-get install bzr=1.5 doesn't work. I must be missing something obvious.
[22:25] <LeoNerd> That should be sufficient
[22:25] <LeoNerd> When you say "doesn't work" - explain in more detail
[22:26] <awmcclain> e.g. E: Version '1.5' for 'bzr' was not found
[22:26] <awmcclain> oh let me try updating the cache
[22:26] <awmcclain> though, if i have 1.6, you'd think it' be up to date
[22:27] <pickscrape> awmcclain: what page gives you that error?
[22:27] <awmcclain> pickscrape: Going _into_ a branch.
[22:27] <pickscrape> via the browser?
[22:27] <awmcclain> pickscrape: Browse source, yes.
[22:28] <awmcclain> I see the top level fine, but anything below. pfft.
[22:28] <pickscrape> I'm getting a different error: "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
[22:28] <awmcclain> :(
[22:28] <thumper> beuno: pong
[22:29] <pickscrape> Wonder if I'm using the right trac-bzr branch...
[22:29] <lifeless> beuno: drop the group count down
[22:29] <beuno> thumper, hi  :)   I just committed a fix for a bug in LH's search.  Is there anyway you can cherrypick that into the gnome playground, so I can make sure it fixes the problem?
[22:29] <lifeless> beuno: the fail-to-close is the refcounter hunting up objects and touching them before free, so its thrashing
[22:30] <beuno> lifeless, ah, right. So, "known issue"
[22:30] <thumper> beuno: hmm.. we need to upgrade the branch almost wholesale anyway
[22:30] <lifeless> beuno: so "python"
[22:30] <thumper> beuno: it might be easier to reapply the theme to trunk and use that
[22:31] <lifeless> robtaylor: which reminds me, the thing that concerns me about gobject is the ref counting; its really harsh on memory IO; can GObject run w/o it ?
[22:32] <beuno> thumper, ok, do you want me to update the gnome branch to the new theme then?  I know you where already working on some of that....
[22:39] <awmcclain> Nope. I've even tried sudo apt-get install bzr=1.5.0-1~bazaar1~gutsy1. I can't downgrade to 1.5
[22:42] <pickscrape> awmcclain: my problem appears to be when the branch isn't in a shared repository. If it is, I can browse into it fine
[22:43] <pickscrape> Which is odd.
[22:43] <awmcclain> pickscrape: I'm navigating into a shared repository. :(
[22:43] <pickscrape> Yes, and we aren't even getting the same error message :)
[22:43] <awmcclain> I'm just trying to downgrade now, but I'm having no luck.
[22:43] <pickscrape> What version of trac and the trac-bzr plugin are you using?
[22:46] <jam> awmcclain: well, if you have 1.6, doesn't that mean you are using the ~beta-ppa which doesn't have 1.5 in it?
[22:46] <jam> don't you need to use the ~bzr ppa instead?
[22:46] <pickscrape> Hah, just realised I've already raised a bug for my problem (bug #239591)
[22:46] <awmcclain> jam: I have both in my sources list. Let me double check. Good point.
[22:47] <awmcclain> jam:  apt-get install bzr=1.5 "should" work, correct?
[22:47] <awmcclain> i just want to make sure my command looks right.
[22:47] <jam> awmcclain: I don't know apt
[22:47] <jam> sorry
[22:48] <awmcclain> jam: Oh, son of a gun. I must have removed it.
[22:48] <awmcclain> sigh
[22:48]  * awmcclain sighs
[22:48] <jam> I can "upgrade" "update" and "install foo" but I haven't tried a specific version.
[22:48] <awmcclain> It's going to be a long day, i feel it.
[22:50] <james_w> awmcclain: what's the output of "apt-cache policy bzr"?
[22:51] <awmcclain> http://dpaste.com/71509/
[22:52] <awmcclain> Ah! got it.
[22:52] <awmcclain> sudo apt-get install bzr=1.5.0-1~bazaar1~gutsy1
[22:54] <awmcclain> Perfect. Downgrading fixed it.
[22:54] <james_w> cool
[22:54] <awmcclain> I should file bug in trac-bzr, yes?
[22:54] <awmcclain> file a bugt
[22:56] <james_w> it looks like it, yes
[23:08] <lifeless> jam: hi
[23:20] <jam> hi lifeless
[23:34] <weigon_> what shall I do if I get: bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: revno does not match len(mainline) 13 != 6191
[23:35] <lifeless> jam: what I"m trying to do with gc is get smooth integration with bzr
[23:35] <lifeless> jam: which is why sorting out fetch to be solid is important to me
[23:35] <jam> lifeless: I agree that fetch is important, I don't think the sort order is the most important part of it
[23:36] <jam> (gc => gc fetch is currently at 27 minutes and still on 0/4)
[23:36] <lifeless> jam: what do you think is the mort important part of fetch ?
[23:36] <jam> lifeless: getting it to fetch without recompressing everything
[23:37] <lifeless> jam: So the way that that will work will depend on the way gc->gc fetch is implemented
[23:37] <lifeless> I want to implement it via get_record_stream, which is what I'm working on, so I'm working towards that
[23:38] <lifeless> if it doesn't fit well via get_record_stream, then I'll do a custom thing like pack->pack does;
[23:38] <jam> lifeless: I feel like you are spending a lot of time getting the "optimal order when recompressing everything"
[23:38] <jam> but not skipping around it.
[23:38] <jam> because it isn't ever going to scale.
[23:39] <lifeless> well, AFAICT git recompresses everything on fetch
[23:39] <lifeless> it sends existing deltas but always decompresses on receipt
[23:39] <lifeless> anyhow
[23:40] <lifeless> I don't want to rush groupcompress, I want to take the time to get it well polished
[23:40] <jam> lifeless: gc is much more expensive then their compression strategy
[23:40] <jam> I'm not sure if we can improve it a lot or not.
[23:40] <lifeless> jam: its cheaper surely
[23:40] <lifeless> conceptually gc does less work
[23:41] <jam> I don't see it doing less work
[23:41] <jam> I suppose if you consider the cached hashes?
[23:41] <jam> At a minimum creating deltas is more expensive than expanding them
[23:42] <jam> by about 10-100:1 ?
[23:42] <lifeless> git does a xdelta (A, B), for a set of (B) to decide which B to insert next, and threads that
[23:42] <lifeless> it then reuses the one it chose.
[23:42] <jam> lifeless: I'm not positive, but I don't think it does that for transmission, only for "git pack"
[23:43] <lifeless> but it generates matching ranges etc from scratch for at least N-1 pairs
[23:43] <jam> (or repack, etc)
[23:43] <jam> I agree that it does that for repack --window ....
[23:43] <lifeless> transmission is less enthusiastic true
[23:43] <jam> I don't think it does that during "clone"
[23:43] <lifeless> but its still at least N-1 pairs
[23:44] <jam> lifeless: except for the ones it can re-use (which is at least what you just said)
[23:44] <jam> and GC can't be reused except in bulk
[23:44] <lifeless> we can just put the group on the wire intact
[23:45] <jam> lifeless: and doing that (IMO) is more important as a priority, and may preclude using get_record_stream
[23:45] <jam> lifeless: I'm *more* concerned about local branching than network, atm
[23:46] <jam> lifeless: because after you've gotten the wire stream, you still have to insert it into the local repo
[23:47] <lifeless> jam: well, if you're interested in scratching that part first, please do so :)
[23:47] <lifeless> I don't think that non-developer usage feedback is very useful at this stage for gc repos
[23:47] <jam> lifeless: I've got lots of other things on my plate before I can get to gc. Certainly you are welcome to scratch your itch. But it feels like you are trying to polish something that isn't *usable* yet.
[23:47] <lifeless> so I don't have any motivation to get the formats and compressor into bzr.dev per se

[23:48] <lifeless> I'm trying to get the *implementation of fetch usable*
[23:48] <lifeless> that means either custom-coded, or using get_record_stream
[23:48] <jam> Ok, I would suggest you are going about it in the wrong way.
[23:48] <jam> Perhaps not.
[23:48] <lifeless> you're complaining that its slow using get_record_stream
[23:48] <jam> I feel like you are polishing the insertion order.
[23:48] <lifeless> WHICH IS WHY I AM WORKIG ON GET_RECORD_STREAM
[23:49] <lifeless> jam: I'm working on the interface so that gc->gc using get_record_stream has the room to send an entire group and reuse it while still working correctly for knits
[23:49] <lifeless> we're trying to squash all these different use cases into one interface
[23:50] <lifeless> which is fine, but it means polishing the interface to be really nice
[23:50] <jam> lifeless: sure, and my feeling is that get_record_stream isn't a good fit.
[23:50] <lifeless> jam: you do realise that you haven't said that at all
[23:51] <lifeless> until now
[23:51] <jam> lifeless: I've been saying using an api that requires recompressing everything isn't a good fit. which is basically how get_record_stream() is designed (atm).
[23:51] <lifeless> not at all
[23:51] <lifeless> get_record_stream was designed explicitly to avoid recompressing
[23:51] <jam> And I don't see having: get_record_stream("gc-blobs")
[23:51] <lifeless> and knit->knit doesn't recompress
[23:52] <jam> lifeless: because the stream is designed as knit deltas.
[23:52] <lifeless> no
[23:52] <lifeless> because the api is flexible
[23:52] <lifeless> it may not be flexible enough
[23:53] <lifeless> which is one of the possible outcomes of this discussion
[23:53] <jam> lifeless: well, at present it talks about everything 1-text at a time
[23:53] <jam> which isn't possible for "optimal GC transmission".
[23:53] <jam> Specifically the "get_bytes_as()" portion.
[23:53] <jam> And 1 factory object per text
[23:54] <lifeless> I'm irritated because I feel like you are telling me I'm doing the wrong thing, but your objections have been about 'this bit over here is rough' not why the time is wasted
[23:54] <lifeless> jam: the API is stream->stream
[23:54] <lifeless> jam: the generic use of the stream is text->text
[23:56] <jam> lifeless: http://rafb.net/p/T8dpQb85.html
[23:56] <jam> a stream is an "iterator of ContentFactory objects"
[23:57] <jam> which is a series of Content objects. I will agree that it doesn't give a definition of what Content is.
[23:57] <jam> But if it is compatible with Knit
[23:57] <jam> then it would be 1 Content for each text.
[23:57] <jam> lifeless: look, *you* wrote the api, and you have the best knowledge of how it can be modified to fit what you are looking for.
[23:58] <jam> I'm going off the level that I've been exposed to it to date.
[23:58] <jam> Which isn't truly deep.
[23:58] <jam> The only flag we have at the moment to indicate what type of stream to produce is "ordering".
[23:59] <jam> Which doesn't really fit a "give a ContentFactory stream that is useful for knits" versus "give me a ContentFactory stream that is good for gc => gc".
[23:59] <jam> lifeless: I *do* see that the base-level ContentFactory object has a "self.key" member, rather than a "self.keys" parameter