[00:04] <maxb> hmm, I wonder how long it takes to rebase 1500 revisions
[00:05] <maxb> this is one scenario when bzr's speed is a bit lacking
[00:07] <maxb> Gaaaaah
[00:07] <maxb> I bet rebase-foreign is picking the file-ids from the wrong side
[00:08] <maxb> cjwatson: What's the aim with the debian-cd branches? End up with the ubuntu branch retrofitted with debian file ids and on top of the debian history?
[00:11] <cjwatson> maxb: Debian used to use svn and now uses git; I want to rebase/merge/whatever across that change
[00:11] <cjwatson> the Ubuntu branch was created when it used svn (or maybe even CVS, but I think it was svn)
[00:12] <maxb> hmm... how come both branches have arch-style revids?
[00:12] <lifeless> cscvs to tla
[00:12] <cjwatson> cancel "rebase/merge/whatever", I specifically want to merge forward, but I'm happy to use something rebase-like to pretend that my history was always based on git
[00:13] <maxb> But lp:debian-cd is still a svn import
[00:19] <maxb> urgh, it died again
[00:22] <maxb> that's immensely irritating. the rebase died 4 revisions short of finishing
[00:42] <lamont> maxb: but only one or two more bugs to fix, right?
[00:42] <maxb> I'll let you know when it finishes another attempt :-)
[00:49] <cjwatson> maxb: hmm, I think I mean "Debian used to use cvs and now uses svn", then
[00:49] <cjwatson> maxb: so the current Ubuntu branch was created when it used cvs
[00:49] <cjwatson> apologies for that confusion
[00:50] <cjwatson> the change was years ago
[00:54] <maxb> assuming it doesn't explode again, I'll push some results in 10 mins or so
[00:54] <maxb> although given how confusing I found the code, you probably want jelmer to review my hacks to bzr-rewrite before you trust its output
[01:01] <maxb> lp:~maxb/bzr-rewrite/ubuntu-debian-cd-rebase-foreign succeeds in the rebase. I can't push my rebased branch because grrrrrr I did it in a shared repo and now have different rich-root errors
[01:05] <lamont> so these blob files... how big do they get?
[01:05] <maxb> huuuuuuge
[01:05] <maxb> As they store the literal content of every revision of every file
[01:05] <lamont> is it basically a concatenation of every single output-format commit ever?
[01:06] <lamont> 375MB cvs tree, 4.7GB of blob and counting
[01:06] <maxb> yup
[01:06] <lamont> oh rapture.
[01:06] <maxb> disk is cheap, right?
[01:06] <lamont> now, where _are_ my scissors.
[01:07] <lamont> ....
[01:07] <maxb> It gets worse - if you pass the data on stdin to fast-import, it caches the blobs in memory!
[01:07] <lamont> git and bzr? or is bzr the only thing silly enough to do that?
[01:08] <lamont> svn being in the "totally do not care" category
[01:08] <maxb> I'm assuming just bzr
[01:08] <maxb> It's really silly, it could just keep track of a revid+fileid and get the content back that way if it needed it again later
[01:18] <Phil_Bordelon> Hello there.
[01:18] <maxb> and pushed: lp:~maxb/debian-cd/ubuntu-rebased
[01:18] <Phil_Bordelon> Does anyone know if there's an equivalent to svndumpfilter available for bzr?
[01:19] <maxb> There's bzr fast-import-filter
[01:19] <cjwatson> maxb: cool, thanks!  I'll have a look ..
[01:20] <Phil_Bordelon> Awesome.  Just what I needed.  Thanks, maxb.
[01:20] <Phil_Bordelon> I'm a writer, and I have stuff in an 'incubator' repo in bzr that I occasionally want to split off into its own repo.  This'll do just that. :)
[01:20] <Phil_Bordelon> (same with code.)
[01:22] <Phil_Bordelon> <3  You and Ian C. made my evening.
[01:25] <mtaylor> abentley: didn't you say that there was a ppa that had bzr 2.1beta in it?
[01:26] <abentley> mtaylor: Sure, and either the beta ppa or the nightly ppa should.  They don't?
[01:26] <mtaylor> abentley: I don't see them on the ~bzr page...
[01:27] <abentley> mtaylor: They were started before a user could have multiple ppas, so they have different users.
[01:27] <maxb> the beta ppa is rather out of date. It has versions older that the ~bzr ppa
[01:27] <maxb> *than
[01:28] <abentley> mtaylor: https://launchpad.net/~bzr-beta-ppa/+archive
[01:28] <abentley> mtaylor: https://launchpad.net/~bzr-nightly-ppa/+archive
[01:28] <mtaylor> abentley: AWESOME
[01:28] <mtaylor> abentley: thankx
[02:17] <jml> abentley, you know what would make me like remerge a whole lot more?
[02:27]  * igc lunch
[02:59] <lifeless> jml: what would
[03:03] <jml> lifeless, oh, I spoke w/ abentley IRL
[03:04] <jml> lifeless, a way of seeing what it actually changed, especially wrt files that used to conflict.
[04:13] <lifeless> vila: https://code.edge.launchpad.net/~vila/subunit/gtk-filter-fixes can you mark this as obsolete?
[06:22] <abentley> lifeless: ping
[07:14] <vila> lifeless: it's already marked as merged, anything more needed ?
[07:15] <vila> hi all ! (by the way :)
[08:11] <GaryvdM> Hi vila.
[08:12] <vila>  hey GaryvdM !
[08:12] <vila> That was short...
[08:13] <vila>  hey GaryvdM ! (Was I saying when your client quit :)
[08:14] <bialix> heya bzr
[08:14] <bialix> igc here?
[08:16] <bialix> hi garyvdm
[08:18] <garyvdm> hmm - something wrong with my keyboard config and xchat. when I press "q" it takes it as ctrl + q
[08:18] <garyvdm> hi bialix
[08:18] <vila> hey garyvdm ! (Third time :)
[08:19] <bialix> vila and gary meet each other. finally
[08:19] <bialix> hi vila!
[08:19] <vila> hey bialix :-D
[08:19]  * vila LOLs :)
[08:19] <bialix> :-D
[08:19] <garyvdm> vila: just wanted to say: I've replied to your question about the qbzr test suit,
[08:20] <vila> garyvdm: now that's timely :D Thanks a lot
[08:21] <vila> garyvdm: hmm, I already spend far too much time administering my zoo, but it's good to know it will go away soon
[08:21] <bialix> garyvdm: just info: I will be unable to work on qbzr till February
[08:22] <garyvdm> bialix: Ok - np
[08:22] <vila> garyvdm: at worst the test can be tagged as requiring pyqt-4.6.1...
[08:22] <vila> s/test/tests/
[08:22] <vila> garyvdm: but waiting for a karmic upgrade is good enough for me
[08:22] <garyvdm> vila: that is a good idea.
[08:23] <garyvdm> or a known failer
[08:25] <vila> garyvdm: know failure will be harder, skip may be good enough
[08:25] <garyvdm> ok
[08:26] <vila> bialix, garyvdm : Congrats for the qbzr-0.18 release by the way !
[08:26] <garyvdm> :-)
[08:26] <bialix> vila: thanks, I'm appreciate the congrats
[08:27] <vila> garyvdm: since you're there, are you still working on the unicode-bom-detect stuff ?
[08:27] <garyvdm> Not for the moment, but I will get back to it.
[08:28] <vila> garyvdm: I was thinking that since you can't do that unconditionally (as abentley pointed out) you may think about implementing the feature in some read-only mode as a first step
[08:28] <bialix> vila: can I ask about bzr itself?
[08:28] <vila> bialix: don't ask to ask, ask :D
[08:38] <garyvdm> vila: " some read-only mode" == command line paramater?
[08:39] <vila> garyvdm: no, at the API level
[08:39] <garyvdm> Ok
[08:39] <vila> AIUI you need this patch for read-only operations (diff, cat, etc)
[08:40] <vila> there may be a way to have additional methods that these read-operations can use and avoid the problems mentioned by abentley
[08:41] <vila> garyvdm: I haven't look in detail so take the suggestion with a grain of salt
[08:41] <garyvdm> vila: I also need to go into some details
[08:42] <vila> garyvdm: ok
[08:42] <bialix> vila: any ideas about https://bugs.launchpad.net/bzr/+bug/244291
[08:43] <bialix> I've offered to provide the repo where this bug present
[08:43] <bialix> is it needed?
[08:43] <bialix> or I should not ask to ask?
[08:44] <bialix> I'm worrying a bit because this repo is no more actively using by me: I'm switching to use colo
[08:45] <bialix> so I can delete it one day accidentaly
[08:48]  * vila reading
[08:53] <vila> bialix: hmm, this looks like a plain branch, how did you end up with an out-of-date working tree ?
[08:54] <bialix> this branch was used as master for light checkout
[08:54] <bialix> it was easy
[08:56]  * garyvdm -> work
[08:58] <vila> bialix: so the bialix@ukr.net-20091128210111-wlxjvzkuj72ze9mi revisions is not in the repo yet the branch references it, how weird... DId you implement some gc without telling us ? :-D
[08:58] <vila> bialix: more seriously do you use some stacked branches ?
[08:58] <bialix> I'm sure this revision in the repo
[08:59] <bialix> because qlog works without errors
[08:59]  * vila blinks
[08:59] <bialix> I don't made gc
[08:59] <bialix> and don't use stacked
[08:59] <bialix> (stacked seems evil for me)
[08:59] <vila> hmm, let me guess, that revision is in the branch history but *not* a mainline revision ?
[09:00] <vila> qlog should show you that quite easily :D
[09:03] <vila> bialix: hmm or somehow that revision went completely out of the branch history after some 'uncommit' or 'push --overwrite'... but let's check if it's still in the branch history first
[09:05] <Anteru> Hi
[09:05] <Anteru> I've just switched a repository from SVN to Bzr (using bzr svn-import), and we're running into weird issues. First of all, a bzr check told us that we have 250 broken parents or so
[09:06] <Anteru> This could be fixed by using bzr reconcile
[09:06] <Anteru> Unfortunately, diff's regularly fail with NoSuchRevision ...
[09:07] <vila> Anteru: hmm, bzr-svn is the recommended way for that AFAIK, but for context, what versions are you using ?
[09:07] <Anteru> Commit works, but diff fails (before/after the commit)
[09:07] <Anteru> Running bzr 2.0.3
[09:07] <Anteru> (latest stable)
[09:07] <Anteru> Server is running bzr 2.0.3 as well, and we're publishing right now using sftp due to issues with bzr serve/fastcgi
[09:08] <Anteru> basically, the problem is that when we try to diff, we get "bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///V:/proj/.bzr/repository/') has no revision dev@anteru.net-20100109162623-iqh9at1lxqx8n38p"
[09:08] <bialix> vila: this revision is the revision of working tree
[09:09]  * bialix preparing screenshot!
[09:09] <vila> Anteru: try bzr reconcile first
[09:09] <Anteru> We did reconcile
[09:10] <Anteru> It's also not for all files, for some, diff works perfectly, but for some, we get the error above
[09:10] <vila> bialix: yes (because most probably info -v starts from the actual tip), but the wt is out-of-date and it seems that doesn't play well here
[09:11] <vila> Anteru: weird, is 'bzr check' happy now ?
[09:11] <Anteru> 20 ghost revisions, let me run it again just to get the output
[09:11] <bialix> vila: http://launchpadlibrarian.net/38124517/qlog-bug-244291.png
[09:13]  * bialix -> work
[09:13] <vila> bialix: great, so it *is* in the branch ancestry, that narrows down the problem
[09:13] <Anteru> (this will take some while, 2.6k revisions)
[09:14] <Anteru> OT: Is check going to become faster some day?
[09:16] <vila> bialix: and I presume that the error goes away if you run 'bzr update' ?
[09:17] <bialix> maybe, I did not try
[09:17] <vila> Anteru: for some value of some, yes. There are plans to implement more options to allow finer-grained checks
[09:17] <bialix> vila: tried in the copy: yes, error go away after up
[09:18] <Anteru> vila: check output: http://pastebin.ca/1758667
[09:18] <vila> bialix: that would help the diagnosis (I'll need to write the test otherwise :-)... YES !
[09:18] <bialix> added to bug comments
[09:19] <bialix> thanks
[09:19] <vila> bialix:  me too :)
[09:19] <vila> bialix: lol, we added nearly the same comments :)
[09:20] <vila> Anteru: yeah, ghosts...
[09:20] <Anteru> Any way to get rid of those, if they're causing these issues?
[09:21] <Anteru> I have no problem to fiddle around with the repository, as long as no information gets lost (as we have already some commits in there)
[09:21] <vila> I'm pretty sure it's related to svn-import/bzr-svn then, but you need someone more experienced than me with the svn conversions then, try to find jelmer or better file a bug on lp or write an email to the bazaar list
[09:22] <vila> Anteru: if you go away from svn, these ghosts need to filled
[09:22] <vila> s/to filled/to be filled/
[09:22] <Anteru> Any idea how/where to start?
[09:23] <vila> AnMaster: A ghost is a revision that exists but bzr is not aware of its content
[09:23] <vila> Anteru: not really, that sounds like a genuine svn-import bug to me though
[09:24] <Anteru> Which sounds like a very serious issue to me, as we can't go back to svn that easily now :/
[09:24] <vila> Anteru: that's why I said it's a bug
[09:25] <Anteru> I'll try the mailing list and cross my fingers that the repository/history can be rescued. Damn, I wonder why we didn't run earlier into this.
[09:26] <Anteru> Just now, after fully switching :/
[09:26] <vila> Anteru: the first thing is to get the list of the ghosts revisions, look into .bzr.log or re-run 'bzr check -v' and look again
[09:27] <vila> from there you'lll have to find out what theses revisions are.... and inject them into the repo (how to do that with svn-import is a different story...)
[09:27] <vila> Anteru: did you use bzr-svn before switching ?
[09:28] <Anteru> Yes
[09:28] <vila> Anteru: Do you use shared repos ?
[09:28] <Anteru> I used it locally for some time (200 revisions?), but we finally decided to fully move and started from scratch (i.e. ran svn-import on the server, and branched from there)
[09:28] <Anteru> bzr.log contains loads of errors: http://pastebin.ca/1758676
[09:30] <vila> All the 'Unable to open' errors should be harmless as long as you don't see them in the console (I'm pretty sure that's bzr-svn trying to find an svn repo in wrong places and failing)
[09:31] <Anteru> That is, the usage previously was that one developer (me) who used bzr locally, by doing svn-import, binding to svn, and branching/merging locally. The other dev was using SVN (but I think it was only like 2-3 commits)
[09:32] <Anteru> Now we scrapped all local bzr copies, and simply ran import again, and I branched off the new repository.
[09:32] <vila> argh !
[09:32] <Anteru> ?
[09:32] <Anteru> We should have done everything differently?
[09:32] <vila> I was hoping to find the ghosts in your previous bzr branches !
[09:33] <Anteru> IIRC, I had some ghosts revisions in my first local import (i.e. the first time I ran svn-import)
[09:33] <vila> Anteru: you could have started with your bzr branch instead which was presumably complete instead of re-running svn-import
[09:34] <Anteru> The original branch already had these ghost revisions (and I think, even the same number -- I was asking here if this is normal that I'm like 10 revisions behind the SVN, and I was told yeah.)
[09:35] <Anteru> Running bzr check -v now
[09:35] <vila> Anteru: Then I'm a bit lost... AFAIK bzr-svn create ghosts only for bzr revisions that can't be exported to svn, so you need at least two people using it to encounter the problem...
[09:36] <vila> or two branches that don't share a repo
[09:36] <Anteru> Well, I didn bzr svn-import on two machines
[09:36] <Anteru> Which would solve that issue
[09:36] <Anteru> I.e. explain how the ghost revisions appeared, but as I said, I had them right away
[09:37] <Anteru> The first time I did svn-import, I was 10 or 20 revisions behind, with some ghosts.
[09:40] <vila> Anteru: I confused svn-import (which *is* part of bzr-svn) and svn2bzr. You definitely needs jelmer here
[09:40] <Anteru> bzr check -v gives the ghost revision ids
[09:40] <vila> AnMaster: and you lamost certainly needs the bzr repos where the ghosts were created
[09:41] <lifeless> vila: it has unmerged changes that won't be merged. it needs to be marked obseleted or whatever. its showing up in branch listing.
[09:41] <lifeless> abentley: pog
[09:41] <lifeless> abentley: pong
[09:41] <vila> from there, branching from the repo that contains the revisions into the repo where they are ghosts should filled them
[09:42] <Anteru> Great, as we don't have them :/
[09:42] <abentley> lifeless: I couldn't remember whether we were doing code review for bzr-pqm or just pushing.  In the end, I requested a review.
[09:43] <Anteru> Ah well, something is always going wrong. I wonder where they came from as we did a fresh svn-import
[09:47] <lifeless> abentley: ok, I shall review in the morning if thats ok
[09:49] <abentley> lifeless: That's fine.
[09:50] <Anteru> vila: Yeah, looks like the merges are the culprit (i.e. local bzr getting merged into SVN)
[09:52] <vila> Anteru: yes, that create ghosts because svn can't represent them so bzr-svn store the revids in some svn property to be able to roundtrip safely
[09:52] <Anteru> (at least, I count 17 merges, and some might have 2 or 3 revisions)
[09:52] <Anteru> Gosh, I would be happy to get rid of them (i.e. I don't worry if the fact that it was a merge is lost)
[09:53] <Anteru> and just treat them as normal commits to the trunk
[09:53] <vila> Anteru: then there should be a way but that requires some voodoo knowledge of bzr-svn internals, file a bug
[09:54] <Anteru> Ok. Any idea if there is a way to get it fixed on the bzr repository directly :) ?
[09:58] <lifeless> night
[09:58] <vila> Anteru: Hopefully yes, but whether it's only deleting them from the parent list or if more is required, I can't say
[09:58] <vila> lifeless: done
[09:59] <vila> lifeless: g'night
[09:59] <Anteru> Ok, cool. I'm going to write a _long_ writeup to the mailing list.
[09:59] <Anteru> I.e. explain all the problems we created ;)
[09:59] <vila> Anteru: too bad you didn't keep the bzr repos around for a while, are you sure you don't have a backup somewhere ?
[10:00] <Anteru> Pretty sure, unfortunately, as I had like 10 repos during testing, and got rid of them all at once.
[10:00] <Anteru> (testing means only locally to check performance etc.)
[10:08] <Anteru> Sent
[10:09] <Anteru> Let's see if someone has an idea (fingers crossed)
[10:13] <Anteru> vila: Thanks!
[10:14] <vila> Anteru: you're welcome! Your experience should at least help us better document the process so those ghosts don't get lost the next time :-/
[10:15] <vila> Anteru: Another way to fix the problem *may* be to try bzr-replay and see if it can cope with the ghosts
[10:15] <Anteru> Yeah, I'm also going to blog about this, in the hope that it will help other people to migrate from SVN to Bzr (because I'm really happy with Bzr)
[10:15] <vila> Anteru: you will end up with a repo with *different* revids though, so be prepared to resynchronize every people involved
[10:15] <Anteru> That's no problem
[10:16] <Anteru> I can simply delete the repository on the server, recreate it, and tell everyone to branch again :)
[10:24] <Anteru> Trying bzr replay of all revisions, let's see if/when this finishes ... doesn't look too fast (pegging one core @ 100% and reading like 2 KiB/s)
[10:47] <l2m> hi ^^
[10:47] <l2m> could anyone help me to understand why the bzr commit does not works with the --fixes switch ?
[10:48] <l2m> i've added in the config file the line trac_mysite_url = http://www.mysite.com/trac
[10:48] <l2m> and nothing seems to happend when i do a bzr commit --verbose  --fixes mysite:106 -m'test___'
[10:49] <bialix> if you run qlog you'll see it there
[10:49] <bialix> what you expect actually?
[10:49] <l2m> qlog ?
[10:50] <bialix> qlog is the part of qbzr plugin
[10:50] <bialix> it's wonderful gui
[10:51] <bialix> --fixes store special metadata attached to committed revision
[10:51] <bialix> it's not quite visible
[10:51] <bialix> qlog makes it clearly visible
[10:51] <l2m> but why is --fixes not calling trac ?
[10:51] <bialix> --fixes does not change the status of actual bug
[10:51] <l2m> i can't see anything in trac
[10:51] <l2m> ok :)
[10:51] <bialix> it's just metadata inside bzr
[10:52] <l2m> not possible to fix in trac an opened bug ?
[10:52] <bialix> trac-bzr plugin does not process such metadata yet
[10:53] <bialix> in theory it's possible to close bug in trac via post-commit hook
[10:53] <bialix> there is special API in trac for this, xml-rpc IIRC
[10:53] <bialix> but in practice nobody wrote such hook yet
[10:53] <l2m> hehe ... :)
[10:53] <bialix> yep
[10:54] <l2m> ok so where looking for this guy ;)
[10:54] <l2m> we are sorry
[10:54] <bialix> imagine if you commit locally without access to trac
[10:54] <bialix> what should bzr do?
[10:54] <bialix> I mean offline
[10:55] <l2m> yep .. but in our case, we have all in local network
[10:55] <bialix> yes, but bzr don;t know this ;-)
[10:55] <l2m> so, many thanks for help bialix ... we gonna look for an other solution
[10:56] <bialix> if you find it, I'd like to know too
[10:56] <bialix> we're using trac at work too
[10:59] <l2m> wel .. so the fixes switch work well with launchpad or bugzilla .. or same limitations ?
[11:03] <bialix> lp don't change status of the bug
[11:03] <bialix> it just link the branch to the bug
[11:03] <bialix> so in lp this info used just as flag: here is branch where possible fix exists
[11:04] <bialix> as you can imagine the fix can be wrong or incomplete
[11:04] <bialix> that's basicall y main reason why bzr don't try to change the status of the bug
[11:08] <Anteru> hm, I cannot get bzr replay to work, complains about no WorkingTree
[11:41] <Anteru> vila: replay fails with conflicts?!?
[11:43] <vila> Anteru: for the merges ? Are they the same conflicts that you did resolve at that point in the past ?
[11:43] <Anteru> it fails on revision 40 or so
[11:43] <Anteru> that's in 2004, when we were using svn 1.0 or so
[11:43]  * vila summons quicksilver that played a lot with bzr-replay lately :-)
[11:44] <Anteru> I don't think we had conflicts back in that day :)
[11:44] <quicksilver> all I have to offer about bzr replay is that I could only make it replay simple revisions
[11:44] <quicksilver> that is, no merge involved.
[11:44] <vila> Anteru: may be you don't use bzr-replay with the right starting branch (don't start from origin but maybe just before the first merge)
[11:44] <maxb> yeah, no support for merges
[11:44] <quicksilver> if there is a way to make it do something sensible with merges I didn't find it.
[11:45] <quicksilver> I must finish that long email I was writing to the bzr list though
[11:45] <maxb> actually most of bzr-rewrite fares poorly if you ask it to rewrite a merge
[11:45] <Anteru> hm
[11:45] <Anteru> Seems my repository is totally hosed
[11:45] <vila> quicksilver: oh, finishing that mail ? Good idea :)
[11:45] <Anteru> It's not only ghost revisions that are missing. Just sent again to the ML :/
[11:46] <Anteru> Bah, that's a migration :(
[11:46]  * vila lunch time, bbl
[14:14] <jam> morning all
[14:14] <jam> hopefully irc will get sorted out...
[14:41] <vila> morning jam !
[14:50] <Lo-lan-do> Hi all :-)
[14:50] <rubbs> hello
[14:51] <Lo-lan-do> Question about bzr switch.  I have a lightweight checkout of ~/repo/branch, which is bound to bzr+ssh://remote/blabla/branch
[14:52] <Lo-lan-do> Is there a way to have "bzr switch otherbranch" switch to ~/repo/otherbranch rather than bzr+ssh://remote/blabla/otherbranch?
[14:55] <rubbs> I don't think so, the only way is to type out the whole path... on the other hand, I seem to remember reading something about intents...
[14:55]  * rubbs runs of to the documentation...
[14:57] <rubbs> mmm... seems like intents are more for shortcutting authorization to branch locations rather than shortcuting the branch locations themselves.
[14:57] <rubbs> you could make an alias...
[14:57] <rubbs> bzr alias otherbranch="~/repo/otherbranch"
[14:58] <rubbs> that way when you do your switch bzr will expand your path for you.
[14:58] <Lo-lan-do> Hm, yes, that would work if I had only one repo.
[14:58] <rubbs> ah.
[14:59] <rubbs> not sure what the best solution is.
[14:59] <Lo-lan-do> I have several branches named similarly, in the same repo, too.
[15:00] <Lo-lan-do> fusionforge/patches/$client1/fixes, fusionforge/patches/$client2/fixes, and so on.
[15:00] <rubbs> that makes sense. Does bzr switch ../otherbranch work?
[15:02] <Lo-lan-do> bzr: ERROR: Not a branch: "bzr+ssh://remote/blabla/otherbranch/".
[15:02] <Lo-lan-do> So, no.  But nice try :-)
[15:04] <Lo-lan-do> Uh, it's even worse, actually, it's bzr+ssh://remote/bla/otherbranch/ , with bla being blabla/.. (blabla's parent dir)
[15:06] <rubbs> mmm...
[15:07] <Lo-lan-do> I'm fetching the source, I'll see if I can add a parameter to change the default behaviour.
[15:07] <rubbs> that might work.
[15:07] <rubbs> I'm out of ideas other than that.
[15:07] <rubbs> unless someone like jam or vila have an idea.
[15:08] <jam> Lo-lan-do: bug #506177
[15:09] <jam> basically, while 'bzr switch $PATH" defaults to switching the lightweight checkout before the bound branch the "bzr switch local" lookup does the bound branch lookup first
[15:09] <jam> for now
[15:09] <jam> use bzr switch ~/repo/otherbranch
[15:10] <Lo-lan-do> I see.  Thanks for the pointer.
[15:12] <Lo-lan-do> Oooh, colocated branches now!
[15:21] <Glenjamin_> hi guys, is there any plan for a os x 10.5 installer for the newer versions of bzr?
[15:35] <Glenjamin_> or, a more relevant question - how do i use bzr-keychain?
[15:35] <Glenjamin_> it appears to have installed correctly and is in the plugins list
[15:35] <Glenjamin_> but i have no idea how to make it prompt for keychain access
[15:36] <Lo-lan-do> Does "bzr help keychain" say anything?
[15:38] <Glenjamin_> "Use the Mac OS X keychain as a credential store for authentication.conf."
[15:39] <Glenjamin_> bzr 2.0.1 btw
[15:48] <Lo-lan-do> Glenjamin_: No idea from me, actually.  I'm not a Mac user, I was just suggesting.
[15:49] <Glenjamin_> no worries
[15:49] <Glenjamin_> bzr-svn can read plaintext stores from svn fine - but doesnt seem to be able to read from the svn keychain store :s
[15:59] <vila> Glenjamin_: I think jfroy know about bzr-keychain, let's try to summon him
[16:12] <Glenjamin_> i'm guessing jfroy is the bzr-svn guy?
[16:12] <vila> jam: can you review https://code.edge.launchpad.net/~vila/bzr/per-file-merge-hook/+merge/17754 ?
[16:12] <vila> Glenjamin_: no, it's the bzr-keychain guy :)
[16:12] <Glenjamin_> oh
[16:12] <Glenjamin_> thats works too :)
[16:19] <jam> vila: I'll try to take a look at it today
[16:21] <vila> jam: thanks, unless you object, it would be nice to include it in rc1 since there seems to be agreement that it's low risk
[16:22] <vila> jam: but I will *not* push more since it needed to be completed at the last minute by the pp instead of the original author...
[16:24] <vila> jam: hmpf, passport, damn
[16:25] <jam> vila: already approved
[16:25] <jam> yeah passport thing is just strange
[16:25] <jam> for whatever reason neither of us connected the dots until it was in the mail
[16:27] <jam> anyway, I'm going to head to a coffee shop for a while, I'll see if I have net access there
[16:27] <vila> jam: small error big consequences... :-/ We will miss you if you can't make it :-/
[16:27] <vila> jam: huh ? What about your expresso machine ?
[16:30] <Lo-lan-do> I was going to ask what's new in 2.1, but reading the release notes, I'm sold already.
[16:30] <Lo-lan-do> "bzr unshelve --preview" is something I've wished for quite some time :-)
[16:32] <Glenjamin_> anyone around who works on bzr-svn? i'm looking at the authentication code, and it appears to have hooks into all the subverpy auth providers, but not use any of them in the Credential Store implmentation
 AnMaster: A ghost is a revision that exists but bzr is not aware of its content <-- wrong nick?
[17:08] <vila> AnMaster_: yeah, sorry about that
[17:09]  * vila lectures Xchat: see ? Can't you check which nick you propose !
[17:11] <AnMaster_> vila, for xchat iirc you can set "most recently to speak completed first" kind of thing
[17:12] <vila> which I did AFAIR, let me check
[17:12] <vila> here we go, lost setting...
[17:12] <vila> AnMaster_: thks for the heads-up
[17:14] <AnMaster_> vila, if you use /set iirc you have to save it by some other command
[17:14] <AnMaster_> was a while ago I used xchat last
[17:15] <vila> AnMaster_: I track changes on the  xchat.conf file.... at least I was but somehow my setup has been broken :-/
[17:15] <AnMaster> mhm
[17:18] <vila> ha, got it, xchat creates a new xchat.conf when some pref is modified which breaks my tracking :-/
[18:42] <Tak> what happens when one bzr unbinds a lightweight checkout?
[18:45] <fullermd_> One doesn't; the operation doesn't make sense.
[18:46] <fullermd_> unbind operates on a branch, not a checkout.  So what would happen would be that it would perform that operation on the branch you have a lightweight checkout of, which is statistically probably not bound in the first place.
[18:47] <Tak> ok
[18:47] <Tak> that's what I figured
[18:48] <Tak> although I kind of hoped that it would create an alternate universe where magical unicorns would keep track of my local revisions until it was time to rebind
[18:50] <keithy> hi
[18:50] <keithy> How can I debug a bzr+ssh connection
[18:51] <keithy> the sftp connection works
[18:51] <Tak> is bzr installed on the remote side?
[18:52] <keithy> yes
[18:54] <fullermd> Tak: Magical unicorns were going to be in 2.1, but the patch was rejected for not having tests   :(
[18:56] <Tak> meh, I'm still running 2.0.3 anyway
[18:56] <Tak> keithy: what kind of error are you getting?
[18:56] <keithy> if I ssh to the mc, I can run bzr
[18:58] <keithy> bash: bzr: command not found
[18:58] <keithy> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[18:58] <mwhudson> keithy: where is bzr on the remote machine?
[18:58] <mwhudson> if it's not in /usr/bin, /bin or just a very few other places you might have to set BZR_REMOTE_PATH
[18:59] <keithy> hmm
[18:59] <keithy> doesnt the Mac os x installer do the right thing?
[18:59] <mwhudson> no idea!
[18:59] <mwhudson> log in and 'which bzr'
[18:59] <keithy> its in /usr/local/bin/bzr
[19:00] <mwhudson> yeah, that's probably not in the default path from ssh
[19:01] <mwhudson> you can set the path as an environment variable or in the config
[19:01] <keithy> but if I use ssh manually it is
[19:02] <mwhudson> it's probably in some file your shell executes
[19:02] <keithy> k
[19:03] <mwhudson> there's no shell involved if you run ssh $host bzr
[19:03] <keithy> ok Ill try that
[19:03] <mwhudson> if bzr+ssh fails, that will fail
[19:04] <keithy> yep bingo
[19:04] <Tak> sweet, I'm up to 1g memory used for a lightweight checkout
[19:04] <Tak> I hope it's over 50% done...
[19:05] <keithy> ok so... someone needs to tell the mac os x installer people that their move doesnt work
[19:05] <keithy> it used to be in /usr/bin/bzr
[19:07] <fullermd> Er.  Yes there is a shell involved...
[19:08] <fullermd> bash will read different rc files for an interactive vs. non session though, so you may need to set $PATH somewhere else.
[19:12]  * Tak Out of memory - terminating application.
[19:12]  * Tak cry
[19:12] <keithy> ouch
[19:19] <lifeless> Tak: what bzr version ?
[19:21] <Tak> 2.0.3
[19:42] <lifeless> hi jam
[19:46] <jam> hi lifeless
[19:47] <jam> you seem to be up early
[19:47] <lifeless> I'm in NZ
[19:47] <jam> is LCA in a differnt T?
[19:47] <jam> ah
[19:47] <lifeless> abentley: could you link the branch to review, I can't find it in mail./
[19:49] <abentley> lifeless: https://code.edge.launchpad.net/~abentley/bzr-pqm/lpland/
[19:51] <jam> lifeless: you seem to be having a good time at LCA
[20:18] <igc> morning
[20:36] <keithy> hi
[20:37] <keithy> how to you set access rights to a repo
[20:37] <keithy> or make it read only?
[20:37] <keithy> for checking out only
[20:38] <Lo-lan-do> keithy: I usually stick it into a location accessible through HTTP.
[20:39] <keithy> hmm
[20:39] <keithy> is there a checkout readonly?
[20:39] <Lo-lan-do> Meaning?
[20:40] <keithy> if people use that then there is no chance of them accidentally checking in
[20:40] <keithy> i.e. deploy
[20:41] <Lo-lan-do> Well, no, the plain HTTP server only has read access to the files in the repo.
[20:41] <keithy> I set up ssh
[20:41] <keithy> and bzr+ssh
[20:42] <keithy> setting up http is a pain.
[20:42] <keithy> can I just chmod it
[20:42] <Lo-lan-do> You can chmod -R the repo, yes.
[20:43] <keithy> k, thall have to do
[20:43] <Lo-lan-do> That's how I do access control on my repos: each project has its group, and the repos are chgrped+chmodded.
[20:43] <Lo-lan-do> So only members of group foo can commit to repo foo.
[20:43] <keithy> k
[20:44] <Lo-lan-do> Others can read only, or nothing, some repos are private (and therefore rwxrws---).
[20:47] <Lo-lan-do> keithy: There's an administrator's guide on the website, as I found out today, with interesting points about common problems.
[20:48] <keithy> k ty
[23:00] <Glenjamin_> is there something other than the -D flags i need to use to get debug information?
[23:00] <Glenjamin_> "bzr -Dhttp -Dauth update" isnt giving me any additional output
[23:03] <lifeless> check ~/.bzr.log
[23:03] <Glenjamin_> yeah, i realised that now, unfortunately it hasn't enlightened me on the problem at all :(