[00:02] <poolie> jam, igc, spiv: call now
[00:02] <jam> poolie: waiting for you to show up :)
[00:16] <lifeless> jam: also - #ubuntu-wow
[00:16] <lifeless> poolie: ^
[00:21] <poolie> thanks
[00:21] <poolie> lifeless, igc: reading the thread now, this might take more than 15 mins
[00:22] <lifeless> -> food then
[00:22] <igc> poolie,lifeless: let's aim for 10 then
[00:27] <poolie> k
[00:50] <lifeless> abentley: ping; are you interested in me making MPVersionedFile meet the VersionedFile (reduced) api ?
[00:58] <lifeless> abentley: also can I request a review from you for my loom push fix.
[01:01] <ChrisPitzer> Hello.  I've used bzr in linux before, but now I'm trying to get it working in windows through putty.  I can run bzr in a terminal, or I can run putty and log on to my server (where I'd like to build a repository) with putty... but I'm not sure how to run bzr in putty...  I think I'm missing something.
[01:01] <lifeless> poolie: igc: its 10
[01:02] <igc> poolie,lifeless: normal number?
[01:02] <lifeless> igc: as far as I knew, yes.
[01:02] <poolie> we could use skype if that's easier?
[01:02] <lifeless> elevator music @ home sucks
[01:03] <igc> calling in now on normal number
[01:06] <dagreen> hey, can someone help a noob with an admin question?
[01:06] <dagreen> I'd like to setup an server for a central repository
[01:06] <dagreen> the docs tell me to use sftp to upload a branch
[01:07] <dagreen> but I want to make it publicly accessible
[01:07] <dagreen> how would I do this with sftp?
[01:07] <bob2> you can make it read-only accessible via http, and have users write via sftp
[01:08] <dagreen> so, setup an apache server?
[01:09] <bob2> well, whatever htpd you like.  you could setup an anonymous sftp account if you prefer.
[01:09] <bob2> gnu used to do that for cvs over ssh, iirc
[01:09] <dagreen> OK.  so, I tried searching for some good docs on settings up sftp, but came up short
[01:10] <dagreen> can someone point me to a good guide?
[01:10] <dagreen> I can setup sftp so users can access their own home dir, but not to a shared dir
[01:10] <dagreen> or even how to allow anonymous access for that matter?
[01:12] <poolie> this is hard enough even if i can hear you :)
[01:12] <poolie> dagreen: on unix or windows
[01:12] <dagreen> fedora
[01:13] <ChrisPitzer> How do i uze bzr in putty?
[01:13] <dagreen> unix
[01:13] <bob2> ChrisPitzer: what preciesly are you trying to do?  use bzr+ssh:// urls?
[01:13] <poolie> dagreen: so basically you should put them in a unix group
[01:14] <poolie> and create a directory writeable by that group to hold the repositories
[01:14] <poolie> if you're trying to host an open source project you can alternatively use launchpad.net
[01:14] <dagreen> not open source, internal company use
[01:15] <dagreen> so, if they were to checkout a project by typing bzr branch sftp://my-server/myproject
[01:16] <dagreen> do I have to put a link to that directory from all their home directories or something?
[01:16] <bob2> no
[01:16] <ChrisPitzer> bob2: I'm trying to use putty to ssh onto a server and set up / work with bzr repositories.
[01:17] <bob2> users connected via sftp have the same access rights as they would if they logged in via ssh
[01:17] <bob2> so it can go anywhere they could normally reach it (e.g. /srv/bzr/)
[01:17] <bob2> ChrisPitzer: as in ssh in via putty, and run bzr from the command line on the remote machine?
[01:18] <ChrisPitzer> i tried that - bzr isn't installed on the remote machine.
[01:18] <bob2> there's your problem then ;)
[01:18] <ChrisPitzer> haha.
[01:18] <ChrisPitzer> i know
[01:19] <bob2> you can access it remotely with sftp:// urls, have you tried that?
[01:19] <ChrisPitzer> i have bzr installed on *this* machine though... can't I use this bzr instance to create remote repositories...?
[01:19] <ChrisPitzer> just from the command line - no putty...?
[01:19] <bob2> "bzr init-repo sftp://blah/blah"
[01:19] <ChrisPitzer> hu... I'll give it a shot - brb
[01:20] <bob2> I think you need paramiko installed for that
[01:20] <ChrisPitzer> (i still think very "windows" some times)
[01:21] <dagreen> poolie:  after I shared directory and give the appropriate permissions to the group, how do I make it so that directory is the root when they sftp??
[01:23] <bob2> don't think regular openssh has sftp chrooting
[01:23] <dagreen> k, so the only way to make urls look like root is through http then, right
[01:24] <dagreen> ?
[01:36] <poolie> dagreen: just use sftp://host//home/group/repo
[01:37] <dagreen> k.  that should work for me.   didn''t know there was a /home/group
[01:37] <dagreen> thx
[01:39] <ChrisPitzer> so... check my crummy syntax here...
[01:40] <ChrisPitzer>  bzr init sftp://username:password@sub.domain.com/src
[01:40] <ChrisPitzer> because, that results in a bunch of happy text with a last line of "bzr: ERROR: No such file: '/src':"
[01:43] <bob2> try //src
[01:45] <ChrisPitzer> same sad ending.  "no such file: '//src' "
[01:45] <bob2> is there a /src on sub.domain.com?
[01:45] <ChrisPitzer> hehe... yes.
[01:46] <ChrisPitzer> where is // ? root?
[01:46] <ChrisPitzer> ooooh... bingo
[01:46] <ChrisPitzer> that's it.  I need to specify full path on the server, not relative.
[01:51] <fullermd> With sftp you can specify relative with a ~.  sftp://user@dom.ain/~/src
[01:55] <ChrisPitzer> thanks!
[02:28] <awmcclain> Hey all. So, am I right in figuring out that bzr-email ONLY works from the client-side?
[02:28] <spiv> That's right.
[02:29] <igc> lifeless: was it just me that dropped out?
[02:29] <awmcclain> That is frustrating.
[02:29] <igc> poolie:^
[02:29] <lifeless> igc: yes, credit ran out
[02:36] <radix> awmcclain:  https://bugs.edge.launchpad.net/bzr/+bug/211967
[02:36] <ubotu> Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed]
[02:38] <igc> lifeless: dropped out - I think we're done though, yes?
[02:38] <igc> poolie:^
[02:39] <igc> lifeless: if not, you can call me on my home line now
[02:40] <lifeless> poolie: the knit fetch hotfix has landed in trunk
[02:41] <spiv> awmcclain: we're working on fixing that.  I just updated the bug radix linked to with some details.
[02:41] <radix> woot
[02:41] <awmcclain> yay!
[02:41] <awmcclain> Ok. Not a problem.
[02:42] <radix> oh, so it might already be possible?
[02:42] <radix> great
[02:42] <spiv> radix: yeah
[02:42] <spiv> radix: "might" being the important word, I don't think it's actually been tested yet.  In theory it should be fine...
[02:42] <lifeless> spiv: bzr-email needs to be altered
[02:43] <spiv> lifeless: right.  I didn't mean to give the impression that bzr-email specifically would Just Work, yet.
[02:43] <spiv> Just that it should now be possible to write something that uses the new hook, and have that get triggered on the server.
[02:49] <lifeless> thumper: your patch is merged
[02:50] <thumper> yay
[02:50] <thumper> ta
[03:12] <abentley> lifeless: Updating the MPVersionedFile API is fine with me.  I guess reducing the number of APIs is a win, but it doesn't seem like a big win to me.
[03:13] <lifeless> abentley: i just noted in passing was all
[03:13] <abentley> Oh, I thought you were offering to change it.
[03:14] <lifeless> abentley: yes, if you thought it was a good thing
[03:14] <lifeless> but I also don't have a strong drive to do so
[03:16] <abentley> This loom push thing you want me to review is actually a patch to the loom plugin?
[03:20] <lifeless> yes
[03:21] <lifeless> there are two folk writing loom code
[03:21] <lifeless> and I like peer review
[03:22] <lifeless> I've taken a short cut in fixing push; I'm hoping you'll assess whether the short cut is ok, or say 'its better to leave it broken for a bit and get a more tasteful fix'
[03:24] <abentley> bb:approve I think it's a worthwhile improvement.  I suspect the wrong hook will fire, but I guess that's tolerable for now.
[03:24] <pygi> hey folks
[03:24] <lifeless> thank you
[03:25] <abentley> re BB, I apologize for the downtime.  It messed up this morning, and I wasn't able to get it working again.
[03:25] <lifeless> ouch
[03:25] <abentley> It's like everything I try to improve things makes it worse.
[03:28] <lifeless> is there any assistence you'd like ?
[03:39] <abentley> lifeless: I'd like to see if using pgsql clears up the locking issues.  Do you know a good way to convert the data?
[03:39] <lifeless> I'd probably export vis csv or similar
[03:40] <abentley> Really.  Huh.
[03:40] <lifeless> *via*
[03:40] <abentley> I did try just doing an SQL dump.
[03:40] <abentley> But it seems like pg doesn't recognize some of SQLite's escaping.
[03:41] <lifeless> alternatively you could do a select & insert within python
[03:41] <lifeless> I'm sure there are good toolchains to do this, I've never needed to though
[04:00] <lifeless> got to love the weather
[04:03] <RAOF> lifeless: It's probably different where you are than here.  Nice and sunny? :)
[04:05] <poolfool_> It's dark in Denver Colorado .. but it was a nice day.
[04:05] <poolfool_> To the BZR team, thank you for a great tool.
[04:08] <lifeless> RAOF: loud rain
[04:08] <lifeless> poolfool_: thanks!
[04:10] <poolfool_> lifeless: have you thought about doing a pod cast? FLOSS with leo leport(sp) had somone from the GIT team on in January.
[04:10] <lifeless> that could be interesting
[04:11] <bob2> no swearing.
[04:11] <poolfool_> http://twit.tv/FLOSS
[04:12] <poolfool_> bob2: searing?
[04:12] <poolfool_> s/searing/swearing/
[05:16]  * spiv -> lunch
[05:49] <igc> bbiab - picking kids up from school today
[05:54] <lifeless> http://www.justdave.net/dave/2008/04/06/bugzillamozillaorg-now-in-version-control/
[05:54] <lifeless> ^ cute
[06:48] <lifeless> poolie: ping
[06:49] <poolie> pong, the witch is dead,...
[06:50] <fullermd> Phew.  That'll save me the alimony...
[07:10] <lifeless> fullermd: better than 'the bitch is wed'
[07:10] <fullermd> "Fornication?  But that was in another country.  And besides, the wench is dead."
[07:44] <joerg_> Hi. Does anybody know what to do if I get the error message "bzrlib.errors.TokenMismatch: The lock token [...] does not match lock token (remote tokens)" while committing?  (bzr 1.3)
[07:46] <lifeless> jelmer: you had someone break the lock on you
[07:46] <lifeless> meh
[07:46] <lifeless> joerg_: ^
[07:47] <joerg_> any idea lifeless?
[07:47] <lifeless> try again
[07:47] <lifeless> it may be out of date
[07:47] <lifeless> or if its bound it may need to be pushed at this point
[07:49] <joerg_> I'm not sure what "bound" means. Do you suppose to try bzr update and then bzr commit again?
[07:52] <lifeless> yes
[07:53] <joerg_> docu says: "If you have a local branch and wish to make it a checkout, use the bind command like this: bzr bind sftp://centralhost/srv/bzr/X-repo/X-trunk"
[07:53] <joerg_> That is not the case. Its a checkout from a branch laying on the server repo
[07:56] <lifeless> k
[07:56] <lifeless> just do update and commit I think
[07:56] <joerg_> ok I try it. Thank you!
[08:04] <poolie> spiv: steve says you were going to speak to jam about the problem of " attempt to add line-delta in non-delta knit"
[08:04] <poolie> do you know what's up with that?
[08:07] <spiv> poolie: No, I don't know what's up with that.
[08:07] <spiv> poolie: jam thought it might be related to the critical fix we did for 1.3.1rc1
[08:08] <lifeless> bye for the day
[08:08] <spiv> poolie: which sounds plausible but not hugely likely to me. I don't know anything more about it.
[08:09] <spiv> (if anything, I'd expect the fix we did to try insert fulltexts unexpectedly, rather than line-deltas)
[08:11] <poolie> bye lifeless
[08:11] <poolie> it does seem to be in a similar area
[08:12] <poolie> i asked andreas to open a bug about it
[08:12] <fullermd> Is the ghost issue considered serious enough to be a 1.4 blocker?
[08:12] <spiv> Yeah.  I suspect it's related somehow, maybe the same root cause that caused the 1.3 regression?
[08:13] <spiv> I don't think I've seen a traceback for it yet though, so it's hard to speculate.
[08:54] <igc> night all
[10:20] <poolie> good night
[10:55] <awilkins> If you have an SSH key in launchpad you should be able to use bzr_shh to download anything from an LP bzr repo, no?
[10:56] <awilkins> Or is it sftp?
[10:56] <james_w> both should work
[10:57] <awilkins> I'm having trouble, is there a particular form for the username?
[10:57] <james_w> whatever your lp username is
[10:57] <james_w> what's your lp homepage URL?
[10:57] <awilkins> https://launchpad.net/~adrian-wilkins
[10:58] <james_w> and which branch are you trying to fetch?
[10:58] <awilkins> I've tried my email address (with @ escaped and not escaped), adrian-wilkins, all sorts
[10:59] <spiv> awilkins: you should be able to use URLs like "bzr+ssh://adrian-wilkins@bazaar.launchpad.net/..."
[11:00] <awilkins> Hmmph, it works with paramiko but not plink
[11:00] <spiv> Ah, I don't know much about the magic to make plink work.
[11:00]  * spiv -> food
[11:00] <ubotu> New bug: #217650 in bzr "Use of authentication.conf causes update to fail" [Undecided,New] https://launchpad.net/bugs/217650
[11:00] <awilkins> That's a regression, it should work with either
[11:01] <awilkins> It used to work with plink AFAIK
[11:01] <awilkins> Installing paramiko on Win32 is a PITA compared to plink as well.
[11:53] <awilkins> That horizon feature would be nice around now :-)
[11:54] <awilkins> What's the practice for submitting merges ; do you submit them all to bzr.dev, or do you submit them to the branch you are making them from?
[11:55] <ubotu> New bug: #217666 in bzr "exceptions.MemoryError when getting http://arch.sv.gnu.org/archives/emacs/bzr/emacs.app" [Undecided,New] https://launchpad.net/bugs/217666
[11:56] <james_w> awilkins: bzr.dev, unless you are making a change to something not yet merged, or fixing something on a release branch
[11:57] <awilkins> james_w: It's jsut a little patch to a couple of the hidden commands to make them more consistent with bzr unknowns
[11:58] <james_w> bzr.dev sounds right then.
[11:58] <awilkins> Is there a mail I can bzr send to? Or do I put up a bug with a merge bundle in it?
[11:58] <awilkins> (PQM is a bit much right now)
[11:59] <james_w> bzr send --mail-to bazaar@lists.canonical.com
[11:59] <awilkins> Groovy.
[13:25] <ubotu> New bug: #217701 in bzr "attempt to add line-delta in non-delta knit" [Undecided,New] https://launchpad.net/bugs/217701
[14:55] <ubotu> New bug: #217737 in bzr "bzr merge gives error over Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x01697050>"" [Undecided,New] https://launchpad.net/bugs/217737
[17:40] <dwt> Morning
[17:40] <dwt> I'm trying to use bzr with svn and have problems pushing to svn
[17:41] <dwt> it fails with error "('Mindestens eine Eigenschafts"anderung ist fehlgeschlagen; Projektarchiv nicht ge"andert', 175008)" wich roughly translates to "at least one property couldn't be changed"
[17:44] <dwt> Well, I'm quite puzzled what it means by that and am currently trying to convince it to give me a propper english response so I can search for it.
[17:46] <andrea-bs> dwt: type `LANG=en_US.UTF-8` in a shell and try to push
[17:47] <dwt> thanks andrea-bs - I'm trying it right now
[17:50] <Bronger> How can I force a synchronisation between an SVN repo and a local Bazaar branch?  Bazaar claims that both a diverged (which is technically correct), however, de-facto both branches contain exactly the same files.  I could merge, but then I get tons of conflicts.
[17:52] <dwt> Well, now it's much more talkative. I actually get a traceback and tells me that 5 should file a bug.
[17:52] <dwt> well....
[17:52] <dwt> The error is: SubversionException: ('At least one property change failed; repository is unchanged', 175008)
[17:52] <dwt> I'm gonna google for that
[17:52] <dwt> but if anybody of you can give me a hint how to debug this further, I'd love to hear it. :)
[17:53] <andrea-bs> dwt: this sounds like a bug, could you please past the entire traceback on <http://paste.ubuntu.com>?
[17:54] <dwt> sure
[17:54] <dwt> http://paste.ubuntu.com/7133/
[17:57] <dwt> It could be a bit more verbose about what property exactly it couldn't change....
[17:57] <andrea-bs> dwt: it seems a repo problem rather than a bzr problem
[17:58] <dwt> ok.....
[17:58] <dwt> I'l test that with svn
[17:58] <dwt> and see what I get
[18:01] <andrea-bs> I have to go now, bye!
[18:02] <dwt> thansk anyway andrea-bs
[18:02] <dwt> Well, subversion works perfectly
[18:02] <dwt> and I can also pull changes I got from subversion
[18:02] <dwt> and merge them and everything
[18:03] <dwt> though no push
[18:15] <newz2000> jam: can you remind me how your push and update plugin works again?
[18:16] <newz2000> never mind, I realized it runs automatically
[18:16] <newz2000> :-)
[18:16] <jam> newz2000: if you have it installed (the newest version) when you do 'bzr push' it should check if it is an ssh connection, and then run 'ssh host; bzr update' fo ryou
[18:16] <jam> for you
[18:16] <jam> newz2000: right, an earlier version required you to run 'bzr push-and-update' instead of 'bzr push'
[18:17] <jam> the newest version just installs a post-push hook to do it automatically
[18:17] <newz2000> nice plugin. Just what I need. :-)
[19:19] <Stavros> can someone help me use bzr-svn? i can't figure it out :/
[19:19] <Stavros> i do bzr branch svn://whatever and i get bzr: ERROR: Permission denied: ".": Can't get password
[19:21] <jelmer> Stavros: hi
[19:21] <jelmer> Stavros: See the FAQ
[19:23] <Stavros> i did, hmm
[19:23] <Stavros> it needed an svn info, svn up didn't cache the password
[19:23] <Stavros> but now it fails with permission denied
[19:24] <Stavros> :/
[19:24] <jelmer> did you run "svn info" on the root url of the repository?
[19:24] <jelmer> What OS are you on?
[19:24] <Stavros> windows
[19:24] <Stavros> i didn't, sec :/
[19:24] <Stavros> apparently i don't have permission to do that
[19:24] <jelmer> Stavros: Ah, it's broken on Windows atm unless you have Subversion 1.5 I think
[19:25] <Stavros> i installed the patched binding
[19:25] <Stavros> s
[19:25] <Stavros> i can't stand svn, it bogs down my entire system to do a simple diff
[19:25] <Stavros> bah, i guess i'll have to live with it...
[19:25] <jelmer> Stavros: the patched bindings don't contain the required fix for this
[19:25] <Stavros> is it safe to push with bzr-svn?
[19:25] <Stavros> ah
[19:25] <jelmer> yes
[19:25] <Stavros> i ah, good
[19:26] <Stavros> i don't want to much the repo up if it works eventually
[19:47] <abadger1999> Hey, how would I get the reverse of "bzr diff"?
[19:48] <dato> abadger1999: between two revisions?
[19:48] <abadger1999> ie: the diff of working tree -> latest commit.
[19:48] <dato> ah
[19:48] <abadger1999> I released a package out of a modified working tree instead of a fresh checkout.
[19:49] <dato> personally I'd do
[19:49] <dato> b commit -m foo
[19:49] <dato> b diff -r -1..-2
[19:49] <dato> b uncommit
[19:49] <andrea-bs> abadger1999: try with "bzr merge file.diff"
[19:49] <abadger1999> dato: Thanks!  That'll work for me.
[19:49] <abadger1999> andrea-bs: k.  I'll try that first
[19:51] <andrea-bs> abadger1999: it works with patches generated by "bzr send" and I'm not sure if this will work also with diff output
[19:51] <abadger1999> andrea-bs: bzr merge just tells me "Nothing to do."
[19:53] <andrea-bs> abadger1999: patch originalfile patchfile
[19:54] <foom> hey, so, is a "bzr obliterate" feature on the plan anywhere? I just had to remove some data from svn that was committed a year ago. It wasn't trivial, but it was possible, without screwing up every developer's checkout everywhere. It seems like with all the fancy DVCSes, that's simply impossible. (which is a problem)
[21:06] <Noia> >.>
[21:06] <Noia> whats the difference between bzr and svn
[21:06] <Noia> lol
[21:11] <asabil> Noia: to keep it short: bzr is better :p
[21:53] <lifeless> hi jam
[21:53] <jam> lifeless: hi
[21:53] <jam> lifeless: have you done anything with instrumenting packs?
[21:53] <jam> I've been thinking about doing a little bit of hit/miss stuff
[21:54] <jam> and then my ISP decided it required authenticated sends, and I had to spend way too much time getting Postfix to properly talk to them.
[21:55] <lifeless> jam: exim4 ftw :P
[21:55] <jam> well, my server is currently a really old FC4 install
[21:56] <lifeless> jam: no, as I said in my mail I don't have the time to do anything about it right now
[21:56] <lifeless> but I wanted to share the underpinnings that seemed to be missing when folk were trying to analyse it. lsprof is good, but it can't tell right from wrong.
[21:56] <jam> (the problem was that FC4 versus Breezy, and Breezy didn't recognize my SATA hard-drive card automatically)
[21:57] <jam> lifeless: well you could pretty easily, if you broke up the cache hit into a separate function
[21:57] <jam> I've certainly done stuff like create an inner function for loops so I can see how much time is spent in each
[21:57] <jam> def run_loop_x():
[21:57] <jam>   for foo in bar:
[21:57] <jam>   pass
[21:57] <jam> run_loop_x()
[21:58] <lifeless> jam: that doesn't tell right from wrong
[21:58] <jam> lifeless: that is to profile the time spent in that loop (as an example)
[21:58] <lifeless> yes, but I never said lsprof can't do that
[21:58] <jam> You could try something similar for cases where there is a hit versus a miss
[21:58] <jam> call a different func
[21:59] <jam> but I'm not sure where the time is actually spent
[21:59] <jam> anyway, I understand your point
[21:59] <jam> it is still hard to *time* a miss versus a hit
[21:59] <jam> counting isn't hard
[22:00] <lifeless> its also hard to decide if the amount of time per unit is as expected, or the number of units is as expected
[22:00] <lifeless> that requires a model for the operation
[22:01] <lifeless> e.g. for working tree operations we all share the model of '1 stat per file, and 1 read per file if needed'
[22:01] <jam> lifeless: by the way, I think our pack => knit fetcher causes weird problems with revision_id references
[22:01] <jam> specifically, I think I see it generating revisions out of order
[22:01] <jam> (newest first, rather than topologically sorted)
[22:01] <jam> I can say that my knit repository (which I push to from packs) has all sorts of crazy stuff going on
[22:01] <jam> still technically "correct" but just improperly orderd
[22:02] <lifeless> interesting
[22:02] <jam> The problem is that I'm generally seeing all of this as artifacts in revisions.kndx, without actually reproducing it
[22:08] <jam> lifeless:  can I have you take a peek at a line of code
[22:08] <jam> Specifically line 662 of bzrlib/index.py
[22:08] <jam> It seems to be mixing indices
[22:08] <jam>             index = self._parsed_byte_index(location)
[22:08] <jam>             # if the key is below the start of the range, its below
[22:08] <jam>             if key < self._parsed_key_map[index][0]:
[22:09] <jam> lifeless: if I'm actually reading a bug, then it would indicate we are not properly "bisecting"
[22:10] <jam> or does _parsed_key_map[index] always match up to _parsed_byte_index
[22:11] <lifeless> in the __init__
[22:12] <lifeless>         # a sorted list of slice-addresses for the parsed bytes of the file.
[22:12] <lifeless>         # e.g. (0,1) would mean that byte 0 is parsed.
[22:12] <lifeless>         self._parsed_byte_map = []
[22:12] <lifeless>         # a sorted list of keys matching each slice address for parsed bytes
[22:12] <lifeless>         # e.g. (None, 'foo@bar') would mean that the first byte contained no
[22:12] <lifeless>         # key, and the end byte of the slice is the of the data for 'foo@bar'
[22:12] <lifeless>         self._parsed_key_map = []
[22:12] <lifeless> (they use the same values to lookup
[22:12] <lifeless> its not a single map to a tuple because of bisect needs
[22:12] <lifeless> oh, where is my cleanup of this code
[22:13] <lifeless> I have a branch that introduces an abstraction here
[22:13] <lifeless> pushing it now
[22:15] <ubotu> New bug: #217917 in bzr ""bzr commit" MemoryError crash" [Undecided,New] https://launchpad.net/bugs/217917
[22:24] <lifeless> jam: whats an operation thats still problematic ?
[22:50] <goozbach> Quick question: I couldn't find an answer in the bzr user guide.
[22:51] <goozbach> I want a "pushed" branch to always have the current contents
[22:52] <goozbach> eg, I run bzr push from my laptop, and want the pushed location (a web accessable directory on a server) to automatically update
[22:52] <jam> lifeless: well 'bzr status' after a pending merge, but that is bad for other reasons :)
[22:52] <mwhudson> goozbach: the push-and-update plugin can do that
[22:52] <goozbach> is this possible without creating a hook
[22:52] <jam> a simple 'bzr log' on a very long history is bad
[22:52]  * goozbach googles
[22:53] <goozbach> mwhudson: thanks
[22:53] <jam> lifeless: 'time bzr log --short -r -10..-1 bzr.dev' is quite a bit longer than it should be
[22:53] <jam> goozbach: cd ~/.bazaar/plugins;  bzr branch lp:bzr-push-and-update push_and_update
[22:53] <jam> (possibly with a mkdir -p ~/.bazaar/plugins first)
[22:54] <goozbach> jam: just got it
[22:54] <goozbach> thanks though
[22:54] <jam> goozbach: it will update if it detects that the remote location has a working tree, and you are connecting over sftp or bzr+ssh
[22:54] <jam> it won't do it if you are using ftp etc
[22:54] <goozbach> yay!
[22:54] <lifeless> jam: 2.5 seconds for me
[22:55] <goozbach> hooray for not re-inventing the wheel
[22:55] <goozbach> thanks guys
[22:55] <jam> lifeless: yeah, but it used to be <1s
[22:55] <lifeless> k
[22:55] <goozbach> I knew I wasn't the only one who wanted that to happen
[22:55] <jam> goozbach: it does require that you have bzr installed on the remote machine, and have regular 'ssh' access
[22:55] <jam> in case that matters
[22:56] <jam> (it basically just calls 'ssh host bzr update' for you)
[22:56] <jam> lifeless: 'bzr log --long -r -10..-1' would also be even worse, I just never use it
[22:57] <jam> --long is going to do a whole revision-graph search because of dotted revnos
[22:57] <goozbach> jam: it's working.
[22:57] <goozbach> I was mostly wondering if someone else had done the legwork
[22:58] <goozbach> yay!
[22:59] <jam> goozbach: yep, I'm glad it works for you, feel free to post bugs, etc.
[22:59] <jam> it is pretty simple, though, so I don't expect you would have problems.
[23:00] <jam> I suppose I should now trap into the 'branch_changed_revision' hook in 1.4, so that it will also work if you have a checkout of the public location, rather than only on push
[23:50] <spiv> Good morning.
[23:54] <jam> morning spiv
[23:55] <igc> morning
[23:55] <igc> morning jam, spiv