[00:35] <dvheumen> Hi, just a quick question, is there and if so what is the difference between having a branch and doing a commit and having a checkout and doing a local commit?
[00:37] <cody-somerville> If you do a checkout and do a local commit, it doesn't push to the server.
[00:38] <dvheumen> true, but if you branch from a server and do a commit then it also doesn't push to the server
[00:38] <dvheumen> so that behavior doesn't seem so different (except from the default action)
[00:39] <cody-somerville> dvheumen, yup.
[00:41] <dvheumen> so the choice depends mostly on what you would like to do most of the time? If you'd like to work mostly centralized (for example at the office) then you'd do a checkout and when you're on the plane temporarily commit locally. And if you would like to work decentralized you'd branch and commit (locally) and only push once the piece is done
[00:44] <cody-somerville> yup
[00:44] <cody-somerville> There is a guide on the wiki for more info.
[00:45] <dvheumen> Yeah I know, the problem is that the small differences between a branch, a checkout and a repository aren't that clearly described
[00:45] <dvheumen> ow wait... on the wiki you say... I'm actually talking about the documentation on the website
[00:46] <dvheumen> the reference guide and such
[00:47] <dvheumen> ah, the website is a wiki, so now we're talking about the same thing again :P
[00:49] <dvheumen> anyways, thanks again, that was all I needed to know :P
[01:31] <Mecha25> anybody know why my bazaar.launchpad.net page has gotten my committed revisions and my code.launchpad.net page hasn't?  it's been over an hour since I pushed it
[01:34] <Mecha25> hello?
[01:37] <Mecha25> 113 people everywhere and not a voice is heard
[01:44] <Mecha25> anybody out there?
[01:49] <Odd_Bloke> ubottu: weekend
[01:49] <Odd_Bloke> Mecha25: ^
[01:49] <Mecha25> hey, finally somebody
[01:49] <Mecha25> cool
[01:49] <Odd_Bloke> Mecha25: I don't know, #launchpad is a better bet.
[01:49] <Mecha25> thanks
[03:35] <jelmer> kiorky, pong
[04:03] <jelmer> hmm
[08:18] <kiorky> jelmer: yep
[08:35]  * Yurim nods.
[10:09] <kiorky> with shared repository, do  the branches isinde the repo have .bzr directories?
[10:09] <kiorky> I have understood the contrary with http://bazaar-vcs.org/SharedRepositoryTutorial
[10:11] <lifeless> Keltia: they have .bzr directories, but the .bzr for each branch only has 'branch' not 'branch and repository'
[10:11] <kiorky> ok
[10:12] <kiorky> lifeless: do you know the status of nested trees support
[10:12] <kiorky> i didnt find much doc on it
[10:12] <kiorky> it seems to be implemented since .15rc1
[10:12] <lifeless> I believe it is beta quality in larsiq's branch
[10:12] <lifeless> core capabilities are done in the code base but not the UI
[10:12] <kiorky> not in bzr.dev or one of the 1.6 beta's ?
[10:13] <lifeless> no changes have been made to nesting uspport recently :(
[10:13] <lifeless> I must go - breakfast awaits
[10:13] <kiorky> have fun :)
[12:44] <scippio> hello
[12:45] <scippio> I have a problem with bazaar via webdav
[12:45] <scippio> bzr: ERROR: Unsupported protocol for url "http+webdav://scippio:pass@repo.example.com/bbb"
[12:46] <scippio> :-/
[12:55] <Odd_Bloke> scippio: Are you trying to use the webdav plugin?
[12:55] <pygi> isn't webdav plugin a bit broken atm?
[12:55] <scippio> Odd_Bloke: yes .. i have this plugin
[12:56] <Odd_Bloke> pygi: vila's fixed it up recently.
[12:56] <pygi> while I have no idea who that is, good news
[12:56] <Odd_Bloke> scippio: What version of bzr are you using?
[12:57] <scippio> Odd_Bloke: 1.5
[12:57] <Odd_Bloke> scippio: Ah, the webdav plugin requires 1.6.
[12:58] <Odd_Bloke> That said, the only reason for that is that vila hasn't tested it with 1.5 enough.
[12:58] <scippio> Odd_Bloke: hmm ... ok I  trying it... thanks
[12:59] <Odd_Bloke> scippio: You could try just editing the requirements in the plugin and see if it'll work with 1.5.
[13:02]  * Odd_Bloke --> breakfast
[13:08] <scippio> Odd_Bloke: hmm and where is the version in webdav plugin?
[13:28] <scippio> Odd_Bloke: hmm still unsupported protocol on 1.6b3
[13:28] <bob2> bzr selftest bzrlib.plugins.webdav
[13:29] <bob2> maybe just 'bzr plugins' will show if it is installed or not
[13:29] <scippio> webdav plugin is installed ok
[13:30] <scippio> [scippio@jerry bzr]$ bzr plugins
[13:30] <scippio> launchpad  Launchpad.net integration plugin for Bazaar.
[13:30] <scippio> webdav  Implementation of WebDAV for http transports.
[13:34] <scippio> hmm ... webdav plugin is unusable :(    i must use ftp :/
[14:18] <Odd_Bloke> scippio: Did you try running 'bzr selftest bzrlib.plugins.webdav'?
[14:18] <scippio> yes
[14:18] <Odd_Bloke> What was the outcome?
[14:18] <scippio> [scippio@jerry bzr]$ bzr selftest bzrlib.plugins.webdav
[14:18] <scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
[14:18] <scippio> ----------------------------------------------------------------------
[14:18] <scippio> Ran 0 tests in 0.001s
[14:18] <scippio> OK
[14:19] <scippio> tests passed
[14:20] <Odd_Bloke> OK, that suggests you don't have the plugin installed correctly, as I get 11 tests running.
[14:20] <scippio> hmm
[14:21] <Odd_Bloke> Wait, when and from where did you get the webdav plugin?
[14:22] <scippio> from launchpad ..
[14:22] <scippio> but maybe i install bad ....
[14:22] <scippio> its my first plugin ..
[14:22] <Odd_Bloke> OK, I get a different string in 'bzr plugins'.
[14:22] <scippio> first: bzr branch lp:bzr.webdav
[14:23] <scippio> second: i copy webdav.py to .bazaar/plugins/
[14:23] <Odd_Bloke> scippio: Ah, no, you want the entire directory in ~/.bazaar/plugins/.
[14:23] <Odd_Bloke> So 'bzr branch lp:bzr.webdav ~/.bazaar/plugins/webdav'.
[14:23] <scippio> i mean ~/.bazaar/plugins/
[14:24] <scippio>  ~/.bazaar/plugins/webdav.py
[14:25] <Odd_Bloke> Yeah, you want the entire directory which it branches in there.
[14:25] <scippio> i have it in
[14:26] <Odd_Bloke> OK, try running 'bzr selftest webdav'.
[14:26] <scippio> [scippio@jerry plugins]$ bzr selftest webdav
[14:26] <scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
[14:26] <scippio> ----------------------------------------------------------------------
[14:26] <scippio> Ran 0 tests in 0.001s
[14:26] <scippio> OK
[14:26] <scippio> tests passed
[14:26] <scippio> [scippio@jerry plugins]$ ls /home/scippio/.bazaar/plugins/
[14:26] <scippio> webdav.py  webdav.pyc
[14:27] <Odd_Bloke> OK, remove both of those files.
[14:27] <Odd_Bloke> And run 'bzr branch lp:bzr.webdav ~/.bazaar/plugins/webdav'.
[14:29] <scippio> [scippio@jerry plugins]$ ls ~/.bazaar/plugins/webdav
[14:29] <scippio> __init__.py  NOTES  setup.py  tests  TODO  webdav.py
[14:30] <Odd_Bloke> OK, now try running 'bzr selftest webdav'.
[14:30] <scippio> yes
[14:30] <scippio> [scippio@jerry plugins]$ bzr selftest webdav
[14:30] <scippio> testing: /usr/bin/bzr /usr/lib/python2.5/site-packages/bzrlib (1.6b3 python2.5.2)
[14:30] <scippio> ----------------------------------------------------------------------
[14:30] <scippio> Ran 11 tests in 0.074s
[14:30] <scippio> OK
[14:30] <scippio> tests passed
[14:30] <Odd_Bloke> OK, now try using it for whatever you were trying to use it for before.
[14:31] <scippio> excellent!
[14:31] <scippio> Odd_Bloke: thank you!
[14:32] <scippio> :)
[14:32] <Odd_Bloke> scippio: Glad I could help. :)
[16:08] <kiorky> uhm, in bzr world, what's the tip or head equivalent to designate the most up to date revision ? last:1 , isnt it ?
[16:09] <Odd_Bloke> kiorky: In what context?
[16:10] <kiorky> Odd_Bloke: i want to get the head 'explicitly' from a bzr repo, so -r last:1 seems nice
[16:12] <Odd_Bloke> kiorky: -r-1 also works.
[16:13] <kiorky> ok
[16:22] <Peng_> -N is exactly equivalent to last:N, right?
[16:22] <luks> yes
[18:09] <kiorky> jelmer: so finnaly, i got it working, nice work !
[18:10] <kiorky> jelmer: i may submit you a patch for compilation stuff when you didnt install your things in standart locations
[18:11] <kiorky> jelmer: i would be interrested to know more on the problems with server side subversion server < 1.5 and the properties that bzr sets up. I ve read somewhere that it can be problematic. Because on our production server, the svn is pretty old (1.3 i think, the one on debian stable)
[18:12] <kiorky> jelmer: uhm 1.4, but with have some repo on a sarge server, so it's 1.1 :p
[18:52] <j1mc> hi all - just a quick question.  will 'bzr uncommit -r 3686' revert the branch to version 3686, or will it revert 3686 revisions?  i would prefer the former.
[18:52] <nevans> upgrading to bzr 1.6beta3... what's the safest branch of bzr-svn to use?
[18:53] <nevans> j1mc,  bzr revert -r 3686 will do what you want, IIRC
[18:53] <j1mc> nevans: thanks
[18:53] <nevans> actually...
[18:53] <nevans> uncommit might also do it...
[18:55] <Peng_> uncommit doesn't revert the working tree.
[18:55] <Peng_> j1mc: Bazaar's -r arguments always do the same thing.
[18:56] <nevans> Peng, thanks... I knew there was an important distinction
[18:57] <j1mc> Peng_: what would i want to use then if i wanted to revert the working tree?
[18:57] <Peng_> j1mc: Um, what do you want to do? Remove revisions from your history or revert the working tree?
[18:57] <radix> j1mc: if you want to actually delete the history from the branch, then do "bzr uncommit -r X; bzr revert". If you just want to bring the working tree to the state that it was at a particular revision, use "bzr revert -r X".
[18:57] <j1mc> basically, i pushed a small change up to LP, but had an error in it, and just want to revert the change up on LP to the prior revision.
[18:58] <radix> j1mc: the difference is whether you want to delete it from history, or add a new revision which brings it back to the old state.
[18:58] <j1mc> delete it from the history
[18:58] <radix> then use uncommit
[18:58] <j1mc> thanks
[18:59] <Peng_> j1mc: You should just fix it and make a new commit.
[20:05] <techII> i want to use bzr with a huge svn repository, but i don't want to wait for the history to download, any suggestions?
[20:06] <Peng_> Time machine?
[20:07] <Peng_> BTW, be careful. Unless you're using a dev version of bzr-svn and/or svn 1.5, it'll probably leak massive amounts of RAM.
[20:31] <uws> techII: checkout perhaps?
[20:31] <uws> techII: or wait ;)  (my webkit conversion took ~2 days)
[20:42] <techII> ok, i need something between a lightweight and regular checkout/branch, that only has a partial history of a project, but can be branched from without going over the network
[20:47] <uws> techII: Yeah, I would like that as well
[20:47] <uws> techII: e.g. lightweigh checkout that caches all history ever requested from te master branch
[20:48] <Peng_> That'll be a large portion of the history...
[20:49] <uws> Peng_: Well, just the diffs you requested, and subsequent updates after the initial branching
[21:00] <lifeless> uws: have you tried the new rebase ?
[21:00] <uws> lifeless: I tried your branch from the bug report but it requires bzr > 1.5
[21:03] <Odd_Bloke> techII: Stacked branches are on their way, which allow you to only download the history you need.
[21:03] <Odd_Bloke> techII: I'm not sure of their exact status though.
[21:05] <Peng_> "Merged into bzr.dev"?
[21:05] <Peng_> They require the development1 format though.
[21:05] <Odd_Bloke> Most of it is, but I don't know if everything is there.
[21:06] <Peng_> Main thing, policies, docs. That's definitely most of it, but I don't know if it's all either.
[21:06] <Odd_Bloke> techII: Basically, that use case should be fully supported in 1.7 (I think).
[21:07] <uws> btw, is bzr's on disk format roughly the same size as git's on disk format?
[21:07] <uws> (with rich root pack)
[21:07] <Peng_> uws: No.
[21:07] <Peng_> There's currently work on making indexes much smaller, and I'm sure there will be other stuff next.
[21:08] <Peng_> Repo size benchmarks are complicated. Git, hg and bzr are all good enough, IMO.
[21:14] <lifeless> uws: yes it does
[21:15] <lifeless> uws: by default bzr is smaller than git, but common wisdom amongst git users is to run a 'repack' with large window and depth, and that makes it smaller than bzr
[21:15] <lifeless> uws: like Peng_ says though, we have a better compressor on the way
[21:15] <uws> lifeless: does it have impact on read performance?
[21:16] <lifeless> the new compressor? untuned its about the same
[21:16] <uws> lifeless: no, the repacking and window size
[21:17] <lifeless> its complex :) - depends on the operation etc.
[21:17] <uws> diff and log lookups are the most common methinks
[21:17] <lifeless> however, git is gast either way (speed is not a problem of git) (well, except http pulls perhaps but that doesn't affect most users)
[21:18] <Peng_> lifeless: What do you think of xdelta?
[21:19] <lifeless> uws: could you try rebase with 1.6b3 ? I'd like to know that I've fixed the bug and I don't have enough info to be completely sure...
[21:19] <lifeless> Peng_: good, I may end up using it for groupcompress, if I can. But I suspect i can't
[21:19] <Peng_> Why can't you?
[21:20] <lifeless> for performance I need to preserve compressor state as additional documents are added
[21:20] <lifeless> its a streaming compressor like e.g. gzip
[21:21] <lifeless> xdelta is a binary compressor - 2 in, one out
[21:21] <uws> lifeless: will do, but not now. will have to wait for a bunch of commits on webkit.trunk first
[21:21] <lifeless> uws: no worries
[21:22] <lifeless> uws: let me know if its not snappy and I'll look at it more. I'll need another callgrind naturally.
[21:22] <Peng_> lifeless: Oh.
[21:23] <lifeless> Peng_: so if xdelta's interface is suitable I will be able to essentially [ab]use it, but if its not I'd need a custom version
[21:24] <uws> lifeless: sure
[21:27] <lifeless> uws: thanks
[21:29] <Peng_> lifeless: Well, good luck. :)
[21:30] <uws> lifeless: are you the bzr marketeer these days? ;)
[21:30] <lifeless> uws: I think igc has a much better marketing feel than I :)
[21:31] <lifeless> uws: I'm happiest doing deep hacking or understanding user issues :)
[21:31] <uws> lifeless: your conversations sound like salesmen buzzword technobabble, in which everything is possible
[21:31] <lifeless> uws: LOL
[21:31] <uws> but in your case most things are actually real
[21:31] <Jc2k> lifeless: i have a technical question :-)
[21:31] <lifeless> Jc2k: shoot
[21:31] <lifeless> Jc2k: also, are you still hung over ? :)
[21:31] <uws> like "what does gnome need?"  [xyz]  "ok, will fix it"
[21:32] <Jc2k> lifeless: there was no drinking for me, i came home after my talk
[21:32] <Jc2k> :(
[21:32] <lifeless> uws: well zeenix had some that were trickier - largely about the fact we use python AFAICT
[21:32] <lifeless> Jc2k: shame; I would have bought you a beer or something :)
[21:32] <Jc2k> lifeless: hehe
[21:32] <Jc2k> how much longer are you in the UK?
[21:33] <Jc2k> anyway, nzjrs (conduit dev) has been trying to get started with the playground
[21:33] <Jc2k> he has a branch in jstowers/conduit/devel
[21:33] <lifeless> Jc2k: I fly out tomorrow
[21:33] <lifeless> ok
[21:33] <Jc2k> he's trying to merge in http://johnstowers.co.nz/bzr/conduit-gio/
[21:34] <Jc2k> he encounters fail
[21:34] <Jc2k> about things been missing
[21:34] <lifeless> pastebin ?
[21:35] <Jc2k> one sec while i recreate :p
[21:35] <Jc2k> http://pastebin.com/d38d71f4d
[21:36] <Jc2k> he tried to create a bundle, but that seems to refer to a local branch so its useless to me
[21:36] <lifeless> ah
[21:36] <lifeless> so two tings
[21:36] <lifeless> the send ui seems to confuse people
[21:36] <lifeless> jam and I are discussing with abentley how to tackel that
[21:36] <lifeless> basically you want to bundle against trunk always, then it refers to a branch people have in common
[21:37] <Jc2k> i suspected his bundle was just fail, aye
[21:37] <Jc2k> but im not sure why the merge is fail
[21:38] <lifeless> that looks like he is missing data?!
[21:38] <lifeless> bzr check <URL> going now
[21:40] <lifeless> deifnitely
[21:40] <lifeless> robertc@lifeless-64:/tmp$ bzr branch http://johnstowers.co.nz/bzr/conduit-gio/
[21:40] <lifeless> bzr: ERROR: Revision {john.stowers@gmail.com-20080607075424-nebves9oo6tiry7z} not present in "1252@1811c9d2-c306-0410-a128-ae57aa55c946:trunk:conduit%2Fmodules%2FGoogleModule%2Fgdata%2Fmedia".
[21:40] <lifeless> I'd like to know his bash history, did he rsync things around, that sort of thing
[21:41] <lifeless> basically, its 'missing ref'
[21:41] <Jc2k> he's in NZ so when you are synced back to local time correctly you'll be better set to talk to him :)
[21:42] <lifeless> its 8:40am for him
[21:42] <lifeless> but yes
[21:42] <Jc2k> he has no online presence right now :)
[21:42] <Jc2k> but i'll tell him to get his butt in here with his bash history
[21:43] <lifeless> k
[21:43] <Jc2k> i know that he's encountered stuff like this before and his solution is to bundle and merge it into a fresh branch
[21:50] <nekohayo> hey there, could someone try using http://ecchi.ca:8000/spec-merge/specto-ULTIMATEMERGE/ as a base, and bzr replay http://ecchi.ca:8000/spec-merge/specto-woutcR2/ from revision 2?
[21:50] <nekohayo> it does not seem to work on my end
[21:50] <nekohayo> even though the contents are strictly equal
[21:59] <lifeless> nekohayo: hi
[21:59] <nekohayo> hoy lifeless
[21:59] <lifeless> nekohayo: what you say doesn't work, what do you mean?
[21:59] <nekohayo> hmm lemme try
[22:00] <nekohayo> lifeless: 16 conflicts encountered.
[22:00] <nekohayo> but I shouldn't have any conflicts, the contents are exactly equal, no?
[22:02] <lifeless> well, replay applies patches
[22:02] <lifeless> so you can have conflicts yes
[22:02] <lifeless> but I'm pulling it now
[22:05] <nekohayo> lifeless: because the goal is simply to stitch the history of those two branches together
[22:06] <lifeless> nekohayo: es, I assumed so
[22:06] <nekohayo> lifeless: oops, I think the specto-woutcR2 branch is the wrong one though
[22:06] <lifeless> nekohayo: they have no common history at all
[22:07] <nekohayo> wait a sec
[22:07] <lifeless> heh, not even same repository type :)
[22:08] <nekohayo> lifeless: http://ecchi.ca:8000/spec-merge/specto-woutc/ is the one, not specto-woutcR2
[22:12] <nekohayo> lifeless: so if I try to replay from -r2.. , I get 16 conflicts. If I try from -r3.. , I get 28 conflicts!
[22:13] <lifeless> nekohayo:  bzr merge ../specto-ULTIMATEMERGE/
[22:13] <lifeless> bzr: ERROR: Repository KnitRepository('file:///tmp/specto-woutc/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///tmp/specto-ULTIMATEMERGE/.bzr/repository/')
[22:13] <nekohayo> lifeless: are you using bzr 1.5?
[22:13] <nekohayo> but I'm not using "merge" here, but "replay"
[22:14] <lifeless> nekohayo: 1.6b3  :) Point is you have apparently disconnected branches
[22:14] <lifeless> nekohayo: one is from svn
[22:14] <lifeless> nekohayo: one is from a local import
[22:14] <nekohayo> yeah they are. that's why I'm trying to use replay?
[22:14] <nekohayo> yeah
[22:14] <lifeless> nekohayo: replay works on file ids - the inode abstraction
[22:14] <nekohayo> but the code is the same, darnit
[22:15] <lifeless> nekohayo: the conflicts you are getting is because bzr *thinks* the files are different files with conflicting file names
[22:15] <nekohayo> so what if I replay, bzr resolve, and then.. uh what would happen?
[22:15] <nekohayo> and should the replay be done starting at revision 2, or 3?
[22:16] <lifeless> if you replay, resolve, commit, replay the next one etc; when you are done you should be able to continue forward
[22:16] <nekohayo> the contents from "ultimatemerge" last revision [22:16] <lifeless> then you would start from 3
[22:16] <lifeless> but I have a suggestion for you
[22:16] <nekohayo> ... I need to do that for ~80 revisions?!
[22:16] <nekohayo> o_o
[22:16] <lifeless> replay it a bit more by hand :(
[22:16] <lifeless> bzr branch ULTIMEATEMERGE working
[22:16] <lifeless> cd working
[22:17] <lifeless> bzr diff ../specto-woutc -r 2..3 | bzr patch
[22:17] <lifeless> bzr commit
[22:17] <lifeless> (and copy log message)
[22:17] <nekohayo> x_x
[22:18] <lifeless> its a bug that we don't have a good conflict resolver for file-path conflicts; it makes the particular pattern of use that you have made frustrating
[22:18] <lifeless> you could try http://spacepants.org/src/bzrgraft/
[22:18] <lifeless> but AIUI its not up to date with current bzr
[22:18] <nekohayo> well yeah, it kind of depresses me that bazaar is claimed to be smarter with merges or even stitching history
[22:19] <nekohayo> when in the end it comes down to manually committing everything o_o
[22:19] <lifeless> nekohayo: why did you start a new branch ?
[22:19] <nekohayo> it wasn't me :(
[22:19] <lifeless> (as in from-scratch, rather than branching from svn in the first place ?)
[22:19] <lifeless> oh
[22:22] <nekohayo> aw shoot, it's a shame graft is unmaintained
[23:01] <kiorky> yo
[23:01] <kiorky> when doing bzr branch foo bar
[23:01] <kiorky> i think i dont understand something
[23:01] <kiorky> when i do local changes/commits, then i want to push back my things
[23:02] <kiorky> why do i need to precise the "from location" again the first time and bzr do not remember it ?
[23:05] <Odd_Bloke> kiorky: Because it's fairly rare that a user will want to push back to the location from which they branched.
[23:05] <mwhudson> kiorky: it does, or at least should, remember
[23:05] <lifeless> gnight all
[23:05] <bob2> 'night
[23:05] <kiorky> mwhudson: the first time, i need to precise agi the from location, after that it remembers
[23:05] <bob2> perhaps push should default to the parent if a push location isn't set
[23:06] <kiorky> bob2: 'xactl
[23:06] <kiorky> bob2: 'xactly
[23:06] <kiorky> this behaviours seems natural for me
[23:09] <Odd_Bloke> Again, often it's not what people intend to do.  If you've branched from a trunk which you can push to, you don't necessarily want to push to it when you forget that you haven't specified the correct location yet.
[23:11] <Odd_Bloke> For example, I do "bzr branch pqm.dev foo", *HACK*, 'bzr push bzr+ssh://me@there.com/bzr/foo' so people can access my changes.  I wouldn't want my changes pushed to pqm.dev by accident, because that will affect other people (theoretically).
[23:19] <kiorky> Odd_Bloke: thats the default on many dvcs :p, just an habit
[23:22] <MatthewWilkes> Hey, is there a record for longest time spent trying to install bzr-svn?  Just wondering how much longer I have to take before I get my certificate
[23:33] <Odd_Bloke> MatthewWilkes: What problems are you having?
[23:33] <thumper> MatthewWilkes: :)
[23:40] <MatthewWilkes> Odd_Bloke: Using OSX, svn 1.4.5 managed with macports.  Trying to get to a version that bzr-svn supports is proving very difficult, I don't care enough about wanting to try bzr to replace my system python, subversion and py-svn, then patch setup tools as macports wants me to, so trying to muddle though doing part of it
[23:41] <mwhudson> oh os x
[23:41] <mwhudson> install ubuntu in parallels, use that
[23:41] <mwhudson> (only about half joking)
[23:42] <MatthewWilkes> mwhudson: I have ubuntu in a vm, and I could play there, but then that would be all I ever did with bzr
[23:43] <mwhudson> MatthewWilkes: you could just do the bzr-svn requiring stuff in the vm
[23:43] <Ng> 139
[23:43] <kiorky> jelmer: why does svn+http://s cache my credentials but https:// does not ?
[23:43] <Ng> bah
[23:43] <kiorky> jelmer: i mean the svn credentials
[23:43] <mwhudson> if you push from the vm to your os x install, you can use that there without bzr-svn, then push back to the vm so you can push back to bzr-svn
[23:43] <mwhudson> MatthewWilkes: not ideal, obviously
[23:43] <mwhudson> are there svn 1.5 os x binaries yet?
[23:44] <MatthewWilkes> mwhudson: Everything would require it, I'm in a company infrastructure that only supports svn, and it will only ever support svn unless it becomes easy
[23:44] <mwhudson> Ng: hi :)
[23:44] <Verterok> MatthewWilkes: Hi, I'm using bzr-svn on OS X (10.4), tell me if I can give you a hand to get it working :)
[23:44] <kiorky> MatthewWilkes:  show bundlebuggy to your workmates
[23:44] <Ng> mwhudson: hey :)
[23:45] <MatthewWilkes> Verterok: Thanks, how are you managing svn?
[23:46] <Verterok> MatthewWilkes: I'm using the DMG from collabnet, but I think the macports version should be fine
[23:47] <MatthewWilkes> kiorky: If the features were all that mattered, no problem, but if it doesn't work, it's useless
[23:47] <Peng_> You only have to convert everyone from svn once. Then it won't be an issue anymore! :D

[23:48] <pygi> MatthewWilkes, you mean unless hosting bzr branches becomes easy? :p
[23:49] <Verterok> MatthewWilkes: and bzr-svn trunk (0.4.11)
[23:49] <MatthewWilkes> pygi: No, I mean working with all the other repositories people have to deal with ;)
[23:49] <pygi> MatthewWilkes, aha, ok, sorry :P
[23:49]  * pygi just plugged himself in, so :)
[23:49]  * MatthewWilkes knows of 1 bzr formatted repository that houses code relevant to his work