[00:00] <thumper> morning bzr dudes
[00:05] <igc> morning all
[00:52] <jelmer> jam-laptop: there's no guarantee though that a revision with multiple parents contains only merges
[00:52] <lifeless> jelmer: what do you mean?
[00:53] <jelmer> lifeless: we were talking about rebasing "merge revisions"
[00:53] <jelmer> and how you could skip them during rebase if the rhs parent has already been merged in the branch you're rebasing
[00:54] <lifeless> jam-laptop: ping
[00:54] <lifeless> jelmer: surely its a topo sort of the revisions and rebase them all; merges too
[00:56] <jelmer> lifeless: rebasing a commit with a rhs parent that has already been merged is most likely going to cause conflicts
[00:57] <jelmer> https://bugs.edge.launchpad.net/bzr-rebase/+bug/126743
[01:05] <ubotu> New bug: #154119 in bzr "Repository.item_keys_introduced_by should not lock Repository" [Medium,Triaged] https://launchpad.net/bugs/154119
[01:41] <ubotu> New bug: #154129 in bzr "pack does not optimise layout" [Undecided,New] https://launchpad.net/bugs/154129
[01:59] <lifeless> igc: poolie: first round of fixen pushed
[02:27] <lifeless> jam-laptop: ping
[02:41] <lifeless> hi igc
[02:41] <igc> hi lifeless
[02:42] <igc> working thru pack_repo.py today FYI
[02:55] <lifeless> cool
[02:59] <jeremy_c> will bazar launch a merge tool for me?
[03:00] <lifeless> do you mean a gui conflict-resolving tool ?
[03:01] <jeremy_c> lifeless, yes, such as Meld on Linux, or TortoiseMerge on windows?
[03:01] <lifeless>  / per-file merge tool ? e.g. meld ?
[03:01] <lifeless> Yes, there are some plugins that do this
[03:01] <jeremy_c> I'll look in the plugin section on the wiki. thanks.
[03:01] <lifeless> np
[03:45] <poolie> ok i've read the whole patch
[03:45] <poolie> i'm going to trim out the boring parts and post my comments
[03:48] <lifeless> woot
[03:48] <poolie> mm?
[03:50] <lifeless> your having read the entire patch
[03:50] <lifeless> I've just replied to all the reviews so far
[03:50] <lifeless> and actioned nearly everything I agreed with
[03:50] <lifeless> spiv: ping
[03:50] <spiv> lifeless: pong
[03:50] <lifeless> theres a gem in my patch for you
[03:50] <lifeless> insert_data_stream
[03:50] <lifeless> where ith da docstring
[03:50] <spiv> lifeless: heh, just read that a few seconds ago.
[03:51] <lifeless> i386: also where were you last night? release party one block from atlassian?
[03:51] <spiv> lifeless: I'll write one and send it to the list.  Thanks for the poke.
[03:51] <i386> lifeless: asleep!
[03:51] <larsl`> Is there a way to get 'bzr send' to use a readable patch format?
[03:52] <i386> Ive been drinking heavily for the last two weeks and Ive been kinda sick
[03:52] <lifeless> larsl`: it's got a human copy of the patch by default
[03:52] <lifeless> larsl`: if you're not seeing that, what parameters are you giving it ?
[03:52] <lifeless> i386: :(
[03:52] <lifeless> i386: we put a few back for you :O
[03:52] <larsl`> lifeless: No other copy here. I just do 'bzr send --mail-to some@address'
[03:53] <lifeless> larsl`: that should fire up your mail client
[03:53] <lifeless> larsl`: with an attached patch
[03:53] <larsl`> lifeless: It does.
[03:53] <lifeless> larsl`: the attached patch should be human readable with a base64 tail
[03:53] <larsl`> But the patch looks like a block of uuencoded something. There is no readable text.
[03:54] <lifeless> larsl`: thats strange; is this open - can you pastebin the patch for me to look at ?
[03:54] <larsl`> Sure, it's just a test.
[03:55] <larsl`> lifeless: This is the contents of the sole attachment in the mail: http://rafb.net/p/MFCGVY79.html
[03:57] <larsl`> ...oh. I need to commit locally before sending.
[03:57] <larsl`> That was just an empty patch.
[03:58] <lifeless> :)
[03:58] <lifeless> I was just finishing extracting the data to examine
[04:31]  * igc food
[05:12] <larsl`> Trying to push a branch to a FTP server, but I keep getting the error message "FTP temporary error: 451 /bzr/bzzr/.bzr/repository/inventory.knit: Append/Restart not permitted, try again. Retrying."
[05:12] <larsl`> "bzr: ERROR: exceptions.AttributeError: 'FtpTransport' object has no attribute 'get_credentials'"
[05:12] <lifeless> oh hmm
[05:12] <larsl`> It seems to do something, because there are directories added on the FTP server, but I can't checkout.
[05:13] <lifeless> Our FTP maintainer is probably asleep right now
[05:13] <lifeless> vila: ^
[05:13] <lifeless> anyhow, the knit repository format requires APPE/REST be available, and they appear to be disabled on your server.
[05:13] <larsl`> Hm.
[05:14] <lifeless> the get_credentials thing is a bug
[05:14] <lifeless> but probably only occuring as a side effect
[05:15] <larsl`> Would any of the other formats work?
[05:16] <lifeless> packs should
[05:17] <lifeless> they are currently being reviewed, should be merged later today
[05:17] <larsl`> Ah. I'm using 0.91.0 from Debian Testing.
[05:23] <abentley> lifeless: Would weaves require APPE/REST?
[05:27] <lifeless> abentley: yes, for the history file in the branch object
[05:28] <abentley> How clever of me to have removed that requirement.
[05:36] <spiv> lifeless: here's a docstring for Repository.insert_data_stream: http://rafb.net/p/9bcOyO41.html.  Any comments or should I just merge it?
[05:37] <lifeless> I think its too vague
[05:37] <lifeless> you say e.g. bencoded
[05:37] <lifeless> is it or isn't it?
[05:37] <lifeless> is it allowed to vary by repo
[05:38] <lifeless> is there a version marker?
[05:38] <lifeless> or is it self delimited by a version?
[05:38] <lifeless> why why why basically
[05:38] <spiv> lifeless: I was afraid you'd ask the hard questions :)
[05:38] <spiv> I'm not sure of the answers to a lot of them to be honest.
[05:39] <lifeless> there's a list
[05:39] <lifeless> I hear smart people subscribe to it
[05:39] <larsl`> So none of the current repository formats would work on a FTP server that doesn't allow Append/Restart?
[05:40] <spiv> I'll start a thread there, then.
[05:40] <ubotu> New bug: #154173 in bzr "pack reconcile does not correct for the fix_text_parents problem" [Undecided,New] https://launchpad.net/bugs/154173
[05:43] <lifeless> larsl`: sorry, no :(
[05:44] <larsl`> I guess there is no write support for HTTP?
[05:46] <lifeless> there is a webdav plgin
[05:46] <lifeless> plugin
[05:47] <lifeless> and there is bzr+http too
[05:47] <lifeless> there is also SFTP
[05:47] <lifeless> which is more secure than FTP
[05:48] <larsl`> Yeah, but FTP and HTTP is all I have for now.
[05:49] <larsl`> What's bzr+http? Is there any documentation for it? Google only finds code.
[05:51] <lifeless> try googling for 'serving bazaar with fastcgi'
[05:52] <larsl`> Seems to be read-only.
[05:52] <lifeless> or http://doc.bazaar-vcs.org/
[05:52] <lifeless> latest, user guide,
[05:53] <lifeless> if you set auth up, then you can make it read write
[05:54] <gotgenes> Can I create a patch just using 'bzr -r REVNO.. > mypatchfile' ?
[05:55] <lifeless> sure
[05:55] <lifeless> that will go from revno to your current tree
[05:55] <gotgenes> and then the person I send that patch to just does 'patch -p0 < mypatchfile' right?
[05:55] <larsl`> Hm. I don't think I have mod_python either.
[05:56] <lifeless> gotgenes: if they are not using bzr yes
[05:56] <gotgenes> gotgenes: they aren't
[05:56] <lifeless> gotgenes: if you and they are both using bzr you are much better off committing and using 'bzr send'
[05:56] <gotgenes> ha
[05:56] <gotgenes> lifeless: ah, that's good to know!
[07:04] <lifeless> bug 154204
[07:04] <lifeless> bug #154204
[07:06] <ubotu> Launchpad bug 154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
[07:11] <ubotu> New bug: #154204 in bzr "revision specs do not lock branches appropriately." [Critical,Triaged] https://launchpad.net/bugs/154204
[07:29] <igc> heading off a bit earlier today to catch up with some people
[07:29] <igc> might be back later tonight
[07:29] <igc> if not, have a good weekend all
[07:30] <spiv> igc: me too.  Have a good weekend.
[07:31] <igc> thanks spiv
[08:25] <vila> jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-)
[08:26] <fullermd> TZ?  You mean those things some weird people actually obey?  ;>
[08:26] <vila> fullermd: yeah, especially children you insensitive clod !
[08:27] <vila> :)
[08:27] <fullermd> Ah, you just plow a few double espressos into 'em, they'll adjust.
[08:37] <vila> fullermd: obviously you don't know my daughters, they are already too much and too often awake for our taste :)
[08:38] <vila> they leave us sleep sunday mornings since a few years though...
[08:38] <fullermd> See, if you could just get them to use some of that awake time for bzr hacking...
[08:39] <vila> why do you think there are so many bugs in my submissions ?
[08:40] <fullermd> I see.  Kids these days...   no QC.
[08:41] <vila> Sheesh, and don't start me about jam on the keyboard...
[08:41] <fullermd> Hah.  My first thought to that was "Doesn't John have his own keyboard?"   :p
[09:23] <zerok> morning :)
[09:40] <sabdfl> hey all
[09:42] <sabdfl> lifeless: nearly, nearly there?
[09:54] <Kinnison> Good moring bzr hackers
[10:16] <ubotu> New bug: #154259 in bzr "traceback on temporary ftp error" [Undecided,Confirmed] https://launchpad.net/bugs/154259
[10:18] <fullermd> I wonder if that error has EVER been temporary...
[10:33] <lifeless> sabdfl: very very close
[11:10] <Olberd> Hi. I'm trying to install bzrsvn in windows and can't make it work
[11:11] <Olberd> I have installed the python-svn requirement, but apparently not so that bzrsvn can locate it
[11:13] <Olberd> or could it be that the win32 package linked to on bzrsvn's homepage isn't new enough?
[11:13] <Olberd> jelmer, maybe you know?
[11:13] <jelmer> Olberd, Did you install the python-subversion bindings linked fomr the wiki page?
[11:15] <Olberd> yes, if you mean http://bazaar-vcs.org/BzrSvn
[11:15] <ubotu> New bug: #154283 in bzr "indexerror in Knit._get_components_positions pulling in pack repo" [Undecided,New] https://launchpad.net/bugs/154283
[11:19] <jelmer> Olberd: What exactly doesn't work?
[11:19] <Olberd> jelmer, it says in bzrsvn's readme that the svn should be at least 1.5. But the link on the wiki has the version 1.4.3.
[11:19] <jelmer> yes, but the .exe linked from the wiki has got the required patches backported
[11:19] <Olberd> When I try to run bzr bzrsvn prints: "no python bindings for subversion installed..."
[11:23] <jelmer> can you start python and run "import svn" ?
[11:24] <Olberd> yes, no errors
[11:26] <jelmer> is the same python interpreter used by bzr ?
[11:26] <jelmer> or did you perhaps install a bzr that included its own python?
[11:28] <Olberd> I used the standalone 0.91 windows installer
[11:30] <jelmer> you probably need the python-based installer
[11:30] <jelmer> I'll add a link to the wiki page
[11:33] <Olberd> ok, I'll try using the other installer
[11:43] <vila> jelmer: pong (looks like being in the same TZ doesn't help us to get in touch ;-)
[11:46] <jelmer> vila: :-)
[11:46] <jelmer> vila: What exactly did you with your comment to bug 141105?
[11:47] <vila> you mean mean ?
[11:47] <jelmer> I consider the svn+ prefix a hack, ideally bazaar should just handle SSL certificates properly
[11:48] <vila> hrm
[11:49] <vila> jelmer: feel free to reopen the bug then
[11:49] <vila> what I meant was that bzr now gives a proper error message instead of KeyError: 77
[11:49] <jelmer> ah, ok
[11:50] <vila> Handling SSL certificates is on my TODO list, python 2.6 will provides an ssl module for that
[11:50] <vila> problem solved :)
[11:50] <jelmer> :-)
[11:51] <vila> kidding, there is a module that can be installed for python 2.[45], I'm looking into integrating it into bzr or making bzr depend on it
[11:51] <jelmer> Ah, I was confusing this bug with bug 82086
[11:51] <jelmer> sorry
[11:51] <vila> np, better two brains than none on any subject :)
[11:51] <vila> that module will allow us to also have a proper https server, but there is a bit of work to get there
[11:52] <vila> and then, we can just deprecate pycurl and drink some champagne :)
[11:54] <jelmer> Yeah, that'd be nice
[11:56] <ryanakca> Is there a way to make a useable diff? I know 'bzr diff', but you can't really apply [11:56] <Kinnison> bundles
[11:57] <Kinnison> they're more what you want
[11:57] <Kinnison> I think
[11:57] <ryanakca> thanks :)
[11:57] <Kinnison> Specifically the 'bzr send' command I think
[11:59] <Kinnison> aah or the 'bzr bundle-revisions' command may be of more use
[12:01] <ryanakca> :)
[12:04] <ryanakca> Kinnison: any idea for http://pastebin.ca/742241?
[12:04] <Kinnison> odd
[12:04] <Kinnison> make the bundle --no-patch?
[12:05] <Kinnison> does that work?
[12:08]  * ryanakca tries
[12:08] <ryanakca> Kinnison: bzr: ERROR: no such option: --no-patch
[12:11] <jelmer> Olberd, any luck?
[12:14] <Kinnison> ryanakca: odd, because it's there for m
[12:14] <Kinnison> +e
[12:14] <ryanakca> hmmm...
[12:14] <ryanakca> what version?
[12:15] <ryanakca> 0.90.0?
[12:21] <ryanakca> Kinnison: hmm... I'll be back in 8 hours or so, school. See you ;)
[12:49] <danigm> hi, i have a question. When two developers push in one branch, and each developer has his own local branch, the log is overwrite. There is a method for push, or something similar that log well?
[12:50] <danigm> i mean, i push, and in the log appear danigm has changed ..., and when other developer push, must appear only his changes, not his branch log
[12:51] <jelmer> danigm, not sure I'm following
[12:54] <danigm> when i change something in my own branch, the log say that i make, and i merge with the main branch, and log it as "merged with main branch". And then push my branch, and the log of main branch dissapear, and appear my own log. I upload my own branch, the main branch is dessapear, is merged.
[12:57] <danigm> I think it's possible having two locals branch, my branch, and the main branch. When I want to publish my chages in main branch, I should merge that with mine, and push main
[12:58] <dato> I *think* he wants append_only = True, lemme re-read
[12:59] <danigm> but I need to branch from main, everytime that i want to push my changes
[13:02] <dato> oh, he was spanish
[13:12] <Olberd> jelmer, other error now
[13:15] <Olberd> it simply says: unable to load plugin u'bzrsvn' from u'.../plugins'
[13:15] <Olberd> I've run 'bzr selftest'
[13:15] <Olberd> It returns error: ... no module named svn.transport
[13:15] <jelmer> the plugin has to be named 'svn'
[13:16] <Olberd> ok
[13:16] <jelmer> rather than bzrsvn
[13:16] <Olberd> does it say that anywhere?
[13:16] <jelmer> it's only necessary for the testsuite afaik
[13:17] <Olberd> ok
[13:18] <Olberd> well, not only for the selftest
[13:19] <Olberd> Renaming it solved my problems it seems
[15:01] <mrevell> Hey - what version was pushing using bzr+ssh introduced? According to the release notes, I think it might 0.11 but then it says smart server didn't come until bzr 0.16.
[15:06] <quicksilver> bzr+ssh isn't smart server
[15:06] <quicksilver> bzr+ssh is just using ssh isn't it?
[15:06] <mrevell> Ah right, thanks.
[15:20] <radix> quicksilver: no, it's the smart server
[15:21] <radix> quicksilver: You can't do much with "just ssh" :)
[15:21] <radix> bzr+ssh connects on ssh and immediately starts up a smart server on the other side to handle the connection
[15:28] <quicksilver> radix: You could. You use use ssh and then shell out to commands like 'cat' and 'chmod' to build/alter the repo.
[15:29] <quicksilver> radix: I have used other systems which work like that.
[15:29] <quicksilver> but fair enough if that isn't what it does :)
[15:29] <radix> quicksilver: that's "ssh and cat and chmod", not "just ssh" :P
[15:30] <radix> but that's enough pedantry from me :-)
[17:38] <james_w> When using VersionedFile.add_lines() the parents argument is the previous revision-ids in which the file was modified, rather than the parents of the current revision, is that correct?
[17:38] <james_w> so 3 revisions, with revids rev1, rev2, rev3, and a file a that is created in rev1 and modified in rev3.
[17:39] <james_w> You would add lines for rev1 with no parents, and then rev3 with rev1 as parent, with nothing for rev2, is that correct?
[17:43] <jam-laptop> james_w: Correct
[17:43] <jam-laptop> (It is part of setting the per file graph, and also making sure the delta is built against an existing revision)
[17:43] <james_w> jam-laptop: thanks.
[17:44] <james_w> jam-laptop: also, any suggestion for what the tree root id could be for bzr-git. I am going with hash(path) for the ids, but this means that all trees would have the same root. This doesn't seem ideal, but I'm not sure what the impact would be.
[17:45] <jam-laptop> james_w: At the moment, I think all bzr trees use 'TREE_ROOT'
[17:45] <jam-laptop> which is also not ideal
[17:45] <jam-laptop> but it turns out that older versions of bzr didn't handle other values properly
[17:45] <jam-laptop> so we had to wait for a format bump to introduce unique ids
[17:45] <james_w> it's unambiguous though :)
[17:46] <jam-laptop> I believe Knit3 uses unique ids
[17:46] <james_w> yeah, it does for what I have seen
[17:46] <jam-laptop> (And bzr since about 0.14 or so is able to handle it)
[17:46] <jam-laptop> actually, maybe all the way back to 0.10
[17:46] <jam-laptop> and it is just 0.8 that can't
[17:46] <jam-laptop> anyway
[17:47] <jam-laptop> The *reason* to have unique tree roots
[17:47] <jam-laptop> is so that if you merge 2 trees into 1
[17:47] <jam-laptop> then when you do further merges
[17:47] <jam-laptop> it knows where to put files that show up in the root dir
[17:47] <jam-laptop> I'm guessing Git doesn't have any concept of project id
[17:47] <jam-laptop> etc
[17:47] <jam-laptop> so I would just go with hash('')
[17:47] <jam-laptop> and live with it
[17:47] <jam-laptop> you *could* use TREE_ROOT
[17:48] <jam-laptop> if you wanted
[17:48] <james_w> I'll go with the hash, thanks.
[17:49] <james_w> I was wanting to make it unique, as git supports submodules, and so we should map them on to nested trees at some point, and it seems non-unique would get in the way.
[17:49] <james_w> but they don't want to be too unique :)
[17:49] <jam-laptop> well, if you made them random
[17:50] <jam-laptop> then 2 people using bzr-git couldn't interoperate
[17:50] <jam-laptop> we'll have to handle the nested tree case anyway for our own data
[17:50] <jam-laptop> since we already have all trees with non-unique root ids
[17:51] <jam-laptop> plus bzr-git is going to have issues with all the same path directories looking alike anyway
[17:51] <jam-laptop> (so having 'src/' is going to collide with every other project that has a src/)
[17:51] <james_w> ah, of course. I'll just use that solution when you find it.
[17:51] <jam-laptop> of course
[17:52] <jam-laptop> if you had a way to come up with a unique tree root
[17:52] <jam-laptop> you could incorporate that into all the other directories
[17:52] <james_w> yeah, one solution could be to have a project-id passed to bzr-git that is just introduced in to the hash.
[17:52] <jam-laptop> but I can't think of a way to do it
[17:52] <james_w> but that would require an extra argument added to branch, checkout, init etc.
[17:53] <jam-laptop> if you wanted to be minorly evil
[17:53] <jam-laptop> you could double hash the first commit
[17:53] <jam-laptop> (take the commit's hash, and hash it)
[17:53] <jam-laptop> that would most likely be unique
[17:55] <jam-laptop> if a bit odd
[17:55] <jam-laptop> and might have problems after joining projects
[17:55] <jam-laptop> since then you have multiple rev1 nodes
[17:55] <jam-laptop> (you could sort them and just always pick the 1st one)
[17:56] <james_w> yeah, using the root commit as the root id did occur to me. You would get collisions occasionaly, but they would be far less.
[17:56] <jam-laptop> certainly far less than using the same value for everything :)
[17:59] <james_w> There are going to be a massive number of fork+execs to make this work it seems.
[18:09] <jam-laptop> well, that is how git is written, right?
[18:11] <Keybuk> wing-commander upstart% bzr bundle
[18:11] <Keybuk> Using saved location: bzr+ssh://keybuk@bazaar.launchpad.net/%7Ekeybuk/upstart/main/
[18:11] <Keybuk> bzr: ERROR: exceptions.AttributeError: 'RemoteRepository' object has no attribute '_make_parents_provider'
[18:11] <Keybuk> ^ d'oh
[18:13] <jelmer> Keybuk: IIRC that's a known bug
[18:13] <jelmer> high on the list for 0.92
[18:25] <Keybuk> ok
[20:04] <jam-laptop> spiv: I still haven't heard the status of chunked encoding: http://bundlebuggy.aaronbentley.com/request/%3C20070903172153.GC22003@steerpike.home.puzzling.org%3E
[20:04] <jam-laptop> I think Martin pinged you on it the other day, but I didn't see a response
[20:56] <ryanakca> bzr merge foo.bundle : any idea for http://pastebin.ca/742241?
[21:08] <AnMaster> bzr+ssh push protocol seems to ignore ~/.ssh/config
[21:08] <AnMaster> because it doesn't try to connect on the port I set it should in ~/.ssh/config
[21:09] <AnMaster> so pushing doesn't work as server use non-standard port
[21:09] <AnMaster> can anyone confirm this?
[21:09] <AnMaster> this bug*
[21:10] <AnMaster> ryanakca, tabs/spaces mixup?
[21:11] <ryanakca> AnMaster: yes, but why should bzr crash (other than python not liking mixtures of tabs/spaces)
[21:11] <AnMaster> ryanakca, no idea
[21:11] <AnMaster> any idea about my problem?
[21:30] <poolfool> AnMaster: https://bugs.launchpad.net/debian/+source/bzr/+bug/146715
[21:30] <ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Fix committed]
[21:30] <AnMaster> yes just found it a bit before
[21:31] <poolfool> AnMaster: Sorry didn't take the time to read it ... I was just lurking.
[21:31] <AnMaster> no problem
[21:36] <jam-laptop> ryanakca: it seems to be doing the merge using a patch
[21:36] <jam-laptop> not a bundle
[21:37] <jam-laptop> and it is requiring the source to be an exact match
[21:37] <jam-laptop> The traceback is probably because that code path isn't used yet
[21:37] <jam-laptop> I can't say I've seen it before
[21:38] <jam-laptop> I could be wrong
[21:38] <jam-laptop> AnMaster: known bug
[21:38] <jam-laptop> It has been fixed in bzr.dev
[21:38] <jam-laptop> so it will be fixed in 0.92
[21:39] <jam-laptop> ryanakca: The "crash" is probably because we would rather fail safe than continue, so we would at least give an error that the patch does not match
[21:39] <jam-laptop> It probably should be a simple refusal
[21:39] <jam-laptop> and not a traceback
[21:42] <ryanakca> jam-laptop: so, how to I make the requiring source an exact match?
[21:42] <ryanakca> jam-laptop: bzr revert?
[21:44] <lifeless> moin
[21:45] <jam-laptop> hi LarstiQ
[21:45] <jam-laptop> lifeless:
[21:45] <jam-laptop> ^^
[21:45] <jam-laptop> come to think of it, I haven't seen LarstiQ in a while
[21:45] <jam-laptop> ryanakca: it sounds like your bundle was munged
[21:45] <jam-laptop> and it is trying to ensure that the bundle you merge is the same as the patch you see
[21:45] <jam-laptop> (so that you don't look at the preview and approve that, but the actual merge merges something else)
[21:46] <jam-laptop> ryanakca: so it is *possible* that you could just edit the bundle to change the lines back to what it thinks they should be.
[21:46] <jam-laptop> (if they are now spaces, try making them tabs, etc)
[21:46] <ryanakca> Aha... I see.
[21:47] <ryanakca> jam-laptop: recreating the bundle fixed it... methinks it has something to do with copy-pasting.
[21:47] <jam-laptop> that would do it
[21:47] <jam-laptop> if it had tabs in it
[21:47] <jam-laptop> and you copy pasted it from a terminal
[21:47] <jam-laptop> that would probably turn it into spaces
[21:47] <jam-laptop> bzr send -o foo.patch is your friend :)
[21:48] <jam-laptop> (As would be bzr send --mail-to=joe@foo.com)
[21:48] <ryanakca> :)
[21:49] <ryanakca> Or just a plain old wget (since the bzr branch is in /var/www ) :D
[21:49] <ryanakca> jam-laptop: thanks!
[21:50] <jam-laptop> ryanakca: no problem
[22:02] <lifeless> ryanakca: well, if the branch is wgettable, just 'bzr merge' :)
[22:03] <lifeless> laters
[22:04] <ryanakca> lifeless: oh yeah, hehe :)
[23:43] <gotgenes> I can't connect to my server's svn repo using bzr-svn because it's through https with a self-signed certificate. Is there a workaround?