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