[00:00] <mwhudson> abentley: so previewtree will still need an inventory at some point without more diff refactoring?
[00:05] <abentley> No, I mean I hope that PreviewTree won't need an inventory, but until it's finished, we can't be sure.
[00:07] <lifeless> abentley: so, my diff suggestion, do you think its baked enough ?
[00:10] <abentley> Yeah.  The main thing it's silent on is how to handle kind changes, but I've got my own ideas.
[00:10] <lifeless> abentley: oh, hmm kind isn't in the signature is it?
[00:11] <abentley> Well, I was going to put it there anyhow.
[00:11] <lifeless> though if each Diff is contructed with the trees, at the start of TreeDiffer
[00:12] <lifeless> you don't need to extend the signature; cross-kind diff could just be a wildcard at the end of the [Diff, Diff, Diff..] list
[00:12] <mwhudson> abentley: fair enough
[00:12]  * mwhudson goes to bed
[00:14] <abentley> lifeless: Sure, but the larger issue for me is, what should CrossKindDiffer do?
[00:15] <abentley> My current idea is that it represents it as an add + delete, and uses the existing list of differs to do it.
[00:17] <lifeless> oh, in the UI ?
[00:20] <abentley> Well, the output.
[00:21] <abentley> So if you change a symlink to a file, it shows deletion of a symlink, and a unified diff that adds a file.
[00:21] <lifeless> so here's a corner case
[00:21] <lifeless> wjhat about subtree -> directory
[00:21] <lifeless> (with the same contents under both)
[00:22] <lifeless> but other than that I think it makes sense as you propose; presumably just call diff twice, once as a delete once as an add
[00:22] <abentley> I think the nested-trees code hides tree references from diffs, and presents the referenced directory instead.
[00:23] <lifeless> k
[00:24] <abentley> There's room for improvement, but that's good enough for nested-trees to go beta.
[00:25] <mtaylor> statik: have you actually started programming in erlang? or are you just interested in it?
[00:26] <ubotu> New bug: #164436 in bzr "permissions tests need to be parameterised too" [Medium,Triaged] https://launchpad.net/bugs/164436
[00:37] <poolie> lifeless, hi,
[00:51] <lifeless> poolie: oh, had you pung before I rung ?
[00:51] <lifeless> mtaylor: erlang is quite nice
[01:00] <jelmer> that would be the ultimate tool
[01:00] <jelmer> a distributed vcs that can run distributed
[01:04] <Odd_Bloke> :D
[01:10] <jelmer> ah well, g'night
[01:11] <schierbeck> good night :)
[01:30] <warren> hmm, somebody sent me a .patch file that is a bzr bundle
[01:30] <warren> I haven't merged this kind of thing before
[01:30] <warren> any pointer to docs of how to do this?
[01:31] <warren> (can I merge it into my tree keeping his metadata?)
[01:31] <Odd_Bloke> warren: You can, by and large, treat the file as a branch. (i.e. bzr pull bundle.patch, bzr merge bundle.patch)
[01:32] <warren> Odd_Bloke, ah
[01:33] <warren> Odd_Bloke, for future reference how do I create this kind of bundle myself?
[01:33] <Odd_Bloke> warren: 'bzr send' is the command you want to look at.  To create the file, use 'bzr send -o bundle.patch'.
[01:34] <Odd_Bloke> There are craftier ways to use it, but I haven't fully plumbed their depths.
[01:39] <poolie> (lunch)
[01:39] <abentley> warren: what platform are you on?
[01:40] <warren> abentley, Fedora
[01:41] <abentley> if you have xdg-utils installed, bzr send will automatically launch your preferred mail client, with the bundle as an attachment and everything.
[01:42] <warren> cool
[02:32] <poolie> ** launchpad is down for maintenance - upgrade to the next version
[02:32] <pygi> poolie: in this time of night ... :)
[02:34] <poolie> i mean, for an upgrade to the next version
[02:34] <poolie> it's midday here...
[02:34] <poolie> i think it's designed to correspond with the lowest daily usage - US and EU nighttime
[02:35] <abentley> poolie: It's okay.  I'm amazed you aussies can stand on your heads all day...
[02:37] <lifeless> poolie: patch mailed
[02:38] <lifeless> poolie: its not 'done', but this is a reasonable snapshot of progress; I think the vast ermaining bulk is the smart server verb
[03:07] <floam> Is it possible for me to have one file in my repository that sort of mirrors some single file from someone elses repository of a completely separate project?
[03:13] <poolie> floam, sorry, no
[03:13] <poolie> well,
[03:14] <poolie> what i suggest you do is make it a symlink to a file in a checkout of their project
[03:14] <lifeless> poolie: you can set up a branch with that one file merged, and other files will just conflict / could do partial merges all the time
[03:14] <poolie> that too
[03:15] <poolie> reading your patch
[03:15] <lifeless> thanks
[03:15] <lifeless> I'm folding now
[03:15] <abentley> floam: btw, what you're calling a "repository" we call a "working tree".
[03:16] <floam> abentley: sorry, I've used cvs/svn up until three months ago
[03:16] <abentley> We use "repository" more in the CVS sense.
[03:16] <floam> I assume the heart in the right place with the nomenclature wrong is better than the other way around :)
[03:17] <abentley> Sure.
[03:18] <poolie> folding?
[04:03] <mtaylor> lifeless: I've been looking at an erlang project, but I'm looking around for motivation to actually learn erlang :)
[04:05] <mtaylor> lifeless: do you know anything about extending erlang with c libraries? (like if I already had one and wanted to wrap it)
[04:31] <abentley> lifeless: ping
[06:45] <ubotu> New bug: #164443 in bzr "can't branch bzr.dev from codehost over bzr+ssh" [Critical,Confirmed] https://launchpad.net/bugs/164443
[06:45] <ubotu> New bug: #164447 in bzr "bzrlib.info.describe_format should be a BzrDirFormat method." [Medium,Triaged] https://launchpad.net/bugs/164447
[08:01] <ubotu> New bug: #164450 in bzr "should show a message when pushing(overwriting?) tags" [Low,Confirmed] https://launchpad.net/bugs/164450
[08:11] <ubotu> New bug: #164453 in bzr "bzr using way too much memory for large file fetch" [Undecided,New] https://launchpad.net/bugs/164453
[08:57] <lifeless> abentley: pong
[08:57] <lifeless> abentley: I'm guessing you are asleep at this point, but if it was re Differ's, I've replied - I think it's looking good.
[09:01] <poolie> thumper, ping?
[09:02] <thumper> poolie: pong
[09:02] <poolie> thumper, do you want to come to this call?
[09:02] <thumper> whose number?
[09:02] <poolie> conference centre?
[09:03] <thumper> I'm there
[09:19] <LarstiQ> Acro: I wasn't, and I'm going to class now again, but leave a message and I'll try to get back to you
[09:35] <ubotu> New bug: #164466 in bzr "rename packs from knitpack-experimental " [Undecided,New] https://launchpad.net/bugs/164466
[10:07] <AfC> Eeek!
[10:07] <AfC> I punched up http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk and it says "Not Found The requested URL /00/00/05/32 was not found on this server."
[10:12] <mwhudson> yes, that sucks
[10:14] <fullermd> That'll teach ya.
[10:17] <AfC> fullermd: :)
[10:30] <lifeless> mwhudson: whats the problem? missing / ?
[10:31] <mwhudson> lifeless: yeah, you get internally redirected to a url that you can't access, or something
[10:31] <lifeless> mwhudson: that should be trivial to fix;
[10:31] <lifeless> ... pretty please?
[10:32] <mwhudson> lifeless: it's an apache config issue, and i really don't know much about that
[10:32] <mwhudson> lifeless: file an RT?
[10:40] <theSoftMan> Hello, is Qbzr a complete GUI for bzr ? giving the possibility of add, commit, create branch,... ?
[10:41] <theSoftMan> and other question is : how to lauch it ?
[10:52] <lifeless> mwhudson: you need a redirect that matches the non/ - ...$ -> .../
[10:52] <lifeless> mwhudson: its maintained by the lp-bzr folk as part of the codehosting config
[10:52] <lifeless> theSoftMan: I'm sorry, I haven't used it myself, but yes I understand it to allow those operations
[10:56] <mwhudson> lifeless: so redirect ~blah/blah/blah to ~/blah/blah/blah/ before considering anything else?
[10:58] <AfC> mwhudson: yes
[11:00] <ubotu> New bug: #164476 in bzr "packs should be the default format" [Undecided,New] https://launchpad.net/bugs/164476
[11:04] <theSoftMan> lifeless : i have made the installation on my windows system but i can launch it ? ( thanks for you previous answer )
[14:26] <VSpike> hi folks - quick question probably.  I tried my first merge (woo!) and it was OK except while resolving some conflicts i had the case where the working tree had deleted the files and the merge source had made changes since the base ...
[14:27] <VSpike> except that I didn't understand what it was trying to tell me and so marked them as resolved because i knew the files had been deleted
[14:28] <VSpike> How can I get the .BASE and .OTHER files back for those items (I can remember which files they were), or how can I check the changes in the merge source against the base that was chosen, given that I don't know what the base chosen was?
[14:37] <fullermd> Maybe something with remerge?
[14:51] <VSpike> fullermd: I was wondering that too, but didn't want to try it without knowing what it might do :)
[14:52] <VSpike> I'm doing it manually and learning how bzr diff and bzr log work properly, so it's all good
[14:52] <fullermd> Well, it's unlikely to make demons fly out of your nose  ;)
[14:52] <VSpike> au contraire :)
[14:52] <VSpike> he
[15:05]  * Peng strangles bzr.
[15:05] <fullermd> Ack!  You squeeze all the vowels out!
[15:07]  * Peng strangles rubygems too.
[15:09] <Peng> I renamed foo/ to bar/. Bzr thinks everything in foo was removed and everything in bar is unknown. :(
[15:09] <fullermd> Isn't that what you'd expect?
[15:10] <Peng> Noo.
[15:10] <Peng> The directory was renamed.
[15:10] <dato> but how would bzr know?
[15:10] <Peng> As in 'bzr mv'.
[15:10] <fullermd> Well, yeah.  But if you didn't tell bzr about it...
[15:10] <Peng> Yes I did.
[15:10] <dato> on, `bzr mv`?
[15:11]  * fullermd blinks.
[15:11] <Peng> Well, it wasn't done by 'bzr mv'
[15:11] <Peng> But I ran 'bzr mv' afterwards, and it does know about the rename.
[15:11] <Peng> I think I give up.
[15:11] <dato> maybe you wanted `bzr mv --after`?
[15:11] <Peng> dato: I might've done that.
[15:11] <LeoNerd> Or just manually mv it back, then bzr mv it again
[15:11] <fullermd> Did you have the trailing slash on bar?
[15:12] <LeoNerd> "mv foo bar" oh oops I forgot; "mv bar foo; bzr mv foo bar"
[15:12] <fullermd> Yah.  That can be simpler when you're dealing with dirs.
[15:12] <Peng> @_@
[15:14] <Peng> Okay, I give up.
[15:14] <Peng> How do I bzr rm a directory that I've already rm -rfed?
[15:14] <dato> bzr will mark it as deleted automaticcally
[15:14] <fullermd> I don't think you have to...
[15:14] <Peng> Oh, that's right. I forgot.
[15:14] <Peng> Hmm.
[15:14] <Peng> I think something else is screwy.
[15:15] <fullermd> This would be the week for it.
[15:15] <Peng> Oh, never mind. The something else was user error.
[15:15] <Peng> Forgot I was in a different directory.
[15:16] <Peng> Hmm.
[15:16] <Peng> Part of this whole mess was probably user error because of that. Not all of it, though.
[16:23] <TeTeT> how to remove the changes of a specific revision? I'd like to get rid of rev 83, but this doesn't work: bzr merge . --r-83..-84
[16:24] <dato> bzr merge -r 83..82
[16:25] <TeTeT> says nothing to do
[16:28] <TeTeT> dato: ah, thx, made a mistake!
[16:29] <TeTeT> dato: I tried 83..84 ...
[18:50] <gioele> hello
[18:52] <gioele> is it dangerous to have a directory /a managed as a tree by bzr and another directory /a/b/c managed as another tree by bzr?
[18:53] <gioele> (/a/b/c would be on the ignore list of /a)
[18:53] <Peng> I don't think it's dangerous.
[18:54] <james_w> gioele: no that's fine.
[19:13] <gioele> thanks for the info
[19:28] <TeTeT> i'm currently pushing a 93MB branch to LP, it's running since once hour and I don't see much progress, still at Fetch phase 0/4
[19:28] <TeTeT> how can I check if anything is still happening?
[19:29] <james_w> TeTeT: ~/.bzr.log might have something
[19:31] <TeTeT> james_w: states 'fetch up to rev {spindler@...}'
[19:31] <TeTeT> james_w: and before that 'Using fetch logic to copy between KnitRepository(....)'
[19:32] <james_w> I thought it might say what it was doing as it worked, but it doesn't.
[19:32] <TeTeT> james_w: just finished :)
[19:32] <james_w> \o/
[19:32] <james_w> TeTeT: did you ever get bzr-builddeb working for you?
[19:33] <TeTeT> james_w: I honestly haven't tried, the packages I patched were not in bazaar anywhere
[19:33] <TeTeT> james_w: but I'll give it a whirl on a package for training I'm supposed to do
[19:33] <james_w> that's cool. I was being pretty useless trying to help you anyway, so I can't blame you.
[19:35] <TeTeT> you were most helpful, it just took a while to figure out where the problem was
[19:37] <james_w> well, if you need any help you know where to find me.
[19:37] <TeTeT> thanks for the offer :)
[19:39] <lifeless> 'lo
[19:41] <james_w> hi lifeless
[19:49] <woei> hmm, I've merged a branch, it added some revisions, great. How do I get the log message and the diff of the new (but not yet committed) revisions in chronological order ?. Something like svn log|diff -rBASE:HEAD.
[19:50] <james_w> woei: if I understand what you mean 'bzr diff' should give you the diff. 'bzr status' will show a summary of each merged revision.
[19:51] <james_w> If you want the full log then that is a bit harder, one easy way that might not work would be 'bzr missing --theirs-only .../otherbranch'
[19:51] <dato> .oO( bzr commit; poke; bzr uncommit ;)
[19:52] <james_w> There will be a way to get the log with the log command, but my brain fails me once again.
[19:52] <woei> I'm looking for something like gitk, where you can see the log and the diff of what happened at each commit
[19:52] <woei> bzr diff does give me the diff, but it gives me the diff of all the revisions I just merged
[19:54] <woei> when getting revision 3, 4, 5, I'd like to see the log of rev.3, the patch of rev.3, the log of rev.4, patch of rev.4, etc.
[19:55] <dato> woei: after you've committed the merge, it's easy to do that with bzr log and bzr diff, or visually with `bzr viz` (from bzr-gtk)
[19:55] <gioele> woei: maybe you're looking for bzr gtk (olive)
[19:56] <dato> woei: without committing the merge, I don't think you can, at least I wouldn't know how.
[19:56] <woei> ok, so I'd branch a working copy, merge from upstream, use a graphical tool to go over each patch, and then merge that pulled branch back to the real working copy
[19:59] <james_w> woei: that would work.
[19:59] <james_w> woei: there is a bug to allow you to access the merged revisions, but no-one has worked on it yet.
[19:59] <woei> hmm, and is there an easy way to refer to the revision prior to the last merge ? So bzr log and bzr diff only shows that interval ?
[19:59] <james_w> also bzr-gtk doesn't deal with merged in stuff at all.
[20:00] <james_w> woei: the last merge in which direction?
[20:00] <woei> the stuff I pulled from upstream
[20:00] <woei> and then committed
[20:00] <woei> prior to merging it back to the real working area
[20:01] <james_w> so you want to see the stuff that you did in your branch since the last time you merged from the other branch?
[20:01] <woei> after committing, bzr log does show the new revisions indented, but how do I tell it to show only those revisions with bzr log ?
[20:01] <dato> woei: try bzr log -r -1
[20:02] <dato> it will show them still indented, but *only* them. if I understood correctly.
[20:03] <woei> no, I made a branch to merge in changes from upstream. I did a bzr merge. I'd like to see the log and patch for each commit. That's not possible (yet) on the command line. Okay, so I commit that merge (from upstream). How can I get just the log (and diff) from the point where I branched from my working copy (to receive new revisions from upstream), and the head of what's in the (now synchronized) branch ?
[20:04] <woei> dato: excellent, bzr log -r -1 does just that
[20:04] <woei> but bzr diff -r -1 does not
[20:04] <dato> for the diff, bzr diff -c -1 will give you the whole diff
[20:05] <AmanicA> or bzr diff -r -2..-1
[20:05] <woei> dato: ok, great
[20:05] <james_w> woei: bzr-gtk will now be able to give you diff for each commit. For the command line you can use bzr diff -c x.y or bzr diff -c revid:xxx
[20:06] <woei> ok, I'm starting to get the picture on why I needed to commit
[20:08] <dato> woei: also, it's not strictly necessary that you make a separate branch and merge there; you could merge in your branch, commit, and if for some reason you don't like the result, do `bzr uncommit`
[20:08] <woei> and that extra branch to receive new revisions is not really needed, if you use bzr commit; bzr viz; bzr uncommit
[20:08] <woei> dato: exactly :)
[20:08] <dato> :)
[20:09] <woei> ok, thanks all for pointers
[20:15] <ubotu> New bug: #164567 in bzr "FTP push does not work without specifying password" [Undecided,New] https://launchpad.net/bugs/164567
[20:56] <jelmer> abentley: ping
[21:00] <jelmer> odd, I seem to be missing emails on bazaar@lists.canonical.com :-(
[21:40] <keir> is there a way use a GUI of some sort to go through a diff, and accept or reject chunks?
[21:45] <lifeless> keir: at commit time ?
[21:46] <keir> so, what i have done, is checked in an external library into my tree, and made several changes
[21:46] <keir> but now upstream has moved forward
[21:46] <keir> so what i've done is just copied upstream over top of my working tree
[21:46] <keir> when i do diff, my changes show up as -'d
[21:46] <keir> i want to revert just those chunks, then check in the changes
[21:46] <lifeless> do you know of 'bzr shelve' ?
[21:47] <keir> i thought that is just for uncommitted changes?
[21:47] <keir> in my case, i committed my changes ages ago
[21:47] <lifeless> these are uncommitted changes :)
[21:47] <lifeless> you have an uncommitted reversal of your change
[21:47] <keir> oh, i see
[21:47] <keir> now, the slight problem, is that these changes are close in proximity to mine
[21:48] <lifeless> ok
[21:48] <dato> keir: for some other time, why don't you apply the new version in a separate branch, and merge that?
[21:48] <keir> so in multiple places, the hunks show up as a single hunk, with an add and a remove
[21:48] <lifeless> heres a different and more scalable approach
[21:48] <lifeless> branch -r <when you imported the code> upstream
[21:48] <lifeless> cd upstream
[21:48] <keir> ah yes, i see
[21:48] <lifeless> unpack upstream stuff; bzr add; bzr commit
[21:48] <lifeless> cd your-branch
[21:48] <lifeless> bzr merge upstream
[21:48] <keir> yes, ok.
[21:49] <keir> wait, but i only want to merge the particular changes to the extern/ lib; not the other changes
[21:49] <keir> so isn't this a cherry pick?
[21:49] <lifeless> no
[21:50] <lifeless> what other changes will be in that branch than those to lib from upstrea?
[21:50] <keir> hmm
[21:50] <keir> sorry, thinko, i got it
[21:54] <keir> dist vc is so nice :)
[21:59] <keir> i'm itching to implement the faster index layer... stupid RL
[21:59] <lifeless> yah
[21:59] <lifeless> same
[21:59] <lifeless> :)
[22:00] <keir> an aside: why is it that bzr 'detects' deletions?
[22:00] <lifeless> there is a bug
[22:00] <keir> rather than svn's behaviour
[22:00] <lifeless> it should be a flag like -A to automatically add and delete new paths
[22:00] <lifeless> and by default error on deletes
[22:01] <keir> yeah, i totally agree. though there is a case that it is the 'wrong' way to use a vc, i like in svn that if i do something silly, i can just delete and svn up
[22:01] <keir> i know that's what revert is for
[22:01] <keir> yet somehow i prefer delet and update
[22:02] <lifeless> its really very strange for me that svn update restores files rather than preserving your changes - its inconsistent.
[22:03] <keir> on a completely logical level, i agree
[22:03] <keir> yet somehow, i feel like the vc is my 'barrier against stupidity'... if i go and delete stuff, without informing bzr, i probably didn't mean it
[22:03] <AfC> And lord knows preserving the broken behaviour of previous generations of tools is not the primary goal around here
[22:04] <fullermd> On the other hand, if I delete stuff, I do mean it...
[22:04] <dato> fullermd: alias commit=commit -A ;)
[22:05] <dato> (when that exists)
[22:05] <fullermd> But just because a file exists, doesn't mean I want to add it.
[22:05] <keir> fullermd, i feel the same way about deletes :)
[22:05] <dato> yeah, I'm not sure why lifeless mentioned additions for commit -A
[22:05] <keir> perhaps commit -D
[22:05] <dato> yeah
[22:06] <keir> or bzr delete --missing
[22:06] <lifeless> A for automatic
[22:06] <lifeless> commit --automatic
[22:06] <keir> lifeless, but it may be the case that you want to delete missing files, but not add unversioned files
[22:07] <lifeless> keir: so the question is
[22:07] <lifeless> is it worth having two flags
[22:08] <lifeless> the main use case for commit --automatic is automated scripts
[22:08] <keir> lifeless, aah, i see
[22:08] <lifeless> but bzr rm --missing/--gone etc is a good way to have the equivalent of 'bzr add'
[22:08] <lifeless> OTOH why not have 'bzr rm' do what bzr add does :)
[22:09] <lifeless> but in reverse - rm everything that is not here
[22:09] <keir> lifeless, exactly, that's what i meant by bzr delete --missing. i guess there is no bzr delete. heh
[22:09] <lifeless> abentley: patch reviewed
[22:10] <keir> does bzr internally support a status which is 'file is missing from WT' without having the 'delete at commit' bit set?
[22:11] <fullermd> I don't think the delete bit is set until commit runs.
[22:11] <keir> so status just shows it as a pending delete?
[22:11] <fullermd> Yah.  Put a file back on that name, and it'll just show up changed (or unchanged, if the file's the same).
[22:12] <keir> but it would involve extending WT model to allow a new 'state' for deleted files which is missing, but not deleted?
[22:12] <fullermd> You lost me...
[22:13] <keir> i'm trying to think of how hard it is to implement the following:
[22:13] <keir> 1) deleting a file in local repo does not mean it will be deleted at commit
[22:13] <keir> 2) files which are to be deleted must be explicitcly bzr rm'd
[22:14] <keir> 3) bzr st supports showing either explicitly deleted, or missing but not deleted, states
[22:14] <keir> 4) bzr rm --missing does what you expect
[22:15] <keir> i don't know anything about the WT's data model so that's why i'm asking these qns
[22:15] <fullermd> I imagine 1/2 are just changes in commit, and 3 is just a change in status.  The file isn't _deleted_, as putting it back will show.  It just says it's deleted.
[22:16] <keir> this would make rm consistent with add
[22:17] <keir> would a patch to do this be rejected immediately because it changes behaviour?
[22:17] <fullermd> Rejected?  Doubt it.  But it probably calls for a list discussion.
[22:18] <keir> alrighty.
[22:27] <lifeless> keir: 1) I would not like unless you mean 'will error at commit'; 2) would be good as long as there is an option for ocommit to get deletes back. 3) is already done I thought, 4) would be nice
[22:27] <lifeless> I'd send an RFC, get some consensus, then patch
[22:27] <lifeless> there is a bug already as I mentioned
[22:34] <lifeless> abentley: ping, is there a inventory delta to iter_changes adapter around somewhere ?
[22:35] <lifeless> abentley: I'd like to make bzr-email use the inventory delta generated by commit
[22:40] <cbx33> hi guys
[22:41] <cbx33> I've been happily push changes to my branch on LP
[22:41] <keir> lifeless, ok. i'll probably wait.. realistically, if i'm going to do bzr hacking i should write the index layer
[22:41] <cbx33> today I merged with someone, did some chages, pushed them successfuly, did some more changes....now I get an error that the branch has DIVERGED?
[22:41] <cbx33> what is going on?
[22:42] <cbx33> it suggests trying a merge then a push
[22:42] <cbx33> but who do i merge with....my own older branch?
[22:42] <cbx33> it doesnt make sense
[22:43] <lifeless> cbx33: did you do the second set of changes in your branch ?
[22:43] <cbx33> yes
[22:43] <lifeless> what command gives you the error ?
[22:43] <cbx33> bzr push
[22:43]  * fullermd suggests checking 'missing'.
[22:43] <cbx33> it committed fine
[22:45] <lifeless> cbx33: as fullermd says, what does 'bzr missing URLYOUPUSHTO' do ?
[22:45] <cbx33> i was missing a merge
[22:45] <cbx33> with myself
[22:45] <cbx33> ok fixed
[22:46] <cbx33> but not sure why;)
[22:46] <lifeless> did you push there from more than one place ?
[22:46] <cbx33> hmmm
[22:46] <cbx33> possibly
[22:46] <cbx33> yes that may have been it
[22:46] <cbx33> thanks lifeless
[22:56] <igc> morning all
[22:57] <lifeless> hi
[22:58] <poolie> hi
[22:58] <poolie> call in 2m?
[22:58] <igc> yes
[23:00] <poolie> lifeless, igc: ping
[23:04] <abentley> lifeless: I don't think we have an adaptor like that.
[23:06] <abentley> jelmer: pong
[23:12] <lifeless> abentley: ok