[12:06] <lifeless> GzipFile is a wrapper around zlib in python that does what gzip does
[12:07] <keir> one sec on phone
[12:07] <lifeless> robertc@lifeless-64:~$ python -m timeit -s 'one_hundred_million_bytes= "A"*1024*1024*100' -s 'import zlib' 'zlib.compress(one_hundred_million_bytes)'
[12:07] <lifeless> 10 loops, best of 3: 2.64 sec per loop
[12:16] <keir> cool
[12:19] <keir> lifeless, what do you think? or you haven't finished your coffee :)
[12:21] <keir> i have to run, i'll be back in ~5 hours
[12:22] <keir> i'm going to be on a bus, i'll probably implement some stuff while i'm in transit
[12:44] <lifeless> jbailey: long time no see!
[12:45] <jbailey> lifeless: Yup, finally settling enough to visit.
[12:45] <jbailey> I understand that I missed your wife here on my first day.
[12:45] <lifeless> how's the babe?
[12:45] <lifeless> oh shame
[12:45] <jbailey> I couldn't get out of the orientation to sneak off and visit Leslie, though. =)
[12:45] <jbailey> He's terribly cute.  Much happier to not be stuffed into a car seat every day, though. =)
[12:46] <lifeless> you drove all the way?
[12:46] <jbailey> Yeah.  We've put 3600 miles on the rental vehicle.
[12:46] <jbailey> Mmm.  Civilized measurements that's.. mm
[12:46] <lifeless> so thats what, 48 hours of driving ?
[12:46] <jbailey> 5500km or so?
[12:46] <jbailey> Probably a touch more.
[12:47] <jbailey> It was about two weeks, most days about 4 hours of driving.  Some with none, some with 6 or 7.
[01:55] <Odd_Bloke> lifeless: As someone who's not particularly familiar with the innards of bzr is the work that keir is doing ATM aimed at reducing disk usage, decreasing computational overhead or a combination of the two?
[01:57] <BasicOSX> I did a bzr checkout --light-weight http://foo/bar/
[01:58] <BasicOSX> no when I cd into bar and do a bzr pull I get issues about read-only?
[01:58] <BasicOSX> bzr: ERROR: bzrlib.errors.UnlockableTransport: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.eqenchanters.org/WoW/AddOns/.bzr/repository/>
[01:59] <thatch> BasicOSX: yeah, that's because it's trying to pull _into_ the thing you did a checkout of
[01:59] <thatch> do you mean to 'bzr up' instead?
[01:59] <Odd_Bloke> BasicOSX: You want 'bzr update'.
[01:59] <Odd_Bloke> Too slow. :(
[01:59] <thatch> mere seconds, Odd_Bloke...
[02:01] <BasicOSX> Can you point me to a url where it explains diff between pull and update? I assume a checkout --light-weight means bzr expects no changes will happen in that area and it's more or less r/o?
[02:05] <thatch> BasicOSX: if you have r/w access to the branch that it's bound to, doing a commit will write directly to that, and doing an update will read from it.  It's like push/pull but on a more svn-like scale.  I'm not sure if there's a good url... Odd_Bloke?
[02:07] <Odd_Bloke> thatch: I've been looking around and there doesn't seem to be a brilliant explanation anywhere...
[02:10] <thatch> halfway down http://bazaar-vcs.org/SharedRepositoryTutorial I find a decent set of steps
[02:10] <thatch> I tried googling and didn't come up with anything, is it linked from the bazaar-vcs wiki?
[02:11] <BasicOSX> I'll take a look at that, thanks
[02:15] <fullermd> Hm.  I think I'll steal that for a followup, actually, as a case in point.
[02:15] <lifeless> Odd_Bloke: keir is working on the index for pack repositories
[02:15] <lifeless> Odd_Bloke: I wrote a toy one, so that I could do some major restructuring vs knit repositories
[02:16] <lifeless> Odd_Bloke: with the intent of a) finding a victim^Wvolunteer to write a better one, or b) coming back later and doing a better one myself.
[02:23] <calvin_> hello, how do i set up bzr to use a proxy in ubuntu?
[02:25] <calvin_> anyone?
[02:30] <calvin_> anyone alive at all?
[02:30] <fullermd> I think it checks a standard env variable, for HTTP at least...    HTTP_PROXY or http_proxy or something like that?
[02:31] <calvin_> yes, i know that much, but don't i need to put it into a config file?
[02:32] <fullermd> I'm pretty sure it'll read it out of the environment.
[02:33] <fullermd> There may be a config file option for it as an alternate choice...  not sure.
[02:38] <calvin_> what do you mean 'read it out of the environment?
[02:39] <calvin_> do you mean it might detect my gnome proxy settings?
[02:48] <fullermd> I mean read the env variable, if it exists.  I dunno if gnome works via that or not; that's pretty far off my path.
[11:31] <NamNguyen> hi
[11:31] <NamNguyen> is there a service wrapper for bzr on windows?
[11:35] <Radtoo> You want to run bzr as windows service?
[11:36] <NamNguyen> yes i do
[11:37] <Radtoo> as in "bzr serve" or something else?
[11:38] <NamNguyen> yes
[11:38] <NamNguyen> as bzr serve
[11:42] <Radtoo> Hmm, I haven't seen such a thing so far, tho I'm not doing this with windows either.
[11:45] <Radtoo> I figure you could use srvany...
[11:46] <hstuart> NamNguyen, you should be able to use this to run bzr serve as a service: http://agiletesting.blogspot.com/2005/09/running-python-script-as-windows.html  though I'm not running Windows so I haven't tested it. Caveat emptor and all that stuff.
[11:46] <NamNguyen> thanks hstuart, i'll check it out
[11:47] <Radtoo> oh you found a full howto. :D
[11:47] <hstuart> amazing what a google for python windows service can turn up ;)
[11:48] <Radtoo> I see. :p
[11:50] <Radtoo> Tho looking at the tutorial, it's also amazing that you have to edit the registry, use one or many additional apps etc just to run a script as service :D
[11:51] <hstuart> Windows does pretty much everything through the registry, so I'm not terribly surprised by that
[11:53] <Radtoo> I guess it was expected that everything setup related is handled by installers... hehe
[06:05] <keir> lifeless, around?
[06:06] <abentley> keir: unlikely at this hour in Australia.
[06:06] <abentley> He usually shows up in around four hours, but not very often on weekends.
[06:09] <keir> yes, i just checked world clock :)
[06:14] <abentley> keir: $ TZ=Australia/Sydney date
[06:32] <mathbr> Hi. How can I tell bzr to ignore one or more files in a local branch no matter what happens? Those files should never ever be invoked in merge's and send's.
[06:32] <abentley> mathbr: You should not "bzr add" files if you don't want bzr to merge or send them.
[06:33] <abentley> You can use "bzr remove --keep" to un-add the files.
[06:33] <mathbr> And then they won't get touched when, let's say, someone modifies those files in the original repo?
[06:33] <abentley> Right.
[06:33] <mathbr> I'll try that then, thanks.
[06:34] <abentley> The first time you pull or merge, after the files have been removed, they will be deleted.
[06:35] <mathbr> Hm... Just saw that the deletion is also visible in a send... I don't want it to appear there either...
[06:36] <abentley> It's a one-time thing.
[06:36] <mathbr> How to get to the second-time?
[06:37] <abentley> copy the files before merging/pulling them.
[06:37] <mathbr> I did changes to some local files and want to create a patchfile now but without the deletion of that other file
[06:37] <abentley> Well, if you just want to create a patch, you can do "bzr diff".
[06:38] <abentley> That lets you specify which files you want to include.
[06:38] <mathbr> I know. But I was told to create a branch and to patches via send to make merging easier.
[06:39] <abentley> So either create a patch with just the files you want, or do a send, and deal with the fact that these files are gonna be deleted.
[06:40] <mathbr> I'll look into that, thanks.
[06:41] <abentley> Or else, shelve the changes to the files, commit a new revision, send that, and unshelve.
[06:42] <mathbr> I'd have to do that for each commit, right?
[06:42] <abentley> Well, I'm assuming you've already committed these changes to the local files.
[06:43] <abentley> In the future, you can avoid committing changes to those files.
[06:48] <mathbr> Ah well, I'll just return to a normal checkout and drop my branch.
[06:51] <mathbr> abentley: Thanks for your help and bye
[06:51] <abentley> No problem.
[06:54] <keir> is there a reason KeyboardInterrupt isn't caught at the top level?
[06:54] <abentley> It would suck if you couldn't ^C out?
[06:54] <keir> no, as in, i get a 5 page traceback
[06:54] <abentley> That's not typical.
[06:54] <keir> rather than 'bzr: interrupted'
[06:56] <keir> it happens for all my tests when i hit C-c right away after hitting 'enter' on the command
[06:56] <keir> also: my repository should never be broken if I do a ctrl-C partway through, correct?
[06:56] <keir> on any operation?
[06:57] <abentley> Well, you may be ^C-ing too early, but that's still surprising.
[06:58] <abentley> It's always safe to ^C.  The worst case, if you do it while writing to the repository, is that you'll get some unreferenced data.
[07:00] <keir> oh, but that won't get caught and cleaned up?
[07:00] <abentley> No, repository operations are strictly append-only.  Cleanup would violate that and increase the risk of data corruption.
[07:00] <jelmer> 'evening keir, abentley
[07:01] <keir> morning!
[07:01] <jelmer> abentley: has anything changed in the is_ancestor() code since 0.90 ?
[07:01] <abentley> Hi jelmer.  Was there something you wanted to ask me?
[07:01] <abentley> I'm not aware of any changes to is_ancestor.
[07:01] <jelmer> abentley: It is trying to call get_revision(None).parent_ids in 0.90 but works fine in bzr.dev
[07:02] <abentley> Are you passing None in as a parameter?
[07:03] <jelmer> I'm pretty sure I don't, but let me check..
[07:03] <abentley> 'cause we did do a whole bunch of changes where we stopped returning None for the null revision.
[07:04] <abentley> So if you're passing in Branch.last_revision, or Tree.last_revision, that might have been None in 0.90
[07:05] <jelmer> abentley: ah, you're right
[07:05] <jelmer> Yes, I am passing in the result of Branch.last_revision()
[07:05] <jelmer> thanks!
[07:05] <abentley> You can use revision.ensure_null to fix it up.
[07:06] <abentley> No problem.
[07:07] <jelmer> I would expect Branch.last_revision() to return NULL_REVISION in this case though. Why is it still returning None?
[07:08] <abentley> The NULL_REVISION changes landed in two batches.
[07:09] <abentley> First was input, second was output.
[07:09] <abentley> Because the output changes are API breaks.
[07:11] <abentley> Branch.last_revision has returned None since the first release of Bazaar.
[07:11] <jelmer> ah, makes sense
[07:20] <keir> wow, is bzr share (aka zeroconf support) going to be targetted for upstream inclusion?
[07:31] <mwh> oh crap, i meant to mention that in my talk
[07:32] <mwh> oh well, i ran out of time anyway
[07:36] <keir> bzr share is the type of polish that can make someone impressed enough to switch
[07:39] <keir> has anyone considered build a 'branch registry' for umbrella projects with communities of developers?
[07:40] <keir> s/build/building/
[07:40] <keir> where bzr itself would know about the project (rather than just a branch or single repository)
[07:40] <keir> and you could do things like bzr list-community-branches
[07:40] <keir> bzr branch community://packs-refactor
[07:41] <keir> or maybe bzr branch project://branch-name
[07:42] <keir> is it possible for transports to be added as plugins?
[07:44] <luks> with python it would be quite hard to _not_ make it possible :)
[07:45] <abentley> Certainly: WebDAV is already implemented that way.  And see the lp: plugin
[07:46] <keir> aah, ok
[07:48] <keir> abentley, is there a page for the lp: plugin?
[07:57] <abentley> No.  It comes with Bazaar.
[07:59] <keir> i see register-branch, but that's it
[08:01] <abentley> bzr help launchpad
[08:04] <keir> neat
[11:59] <nir> Some tests fail on Mac OS X
[11:59] <nir> FAIL: test_sftp_transport.SFTPTransportTestRelative.test__remote_path
[11:59] <nir>     not equal:
[11:59] <nir> a = '/tmp/testbzr-xN4cVR.tmp/tmpRpl0nW/work/relative'
[11:59] <nir> b = '/private/tmp/testbzr-xN4cVR.tmp/tmpRpl0nW/work/relative'
[12:00] <nir> The test is broken - /tmp is symlink to /private/tmp :)