[00:48] <RyNy_> How do I connect from my local machine via ssh with a key to my remote server?
[00:48] <igc> hi all
[00:59] <lifeless> hi igc
[01:00] <igc> hi lifeless
[01:00] <igc> lifeless: back in Oz?
[01:16] <lifeless> nope
[01:16] <lifeless> platform sprint in portland
[01:31] <spundun> hi all
[01:32] <spundun> I'm on mac snow leopard and I tried to install bazaar
[01:32] <spundun> through the .pkg file
[01:32] <spundun> but I can't find anything installed
[01:32] <spundun> what files am I looking for?
[01:33] <spundun> I can't find anything called qbzr
[01:34] <spundun> the file I downloaded is Bazaar-2.0.4-1-desktop.pkg
[02:54] <RyNy_> I got it to work on 10.5.8. I'd do a google search. i came across support for 10.6 somewhere recently
[03:11] <spundun> RyNy_: I got the 10.6 binary from here: http://wiki.bazaar.canonical.com/MacOSXDownloads I thought it'd work
[03:13] <spundun> 10.6 seems to be officially supported by bazaar, from what I gathered from the link above.
[03:13] <spundun> I think the problem is with their packaging.
[03:13] <spundun> maybe the install script is failing somehow
[03:13] <RyNy_> spundun: I've really been strugging with bzr on my mac here. I got shell integration and after much struggle got the GUI, Explorer to work. But I can't figure out how to ssh to my server with a private key. I just found out that there is a plugin for Eclipse IDE
[03:13] <RyNy_> Have to say their documentation is really lacking
[03:14] <spundun> I'm trying to install the macports version in parallel
[03:14] <spundun> which one did you get working?
[03:14] <RyNy_> For the GUI I got Explorer working
[03:15] <RyNy_> I posted this help doc: https://answers.launchpad.net/bzr/+question/99421
[03:15] <spundun> thanks, I'll lok at it.
[03:15] <spundun> gtg now.
[04:51]  * igc out for a bit - bbl
[09:01] <yojimbo-san> In a pre_commit hook, how can I determine the absolute filename of an item from tree_delta?
[09:07]  * igc dinner
[09:46] <Kamping_Kaiser> bugger, bzr-builddeb contains cia commands
[09:47] <Kamping_Kaiser> no, my checkout isprobably broken
[09:48] <Kamping_Kaiser> no, my checkouts brokeen
[09:48] <Kamping_Kaiser> pebkac as usual :)
[11:27] <jelmer> lifeless: is bazaar's pqm using the NEWS conflict resolver yet?
[12:10] <quicksilver> doh. my subscription attempt expired
[12:10] <quicksilver> apparently you're not allowed to wait two weeks before cliking the link
[12:53] <asabil> hi all
[12:53] <asabil> is there any hook for when the working tree is updated ?
[12:54] <asabil> to be able to fix this bus: https://bugs.launchpad.net/bzr-externals/+bug/485494
[14:39] <maxb> asabil: `bzr hooks`
[14:39] <maxb> Which, uh, crashes for me. Nice.
[14:39] <asabil> same here
[14:39] <LeoNerd> Me too
[14:39] <LeoNerd> bzr: ERROR: exceptions.AttributeError: 'InfoHooks' object has no attribute '_callable_names'
[14:39] <asabil> same error
[14:40] <maxb> ah well, `bzr --no-plugins hooks`
[14:40]  * maxb plays hunt the evil plugin
[14:40] <asabil> maxb, yep, and there is not hook for when the tree is updated
[14:41] <maxb> !blame bzr-svn
[14:41] <jelmer> maxb: It's a bug in bzr
[14:42] <jelmer> maxb: it just happens to only be activated when there's more than one hook loaded
[14:42] <maxb> oh. yuck :-)
[14:56] <napster> If there are more than one developer, how the source code is managed? I'm new to bzr too...
[14:59] <maxb> napster: Try this document for an introduction to some of the possible ways to work: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/bazaar_workflows.html
[15:00] <napster> maxb, just got it from #launchpad... tnx anyway... ;)
[15:04] <keithhub> i've got a bzr checkout of trunk from a svn repo -- if i make a commit on the bzr branch, should i be able to see the subversion revision assigned?
[15:14] <radoe> If I have a branch of a svn repo by the help of bzr-svn, is there any way to have tags in this bzr branch and push commits back to the svn repo? I have no need to push the tags back, the can be bzr-only.
[15:17] <jelmer> radoe: bzr branch will automatically pick up the tags if you use the standard trunk/branches/tags layout in svn
[15:18] <jelmer> radoe: and bzr-svn supports pushing back into svn
[15:21] <radoe> jelmer: maybe I misinterpreted this error message: bzr: ERROR: Tags not supported by SvnBranch('file:///home/ralf/SVNREPO/bzr-test'); you may be able to use bzr upgrade.
[15:21] <jelmer> radoe: in that situation, bzr-svn doesn't know where to push tags to
[15:36] <jelmer> radoe: you need to tell it the layout of the svn repo before you can push
[15:38] <RyNy_> Anyone know how to connect using ssh and a private key to a server?
[15:38] <mzz> RyNy_: on what os? on linux bzr should end up just invoking ssh, so if that is configured to do so, so will bzr
[15:39] <mzz> RyNy_: configuring an alias in ~/.ssh/config for the host and options you need may be necessary, I think
[15:49] <lifeless> jelmer: no
[15:49] <lifeless> jelmer: 2.1.0 isn't released yet:P
[15:53] <RyNy_> mzz: sorry, I meant to say in the GUI Explorer. I currently have an alias ~/.ssh/config. I'm on OS X
[15:53] <RyNy_> I did install paramiko too
[15:54] <mzz> RyNy_: sorry, I know virtually nothing about mac
[15:57] <radoe> jelmer: may I request your help than? For tests I start with an empty svn repo with standard tags/trunk/branches layout, see http://pastebin.ca/1774416 what I did exactly...
[15:59] <radoe> jelmer: I created a bzr repo with svn-import, tagged trunk and simply tried to push it back.
[16:00] <jelmer> radoe, that looks correct
[16:00] <jelmer> radoe, the push command you mentioned earlier didn't push to /trunk though
[16:01] <radoe> jelmer: Yes, the earlier one was a different test, after your hints I created a svn test repo in tags/trunk/branches layout and tried again.
[16:05] <radoe> jelmer: ahh, I see. The tag in fact *gets* pushed back to to svn, even "bzr push" does emit a message "No new revisions to push.". After this message at first I thout nothing has happened during the push...
[16:12] <radoe> jelmer: sorry for the confusion with two different tests. And after the "No new revisions to push" message in my second test I simply did not expect that anything had happened...
[16:12] <jelmer> yeah, bzr's UI probably should mention the number of changed tags or something like that
[16:13] <radoe> jelmer: exactly.
[16:18] <RyNy_> mzz: no worries. Anyone have any experience with Bazaar Explorere?
[17:34] <DaffyDuck_`> How do I get an old revision of a file?
[17:37] <DaffyDuck_`> Ah, "cat".
[17:40] <yjmbo> In a pre_commit plugin, how do I get the full pathname of a file from tree_delta?
[17:42] <jelmer> yjmbo: I think you can feed it to the abspath() method on the working tree that you have
[17:49] <james_w> wasn't there a "bzr-land" plugin that did a merge and put the parents the other way round to normal?
[17:49] <james_w> I would like to make use of it
[17:53] <lifeless> mthaddon: https://lpstats.canonical.com/graphs/LaunchpadOpenBugs/ is showing zero for the lp code bugs
[17:53] <lifeless> mthaddon: I suspect it doesn't refer to 'launchpad-code' instead using the old launchpad-bazaar or something
[17:58] <maxb> james_w: I thought it was conjectured, not written?
[17:59] <james_w> maxb: that may be right, thanks
[18:04] <jelmer> vila: hey
[18:04] <jelmer> vila: The merge proposal you just put up has a conflict in NEWS
[18:04] <lifeless> james_w: wed morning or afternoon ?
[18:05] <jelmer> vila: oh, and it's set to Rejected now - ignore me :-)
[18:05] <vila> jelmer: how ironic :D
[18:05] <jelmer> vila: :-)
[18:06] <james_w> lifeless: morning suits me fine
[18:12] <lifeless> james_w: scheduled in for me
[18:13] <james_w> thanks
[18:53] <mattl> hey... is there a way i can have every checkin send an email to a list?
[18:53] <mattl> without configuring something on the client
[18:54] <rubbs> mattl: try this under change notification: http://wiki.bazaar.canonical.com/BzrPlugins
[18:56] <mattl> rubbs: is that something each developer would need to install though?
[18:58] <rubbs> mattl: you could create a smart server that has something like that installed, if you need something with a little more beef you could try PQM (in the section right below change notification)
[18:59] <rubbs> mattl: also look at this for your "server" http://doc.bazaar.canonical.com/test/en/admin-guide/hooks-plugins.html
[19:00] <mattl> i have a site that checks out the trunk every 5 mins... i wonder if i could just add something to that
[19:02] <rubbs> mattl: it shouldn't be too hard to use hooks for that then. I'll dig up the link
[19:04] <devmod> Hello
[19:04] <mattl> rubbs: thanks.
[19:04] <mattl> devmod: hey
[19:05] <rubbs> mattl: http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/hooks-help.html?highlight=hooks
[19:05] <rubbs> devmod: hello
[19:06] <devmod> I was reading the bzr user guide, and I am not sure I understand "Backing up task branches", where do u exactly back this up?
[19:14] <rubbs> devmod: can you send a link to the page that you are talking about?
[19:15] <devmod> rubbs, http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/organizing_branches.html
[19:15] <devmod> last paragraph
[19:15] <devmod> basically, i want to be able to keep  a copy of my task branches somewhere (to access it from my laptop maybe? to sync between dev machines, and as a backup)
[19:16] <rubbs> I'm not entirely sure of the best way, but you could create a different location for your task branches in a central location and bind to them.
[19:17] <lifeless> mattl: you can install bzr-email on the server
[19:17] <rubbs> I'm not sure if anyone else here has a better idea.
[19:17] <lifeless> mattl: and as long as you use bzr+ssh it will Just Work
[19:18] <devmod> maybe im just too svn minded
[19:19] <devmod> everyone doesnt mind having only local copies of in-progress fixes ?
[19:20] <rubbs> devmod: if I have a long term branch. I'll push it to a central location( like LP) and keep it there under it's own branch
[19:20] <rubbs> but to be honest, my workflow is such that my fix branches are very short lived (a few commits at most)
[19:21] <devmod> yeah that is what i was thinking as well
[19:22] <devmod> not sure how bazaar would apply to new projects in which tasks are going to be considerably longer
[19:22] <rubbs> I'd just push those up to the back-able location in a seperate directory.
[19:22] <rubbs> keep them in a similar location, but ultimately separate
[19:23] <devmod> and then when u want to go back to the original repo , u just merge back ?
[19:23] <rubbs> yep
[19:23] <rubbs> so for example:
[19:23] <devmod> (new to bzr in general, so exact cmds escape me atm)
[19:23] <rubbs> you have a shared repo that contains trunk.
[19:23] <rubbs> next to trunk is task1 and task2
[19:24] <rubbs> when you are done with task2, you go into main and do a "bzr merge task2"
[19:24] <rubbs> and that will merge all your changes from task2 into trunk/main
[19:24] <rubbs> (sorry used two different names there but meant trunk the whole time)
[19:24] <devmod> yes
[19:24] <rubbs> (instead of main)
[19:24] <rubbs> is that what you mean?
[19:24] <devmod> and to create then? starting from trunk?
[19:25] <devmod> (im confused about the "unbind" part)
[19:25] <rubbs> yeah, so to start you would (from just outside of the trunk dir) "bzr branch trunk task3"
[19:25] <rubbs> well, with this workflow, you can more or less forget the bind
[19:25] <rubbs> you just have to push and pull to your local...
[19:26] <devmod> ohh ok
[19:26] <rubbs> is this making sense at all?
[19:26] <devmod> i believe so
[19:26] <devmod> it almost feels liek it wasnt intended to work that way
[19:27] <rubbs> bzr is really fexible by design. There isn't a whole lot that it wasn't intended for.
[19:28] <devmod> and when i merge the branch back into the trunk, will the trunk now contain all log info from the branch as well?
[19:28] <rubbs> As long as you stick true to using bzr as only a history tracker, and not a content delivery system, then you pretty much are using it as designed ;)
[19:28] <rubbs> yes,
[19:28] <rubbs> this is the beauty of bzr (and hg and git too)
[19:28] <rubbs> you keep ALL your history
[19:28] <devmod> i see
[19:29] <rubbs> if you want to see what that looks like you can run a log command on the bzr branch on lp.
[19:29] <rubbs> so if you have qlog installed (default on windows and apt-get install qbzr on Ubuntu) you can run "bzr qlog lp:bzr"
[19:30] <rubbs> that will open a gui window and show you what a typical log looks like for a merged branch workflow similar to what we are talking about
[19:31] <devmod> i see
[19:31] <rubbs> if you give me a few minutes I can whip up a short tutorial on how to work it for you...
[19:32] <rubbs> on the workflow we discussed, and then we can tweak it to fit your needs
[19:32] <devmod> i was just wondering what workflow fit our approach the best
[19:32] <devmod> we used to use svn
[19:32] <devmod> so i have this concept of making branches for my own dev which are backed up somewhere
[19:33] <rubbs> so you need some sort of central place (backup and collaberation) and you want to be able to use local commits, but have the option to back them up too, right?
[19:33] <devmod> right
[19:34] <rubbs> ok, cool. give me about 5 minutes, I'll whip up something, and you can review it. Then we can see if we can tweak it to make it best for you and your needs. does that work?
[19:34] <devmod> absolutely thanks
[19:34] <rubbs> np... brb
[19:35] <bjp> hey, is there a workaround for this bug: https://bugs.launchpad.net/loggerhead/+bug/447229/
[19:50] <Peng> bjp: Well, you could use "bzr branch nosmart+http://whatever"
[19:51] <rubbs> devmod: http://pastebin.com/m3000dec2
[19:51] <rubbs> not very pretty but you should be able to figure it out.
[19:52] <Peng> bjp: I thought that had been fixed, and I can't reproduce it with Loggerhead's trunk.
[19:52] <devmod> rubbs, thanks!
[19:52] <rubbs> np
[19:54] <Peng> bjp: Have you experienced the bug yourself? Can you try upgrading to Loggerhead's trunk (lp:loggerhead)?
[19:54] <bjp> Peng: nosmart+http gives me another No repository present error
[19:54] <bjp> yes i'm working on getting around the bug right now
[19:55] <bjp> I haven't tried using the trunk, can i run serve-branches from the branch directory w/out installing it?
[19:55] <Peng> bjp: bjp Yes.
[19:56] <bjp> new error: "An attempt to access a url outside the server jail was made"
[19:56]  * Peng dies.
[19:56] <bjp> wait let me try something
[19:57] <mwhudson> bjp: what version of bzr are you running?
[19:57] <mwhudson> that sounds like a no-fixed bug in bzr
[19:57] <bjp> 2.0.4
[19:57] <mwhudson> hmm
[19:59] <Peng> bjp: What's the path of your repository, and what's the path you're having Loggerhead serve?
[20:00] <bjp> i just tried serving the root of the shared repository /opt/repository
[20:00] <rubbs> devmod: I'll brb, so if you have questions for me, go ahead and ask, but it may be a minute or two before I respond. Just FYI.
[20:09] <lifeless> mthaddon: Chex: are either of you on duty atm ?
[20:09] <devmod> rubbs, sure np thanks again
[20:09] <lifeless> we need the review team for  https://code.edge.launchpad.net/~bzr-pqm/bzr/2.1 set to bzr-core please
[20:15] <rubbs> devmod: back fyi
[20:17] <lifeless> elmo: https://code.edge.launchpad.net/~bzr-pqm/bzr/2.1
[20:17] <bjp> i also tried using loggerhead as a plugin with 'bzr serve --http' but got this bug: https://bugs.launchpad.net/loggerhead/+bug/492614
[20:18] <lifeless> elmo: set the 'review team' to ~bzr-core please
[20:18] <elmo> lifeless: done
[20:19] <lifeless> sweet, thanks
[20:20] <yjmbo> Can someone give me a bit of pre_commit plugin help? I am passing tree_delta path names to an external command, but I need absolute pathnames; where do I find the correct prefix?
[20:21] <mkanat> yjmbo: I think it's in branch._transport.base.
[20:21] <mkanat> yjmbo: If you want the branch path.
[20:22] <yjmbo> yep, that sounds plausible ... let me try it ...
[20:28] <yjmbo> mkanat: ok, as a complete newbie to bzr plugins, how do I get that value? "print branch._transport.base" gives "'module' object has no attribute '_transport'"; I cargo-culted "branch.Branch._transport.base" by looking at the hook registration, but I get "type object 'Branch' has no attribute '_transport'" ... I know I'm missing a large chunk of assumed knowledge, but what is it? :-)
[20:29] <bjp> Peng: are you able to get it to function correctly with a shared repository?
[20:29] <mkanat> yjmbo: params.branch
[20:29] <mkanat> yjmbo: That's the branch object.
[20:30] <Peng> bjp: Yes.
[20:30] <mkanat> yjmbo: It might be params.branch.repository._transport.base. I don't recall off the top of my head.
[20:30] <mkanat> yjmbo: Also, I think that the assumed knowledge is the bzrlib API docs.
[20:31] <bjp> Peng: i posted a comment on that bug, how is your setup different?
[20:31] <yjmbo> :-) I've tried for a while, that's a lot of docs with very few examples! However, I'll try some more until I get it. I looked at a load of plugins, but even the ones that seem to be doing the same task as me are far more complex, and doing things in a far different manner ...
[20:37] <Peng> bjp: The fix for that jail bug landed in bzr 2.1.
[20:38] <Peng> bjp: (It's bug #348308, FYI.)
[20:39] <mwhudson> Peng: oh, that's sucky
[20:39] <Peng> mwhudson: What?
[20:39] <mwhudson> i guess at least 2.1 is nearly out
[20:39] <mwhudson> Peng: that the jail bug isn't fixed in the 2.0 branch
[20:39] <Peng> MaAh.
[20:39] <Peng> Ah.*
[20:40] <Peng> Mann, I don't want to be dealing with these bugs anymore. I'd even forgotten most of that bug number!
[20:41] <Peng> (It's not because of that, but I'm going AFK.)
[20:52] <devmod> rubbs, that was pretty clear :) One last thing, to update my task branch I merge the trunk into it ?
[20:54] <rubbs> devmod: yes and no. If you need to get something from trunk, then yes, you merge the trunk into it, but because you merge branches you don't need to update your working tree the same way you do when you work with SVN.
[20:54] <rubbs> when you merge, it merges your changes into the trunk... even if the trunk is further ahead than you are
[20:54] <rubbs> if there are conflicts it will tell you and then you resolve them... very similarly if you were using SVN
[20:54] <devmod> ohh i see
[20:55] <rubbs> so, merging the trunk in to update is usually unnecessary
[20:58] <rubbs> hopefully that makes sense
[21:39] <bjp> shewt, that means i needs 2.1
[21:39] <bjp> and there prolly aren't any .deb packages of it yet
[21:41] <rubbs> http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu there is a 2.1 ppa
[21:41] <maxb> There is a PPA which is supposed to contain 2.1 but does not, you mean :-/
[21:42] <rubbs> oh, I didn't know.
[21:42] <rubbs> maybe the nightly one?
[21:42] <rubbs> seems like that would be risky though
[21:43] <maxb> I'd imagine that ought to be 2.2 by now
[21:43] <bjp> heh yea, i'm running this on my server box
[21:43] <bjp> i don't update it a lot, but bzr is one of it's main functions, so i'm not sure if the daily ppa would be a good idea or not
[21:44] <rubbs> seems weird that the beta ppa doesn't have 2.1... since it's in beta. Is someone working on that?
[21:44] <maxb> I made noises that I might, if I get some time
[21:45] <maxb> No one said they were working on it
[21:45] <rubbs> damn
[21:46]  * maxb afks
[21:47] <bjp> the topic says 2.1rc is gold ><
[22:06] <asabil> hi all
[22:06] <asabil> what is actually missing to add support for nested trees ?
[22:35] <lifeless> asabil: engineering time
[22:35] <lifeless> asabil: probably several weeks at a minimum of a practiced dev
[22:35] <asabil> lifeless, I see
[22:36] <lifeless> the actual specifics of what hasn't been imlementedI don't recall offhand
[22:39] <mathrick> hiya, I was just branching trying the famous Emacs repo, and it is indeed very resource-intensive, even on 2.0.3, which is already supposed to be much better
[22:40] <mathrick> so how come it hits over 500M resident mem with mostly linear history? Does bzr need to keep the whole tree in memory when branching?
[22:48] <lifeless> mathrick: do you have the C extensions?
[22:52] <mathrick> most probably, any particular package I should look for?
[22:53] <lifeless> python -c 'import bzrlib._dirstate_helpers_pyx'
[22:54] <mathrick> no errors, so yes I guess
[23:07] <mathrick> lifeless: so, is it supposed to take less with C extensions?
[23:07] <lifeless> much less
[23:08] <lifeless> unfortunately jam isn't online at the moment, he has been doing the most memory use analysis
[23:09] <lifeless> linear history doesn't really matter either way; its likely just the size of the data set in use: we write indices at the end of the process.
[23:11] <mathrick> lifeless: aha, so no hope for, umm, just pulling things and dumping them to disk?
[23:11] <lifeless> oh we do for the bulk of data
[23:11] <lifeless> but the indices are written at the end
[23:11] <mathrick> I see
[23:12] <lifeless> we're reducing memory use release by release though
[23:12] <lifeless> you might try 2.0.4
[23:12] <mathrick> I know, previously it was known as the pull that would kill your machine without fail :)
[23:12] <mathrick> so 2.0.x are already better in that it works and fits in some 550M and generally finishes in a reasonable time
[23:19] <lifeless> poolie: are you up ?