[00:00] <Odd_Bloke> beuno: OOI why Postgres over MySQL?
[00:02] <beuno> Odd_Bloke, because that's what I've been working for the past 6 years  :)
[00:02] <beuno> I'm not saying that should be *the* backend
[00:02] <beuno> it's just easier for me to start with that, implement it, and then jump to pg
[00:02] <Odd_Bloke> beuno: My question was the other way around. :p
[00:02] <Odd_Bloke> Or, why is Postgres the end goal? Won't MySQL be good enough?
[00:03] <beuno> Odd_Bloke, ah, sorry, was expecting a MySQL bashing  :p
[00:03] <beuno> yes, MySQL should be good enough, but I suspect PG will be prefered from people coming from LP
[00:08] <mwhudson> has anyone here installed turbogears on leopard?
[00:08] <Odd_Bloke> beuno: Ah, yeah, that hadn't occurred to me.
[00:08] <mwhudson> without wanting to maim someone (possibly themselves)
[00:22] <abentley> Odd_Bloke: Yeah, familiarity with PG, and I understand that PG is a more correct SQL implemplementation.
[00:24] <beuno> abentley, any idea why I would get this while voting?  http://paste.ubuntu.com/13751/
[00:25] <abentley> Your account doesn't have any submitter associated with it, I would imagine.
[00:25] <abentley> If you used the create_account script, that shouldn't have happened.
[00:26] <beuno> I did
[00:26] <beuno> I'll clean the DB and try it again
[00:27] <abentley> It looks as though the submitter list is optional, but you should have at least one.
[00:27] <Odd_Bloke> abentley: Well, there's certainly an argument that being a correct SQL implementation isn't necessarily a good thing. :p
[00:27]  * Odd_Bloke had Hugh Darwen teach his Intro to Databases course, and has disliked SQL since. :D
[00:44] <abentley> beuno: How do you want this sqlite file?  Email?
[00:45] <beuno> abentley, email is fine, yes
[00:45] <Odd_Bloke> abentley: Might be worth putting it somewhere several people can get, if it could aid development...
[00:46] <abentley> Odd_Bloke: Okay.
[00:46] <beuno> hrm, I'm making some progress with moving over the data, although I'm not sure how I'm going to automate some steps
[00:47] <beuno> I've got *most* tables in mysql with data
[00:47] <abentley> beuno: What approach are you taking?
[00:47] <beuno> abentley, exporting the SQL db, replacing known differences between sqlite and mysql queries, and dumping into the mysqldb
[00:48] <abentley> beuno: Are you prepared to deal with binary data that way?
[00:49] <beuno> abentley, AFAIK, binary data should be dumped and imported correctly, but I'll get back to you when I actually test it  :)
[00:49] <beuno> that would be mainly for patch_text, right?
[00:49] <abentley> beuno: There are some UTF16 files in there.
[00:49] <abentley> IIRC.
[00:51] <beuno> abentley, I'm going to aim at getting all the tables created and data fully imported into them, and then start to check consistency
[00:51] <beuno> that's where the bzr db will come in handy  :)
[00:54] <beuno> I'm going to head home now to get something to eat, but I'll be back in a while, I'm curious to see how far I can get without running into substantial blocker
[01:20] <abentley> beuno: http://code.aaronbentley.com/bundlebuggy/devdata.sqlite.nopasswords
[01:23] <beuno> abentley, great, thanks! I'll use that as soon as I get mysql to create all the tables correctly  (already home)
[01:47] <NemesisD> how does bzr treat symlinks by default?
[01:47] <NemesisD> i made a change to a symlink file and i noticed that bzr commit didn't list the file as changed
[01:49] <bob2> if the symlink and destination are versioned by bzr, it should work (and does for me)
[01:58] <beuno> abentley, I haven't tried with the bzr db, but with small adaptations to the table structure, and replacing a few characters from the sqlite dump, data seems to get imported correctly into mysql. I'm leaving for a few hours, and hopefully I'll be back to test it against the bzr db
[01:58] <beuno> (I imported the blobs from sqlite, and they seem to get imported correctly)
[01:59] <abentley> Well, that sounds promising.
[02:31] <igc> morning
[02:47] <igc> poolie: Thanks for your emails re file categories. I've emailed the list with my latest thoughts so I'd be keen for you to consider them when times permits.
[02:55] <hersonls> poolie: here
[03:08] <abentley> beuno: I've updated the docs.
[03:21]  * igc lunch
[05:44]  * igc pick up kids
[05:44] <Odd_Bloke> ZOMG netsplit.
[06:57] <poolie> hello lifeless
[06:57] <poolie> lifeless: could you look at balleny again if you get a chance or ask a sysadmin to do so, it's still ridiculously slow
[06:59] <lifeless> poolie: will nag
[08:23] <lifeless> liw: how is the rsync?\
[08:23] <liw> lifeless, the big pack file has about 43 more hours to go, and then there's another 227 thousand more files
[08:24] <lifeless> are you copying the working trees?
[08:24] <liw> nope
[08:24] <lifeless> strange
[08:25] <lifeless> let the big file finish
[08:25] <lifeless> then stop the rsync, and do 'for branch in branches; bzr zap-tree $branch'
[08:26] <liw> ack
[08:26] <Peng> "zap-tree"?
[08:26] <lifeless> something like
[08:26] <lifeless> remove-tree, zapt-ree, I dunno
[08:27] <Peng> remove-tree.
[08:27] <Peng> zap-tree would be a useful alias. "remove-tree" is long.
[09:13]  * igc dinner
[09:15]  * gour wonders why igc always has dinner so early...we hardly took a breakfast here
[09:21] <lifeless> timezones ftw
[09:22] <gour> timezones? i thought there is no life out of the europe
[09:23]  * gour is joking a bit...holiday is here today ;)
[09:48] <mtaylor> .THIS .OTHER .BASE - is there a doc describing them anywhere?
[09:50] <gour> mtaylor: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#resolving-conflicts
[09:50] <spiv> mtaylor: "bzr help conflicts"
[09:51] <spiv> Hmm, test_35_wait_lock_changing has bitten me twice today.
[10:10] <[reed]> How does bzr compare to this? http://quotes.burntelectrons.org/3715
[10:13] <luks> [reed]: ideally, you don't rebase, but merge instead
[10:14] <luks> but if you really must, there is a plugin, so you can do just 'bzr rebase'
[10:14] <LarstiQ> or just pull
[10:14] <luks> LarstiQ: I guess the situation is that you have a committed change and you want to pull
[10:14] <luks> at least that's what I understood from the hg sequence of commands
[10:14] <LarstiQ> luks: that explains the need for rebase, the 'cvs up -A' is a bit misleading though
[10:15] <luks> er, I meant ;'and you want to push'
[10:16] <[reed]> yeah
[10:16] <[reed]> k, thanks
[11:14] <lifeless> [reed]: ouch, that quote hurts my eyes
[11:19] <[reed]> lifeless: hehe
[12:08] <elmo> lifeless: fail.  :/  dapper chroot is <1s on my laptop
[13:17] <lifeless> elmo: garh
[13:43] <elmo> should bzr build-depend on the pyrex stuff?
[13:44] <elmo> nm
[13:45] <lifeless> no
[14:19] <jml> abentley: ping
[14:27] <emgent> hello people
[14:30] <emgent> http://pastebin.ubuntu.com/13848/
[14:30] <emgent> some idea?
[14:31] <emgent>   launchpad            /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
[14:34] <fullermd> Think that's fixed in newer bzr.  1.5 should have it.
[14:34] <fullermd> bug 217701
[14:37] <emgent> fullermd: uhm
[14:38] <emgent> i think no
[14:38] <emgent> http://pastebin.ubuntu.com/13849/
[14:38] <emgent> i have newest bzr
[14:38] <fullermd> No, you have 1.3.1.
[14:38] <fullermd> 1.5 has the fix.
[14:38] <emgent> uhm just a moment
[14:38] <emgent> uhm true
[14:38] <fullermd> Coffee.  Blame it on lack of coffee   :)
[14:39] <emgent> :)
[14:40] <elmo> lifeless: "fixed"
[14:40] <elmo> best non-solution ever
[14:41] <abentley> jml: pong
[14:43] <jml> abentley: I've got a patch to the stacked branch stuff that only really makes sense to apply to your branch.
[14:43] <jml> abentley: it make BzrDir.clone() also clone stacked_on information.
[14:44] <abentley> jml: Wouldn't it also make sense to apply to Robert's branch?
[14:45] <jml> abentley: logically yes. I haven't tried applying it though.
[14:47] <abentley> thumper and I haven't discussed what he wants me to do vis-a-vis an integration branch, but I'm happy to look it over.
[14:49] <jml> abentley: http://pastebin.ubuntu.com/13853/
[14:49] <jml> abentley: lifeless paired with me to do that, fwiw.
[14:54] <abentley> So I guess the main concern I have is whether "push" uses clone or sprout.
[15:47] <lifeless> elmo: new kernel?
[15:50]  * lamont idly wonders why the ppa archive for bzr doesn't bother with a bzr_1.5.0.orig.tar.gz
[15:50] <lamont> admittedly, bzr_1.5.0-$mumble.tar.gz is only 3.5MB, but still...
[15:51] <pickscrape> Is the PPA archive suitable for debian users, or is it Ubuntu only?
[15:51] <lamont> installing ubuntu debs on debian and vice versa is an action that is fraught with peril.
[15:52] <lamont> OTOH, bzr_1.5-1 is in sid
[15:52] <pickscrape> What's sid?
[15:52] <lamont> debian unstable
[15:52] <lamont> and I rather expect that someone has tossed it at backports.debian.or
[15:52] <lamont> g
[15:53]  * pickscrape is a debian distro noob. Long time gentoo user.
[15:53] <elmo> lifeless: yea, that 'fixed' it - it's still reproducable on tungsten, which is edgy (2.6.17.4)
[15:53] <lamont> welcome to the fold
[15:57]  * lamont rotfl at the bzr packaging using quilt.
[16:03] <sabdfl> nfw
[16:03] <Psy|ecimTech> hi there!
[16:03] <sabdfl> hi Psy|ecimTech
[16:03] <Psy|ecimTech> Just a quick question :P
[16:05] <Psy|ecimTech> I'm playing a bit using the smart server, but seems that when I kill the process, the 4155 port remains open.
[16:05] <Psy|ecimTech> So, next time I fire up the server, I get this error: error: (98, 'Address already in use')
[16:06] <Psy|ecimTech> Oh, now its ready, seems that it takes time to close up the port on ubuntu
[16:07] <MattCampbell> Looks like the smart server may not be setting the SO_REUSEADDR option; I'll check.
[16:08] <Psy|ecimTech> Yep, seems that you must wait for a timeout to reuse the port
[16:09] <MattCampbell> Indeed the SO_REUSEADDR socket option isn't being set.
[16:10] <MattCampbell> Wait, I'm not looking at the latest code.
[16:12] <Psy|ecimTech> BTW, whe are playing a bit versioning thru smart server on windows <-> ubuntu 64.
[16:13] <MattCampbell> If you're running a smart server on Ubuntu, why not use bzr+ssh instead?
[16:14] <MattCampbell> (I'm waiting on a checkout of bzr trunk so I can see if the smart server sets SO_REUSEADDR in the latest revision.)
[16:15] <Psy|ecimTech> Oh, we're just starting, and just avoid any problem on windows side...
[16:19] <MattCampbell> Looks like the smart server sets the SO_REUSEADDR option in bzr trunk.  Anyone know when this was done?
[16:20] <MattCampbell> Psy|ecimTech: What version of bzr are you running on the Ubuntu machine?
[16:21] <Psy|ecimTech> Wait a minute, the Ubuntu guy is just comming in
[16:21] <Psy|ecimTech> there!
[16:22] <MattCampbell> The SO_REUSEADDR fix was done on 2008-04-21.
[16:23] <Psy|ecimTech> Gus_Tronador: -> MattCampbell: Psy|ecimTech: What version of bzr are you running on the Ubuntu machine?
[16:23] <Psy|ecimTech> Gus_Tronador: -> MattCampbell: The SO_REUSEADDR fix was done on 2008-04-21.
[16:23] <MattCampbell> So it should be in 1.5.
[16:23] <Psy|ecimTech> Seems to be 1.3.1
[16:24] <Psy|ecimTech> Could it be a RC?
[16:24] <MattCampbell> An update to 1.5 should fix the problem.
[16:24] <MattCampbell> 1.5 came out a few days ago.
[16:25] <MattCampbell> BTW, I'm a bzr newbie too, so maybe what I'm saying is obvious to everyone else here.
[16:26] <Psy|ecimTech> No, thats great, but seems that ubuntu's repo is still not updated to the latest
[16:27]  * MattCampbell looks on packages.ubuntu.com
[16:27] <luks> you can use https://launchpad.net/~bzr/+archive
[16:28] <Psy|ecimTech> ahhh great!
[16:47] <Gus_Tronador> Hello! ... I'm using BZR in ubuntu 8.04 Hardy Heron and I have an issue with "bzr server" ... When I run it from console and I stop it with "ctrl+c" socket remains open or address-port 0.0.0.0:4155 remains binded to socket
[16:47] <Gus_Tronador> so ... I wish I could unbind it to restart server. Could someone please help me?
[16:48] <Gus_Tronador> (when I try to re-run "bzr server" I get : "bzr: ERROR: Cannot bind address "0.0.0.0:4155": Address already in use." )
[16:50] <radix> heh
[16:51] <radix> Gus_Tronador: someone just mentioned this problem half an hour ago :)
[16:51] <radix> Gus_Tronador: it should work after a couple minutes.
[16:52] <radix> Gus_Tronador: oh, and it seems to be fixed in bzr 1.5, according to conversation that just happened
[16:54] <Gus_Tronador> radix: I think it wasn't fixed in 1.5 because I'm using that version :( ... address-port remains binded for a couple of minutes
[16:54] <Gus_Tronador> radix: and after those minutes I can restart server.
[16:55] <radix> Gus_Tronador: you're using the final version of 1.5?
[16:55] <radix> maybe it's not in a release yet
[16:57] <Peng> WFM on Ubuntu with bzr.dev.
[16:57] <Peng> (I dunno if I have 1.5 installed.)
[16:58] <Peng> Well.
[16:58] <Peng> Yeah, WFM in 1.5 too.
[17:03] <ignas> hi
[17:05] <ignas> in our ssh configuration we had a limitation that people can only run "/usr/bin/svnserve -t"
[17:06] <ignas> what command is needed to allow them to use bzr smart server?
[17:06] <fullermd> bzr server [some args]
[17:06] <fullermd> Er, 'serve'.
[17:07] <ignas> "serve" ?
[17:07] <ignas> it starts the bzr server
[17:07] <ignas> i am talking about bzr+ssh://
[17:07] <fullermd> Same thing.
[17:07] <fullermd> It uses serve --inet [various others...   --allow-writes at least, --directory=/ maybe?  Not sure]
[17:08] <Peng> Yeah, --directory / is among them.
[17:08] <ignas> so i just edit .ssh/authorized_keys
[17:08] <gour> i need some help (in order to provide bzr completion for fish shell) how is bzr help formatted, i.e. in string "-v, --verbose        Display more information."
[17:08] <ignas> and add "bzr serve --directory=/ --allow-writes" there
[17:09] <gour> ...space is used between short & long option, but what about long option and description?
[17:09] <Peng> ignas: Don't forget --inet.
[17:15] <james_w> gour: have you seen "bzr shell-complete"?
[17:16] <gour> james_w: no, i'm figuring out where and how are helo topics generated
[17:18] <gour> james_w: shell-complete misses descriptions
[17:19] <gour> james_w: see http://rafb.net/p/7k94LV34.html - this is the fish (shell) function which generates tab completion for several (D)VCSs, bzr is missing :-(
[17:19] <gour> hg is covered with case '*'
[17:54] <meuserj> getting a weird error doing a bzr status on a branch on an NFS mount:
[17:54] <meuserj> /usr/lib/python2.5/site-packages/bzrlib/dirstate.py:237: DeprecationWarning: struct integer overflow masking is deprecated
[17:54] <meuserj>   , st.st_dev, st.st_ino & 0xFFFFFFFF, st.st_mode))[:-1]
[18:11] <Laney> Can I cherry-pick changes to commit?
[18:44] <demod> Laney: iirc the record plugin can do that
[18:44] <Laney> demod: I found bzr shelve, looks to do what I want
[18:45] <demod> Laney: kk
[18:45] <demod> hm, it was the interactive-plugin anyway... ,)
[19:01] <vila> lifeless: ping, loom breaks the bzr test suite (6 test failing related to push), should I file a bug ?
[19:09] <lifeless> vila: sure
[19:11] <vila> lifeless: damn, I was hoping you would have say: "Holly cow! I'll fix that right *now*" ;-)
[19:18] <lifeless> vila: I'm fixing 'why does gdm not list latin as a language even though I clicked on latin int he various gui thingys'
[19:28] <vila> lifeless: gee
[19:32] <beuno> abentley, ok, after a few hours of cursing, I've got the SQL to create the tables in MySQL, and, a problem while importing the bzr DB, due to single quotes in BLOBs
[19:33] <abentley> Yeah, that's the kind of thing I ran into with that approach.
[19:33] <beuno> I'll have to look into other ways of exporting data from sqlite, but I've got a reproducible list of changes to the sqlite dump that make it "mysql-importable"
[19:33] <lifeless> vila: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/234101
[19:35] <beuno> abentley, I'm going to get some work done, and try a different approach
[19:37] <pickscrape> I went though a lot of pain moving our trac installation from SQLite to Postgres because of string quoting issues
[19:38] <pickscrape> Shortly after I muddled through it myself, they released an offical migration script
[19:38] <pickscrape> Could be of use to you if you want to have a look at the code: http://trac-hacks.org/wiki/SqliteToPgScript
[19:39] <abentley> pickscrape: Yeah, I saw that.  Unfortunately, it seemed very Trac-specific.
[19:40] <pickscrape> I'll see if I can dig out what I did.
[19:42] <lifeless> vila: and https://bugs.edge.launchpad.net/ubuntu/+source/langpack-locales/+bug/234105
[19:50] <pickscrape> Bad pickscrape. I can't have version controlled it. Shame: there was all sorts of clever shellery involved. :(
[19:55] <vila> lifeless: regarding bug #234105 are you sure latins had telephone ???
[19:56] <lifeless> vila: see my comment re accuracy :)
[19:56] <vila> I saw it :)
[19:58] <vila> lifeless: regarding loom, is there a reason for record to not be part of commit ?
[19:59] <vila> I'm still unclear on when I should record...
[20:00] <jam> jelmer, statik: ping
[20:00] <jelmer> jam: hi
[20:01] <statik> jam: hi! any chance you can host this week? I'm not able to punch a hole in the router for gobby here
[20:02] <jam> jelmer: are you available on skype?
[20:02] <lifeless> vila: yes, they are orthogonal operations, commit and record are definitely different
[20:02] <jam> statik: I'll give it a shot
[20:02] <lifeless> vila: you should record before you push
[20:03] <jelmer> jam: yep, let me see if I can find a headset of some sort
[20:03] <vila> the use case I have which seems broken is: bzr merge --uncommitted
[20:03] <jelmer> jam: my skype name is jvernooij
[20:05] <vila> lifeless: I use that when hacking on one "slow" machine and running the tests on a faster one
[20:05] <jelmer> jam: one sec
[20:05] <jam> jelmer: np
[20:06] <vila> well, more precisely I do: bzr revert --no-backup; bzr pull; bzr merge --uncommitted (on the faster machine)
[20:07] <lifeless> jam: whats 'notification' as opposed to the thing I wrote for bzr-gtk ?
[20:07] <jam> lifeless: ask statik
[20:08] <lifeless> statik: ^
[20:09] <statik> lifeless: it just pops a notify_send bubble when a push or pull completes
[20:10] <statik> notify-send even
[20:10] <lifeless> statik: thats what the bzr-gtk commit-notify does
[20:10] <statik> lifeless: cool
[20:10] <lifeless> statik: I am smelling wheel reinvention :)
[20:10] <statik> lifeless: i will have to check out commit-notify
[20:11] <statik> the other one doesn't require me to do anything, I must need to do something to turn on commit-notify
[20:11] <jam> jelmer: are you ready yet?
[20:13] <lifeless> statik: you just run it, or set it on in the bzr-gtk prefs (though they seem somewhat borked at the moment)
[20:13] <lifeless> statik: jelmer knows all about it, ask while you are on the phone
[20:13] <lifeless> statik: it listens on dbus and can tell you about commits from other machines on your network if lan-notify is also running
[20:14] <jam> lifeless: from what statik said, it also notifies you when a push/pull finishes
[20:14] <jam> so you can start it, and switch your focus
[20:14] <jam> and it will pop up when it is done
[20:14] <jelmer> jam: almost - couldn't find a headset but I'm just going to use an external mike
[20:14] <jam> jelmer: np
[20:15] <lifeless> jam: commit-notify hooks on set_rh
[20:15] <jam> lifeless: which doesn't trigger anymore :)
[20:16] <jelmer> jam: Ok, I'm ready
[20:16] <lifeless> jam: so modulo the obvious trivial update, which belongs in bzr-dbus, it sounds identical
[20:16] <jam> lifeless: sounds similar to me, too
[20:16] <lifeless> jam: (except commit-notify is devcoupled, yada yada yada
[20:16] <jam> I don't use either
[20:17] <statik> lifeless: sounds very cool, i should switch :)
[20:23] <lifeless> elmo: https://pqm.bazaar-vcs.org/ errors now?
[20:34] <LaserJock> any LP bzr people about? I'm wondering what happened to the gchemutils vcsimport
[20:35] <LaserJock> as a related question, can cvsps import only a part of the history?
[20:40] <hersonls> where a found documentation for loggerhead?
[20:58] <lifeless> night all
[21:05] <mtaylor> hey guys - what's the reasoning behind having bzr branch not set a default push location ?
[21:05] <mtaylor> or rather, having bzr push not default to using the parent location?
[21:08] <Jc2k> 90% of the times i've branched in bzr i've not pushed back to the parent
[21:09] <Jc2k> (not a reason, just what i've found as a user)
[21:11] <beuno> that's odd, it's the oposite with me, 90% of the times I push back to parent
[21:12] <beuno> but I guess that's the beauty of DVCS
[21:13] <fullermd> 90% of the time I never push anywhere   :)
[21:13] <mtaylor> hehe
[21:14] <beuno> alright, you win, we should remove push by default and make it a plugin
[21:14]  * fullermd nods.
[21:14] <fullermd> More secure that way.
[21:14] <fullermd> Really, we should do the same with 'commit'.  It's far too dangerous a tool to allow people to use willy-nilly.
[21:15] <beuno> yeah, and that should improve performance quite a bit
[21:16] <mtaylor> so I'm guessing we don't have a default push location then because, well, because that would waste resources on fullermd's machine setting it
[21:17] <beuno> yes, that sounds like a solid answer
[21:17] <mtaylor> good
[21:17] <mtaylor> as long as there is a reason
[21:18] <beuno> if IIRC, this was discussed at some point, and some good reasons given for it, finding the thread will be impossible
[21:18] <mtaylor> I figured
[21:19] <mtaylor> I'm _guessing_ it has something to do with there not really being a "default" usage pattern for this
[21:19]  * CardinalFang doesn't figure there are /good/ reasons, just reasons.
[21:19] <beuno> it sounds like something lifeless would know, but he's changed timezone
[21:19]  * mtaylor punches timezones in the face
[21:20] <fullermd> Well, I would guess there are 2 factors.
[21:20] <abentley> lifeless: I'd like to talk about looms.
[21:20] <fullermd> One is that having the parent loc and push loc being the same is definitely a non-starter; there are vhastly many cases where that would be useless.
[21:20] <fullermd> And the other is that the more you increase the number of "X uses the Y location, except if that's not set, then it defaults to Z" cases, the more confusing everything gets.
[21:20] <CardinalFang> Different is fine.  Defaults, though?
[21:21] <fullermd> (some might say we're already too far in that pit)
[21:21] <beuno> mtaylor, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/37064/match=default+push+location
[21:22] <beuno> I could never understand how to navigate through gmane, but that's the thread
[21:23] <mtaylor> beuno: great. that's a good summation I think
[21:23] <mtaylor> CardinalFang: see above link
[21:47] <jam> beuno: click on the "subject" link: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/37041/focus=37064
[21:48] <beuno> jam, aaaaaaaah, yes, thank you  :)
[22:37] <mwhudson> morning
[22:50] <beuno> mornin' mwhudson
[22:50] <tolstoy> Folks: I just installed bzr 1.4 (via the Mac OS installer) and I get a bzrlib problem. Anyone familiar with this?
[22:51] <tolstoy> bzr: WARNING: bzrlib version doesn't match the bzr program.
[22:51] <tolstoy> This may indicate an installation problem.
[22:51] <tolstoy> bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 4, 0, 'final', 0)
[22:51] <mwhudson> tolstoy: i did that yesterday, worked fine
[22:51] <tolstoy> Did you install over the top of the bzr 1.3 installation?
[22:51] <tolstoy> Might that be an issue?
[22:51] <mwhudson> no, it was a clean install
[22:52] <mwhudson> it indeed might be the issue
[22:52] <tolstoy> Hm. I wonder if there are any uninstall instructions.
[22:52] <mwhudson> tolstoy: what does `which bzr` say?
[22:52] <tolstoy>  /usr/bin/bzr
[22:52] <mwhudson> it sounds like you're getting the right bzrlib but possibly the wrong bzr script
[22:52] <mwhudson> tolstoy: is there a /usr/local/bin/bzr as well?
[22:53] <tolstoy> Yep. That's the issue.
[22:53] <tolstoy> the /usr/bin/bzr has a _script_version_ of 1 3 0 (or something like that).
[22:53] <tolstoy> I guess I can just delete it, but.... eek. ;)
[22:53] <fullermd> Well, that's why it does the version checking   ;)
[22:54] <tolstoy> Yep. Well, thanks for the help!
[22:55] <tolstoy> I've re-arranged my path to prefer /usr/local/bin, at least for now.
[22:59] <mwhudson> i would /guess/ that this was really a bug in the old installer
[22:59] <mwhudson> it shouldn't really have been putting files in /usr/bin, that's naughty