[01:07] hi. i've added a previously bzr-version-controlled folder underneath my project root to my .bzrignore. moving forward, the ignore works fine, as expected, what's the bzr cmd to remove/purge that now-ignored-subfolder's version history ? staring at the silly man page, i'm missing it ... [01:08] there is none [01:08] if you mean "I'd like to erase from history going all the way back to the beginning of time", that is [01:08] if you just want to del it, rm [01:09] bob2: hi. rm what? not the directory, i presume ... [01:09] or? [01:09] ? [01:09] if you want to delete the directory and then commit, rm it [01:09] no, i want to keep the directory, in place, just not have it bzr-tracked ... [01:09] bzr rm --keep [01:10] aha! bingo, i think! [01:10] perfect, thanks. [04:39] i thought bazaar commits were local, but I just committed something and it went straight to launchpad (no push required). What's going on? [04:41] how did you branch ? [04:42] I did a bzr checkout of the thing I wanted to work on in lp. [04:43] Commits aren't "local", they go to whatever branch you're working on. When you run 'checkout', you're not making a new branch, just a new working tree on the existing branch. [04:43] So that's the expected outcome. [04:43] fullermd: beat me to it :p [04:43] If you want the new revs to not go there, you'll want to make a new branch for them using 'bzr branch'. [04:44] hmm [04:44] that seems like it would then require me to merge, though [04:44] * fullermd swoops in and ninjas away the credit :p [04:44] hehe [04:44] Well, if whatever you do leads to divergeance, there's no way around merging whatever you do. [04:44] naturally [04:45] but it seems that this requires an extra step... I'd like to just have some commits queued up and then push them [04:45] obviously the server would require me to pull and merge if when I push I'm out of date [04:45] That would be what you'd do with the new branch... [04:45] but then I'd have to have another checkout lying around of the main branch and merge my branch into it, right? [04:46] That would be a way to go, yes. [04:46] are there other approaches? [04:46] I'm hoping there's something I'm missing... I like hg's approach to this [04:46] If you don't have divergeance, you could just push from your branch. If you (and probably more important, the upstream project if it's not just "you") don't care about pivoting the mainline around, you can just merge-push in place. [04:47] I see... so if I make a personal branch, I can then push straight into the main branch (and that would save the push location?) [04:48] hg's approach is the latter. The reason it's off the beaten path in bzr is that it screws with the mainline. hg doesn't use the mainline concept, so the objection there is null. [04:48] so what is the 'bzr way'? I'm happy to try a new approach [04:49] The bzr way would be to either just push like that if there's no divergeance, or merge/commit into a checkout if there is (or if you want to merge anyway) [04:50] I see. [04:50] ok, I'll try the 'separate branch and push into mainline' approach. Thanks for explaining. [04:51] I recognize your nick from somewhere. perhaps #postgresql? [04:52] Probably not. I've used Postgres for years, but I've never been in an IRC chan about it... [04:52] ah, k. Who knows, then. :) [04:53] You may find some of the stuff at useful. The RevNumbering and RevHandling docs talk about some of the stuff underlying which way you merge and its effects. [04:55] so if there's a branch on lp, let's say lp:~foo/bar/baz ,when I *branch* it is that in effect making a local-only branch of the server-side branch? [04:55] but when I checkout, my local state always completely mirrors the server state and that's why checking in causes a push? [04:56] Accurate enough, yah. [04:56] I see. The 'branch' terminology seemed like the wrong thing to do after my experience with git, svn and hg [04:58] You could translate it like a 'hg clone'. Not an exact correspondence, but... [04:58] yeah, i understand that now [05:03] ok, next question -- bzr pull takes *forever*. is this because lp is slow? [05:03] or is it always this bad [05:04] Well, lp isn't per se fast... Like any server, it's sure to be slow if you're talking over http though. [05:04] if the 'parent branch' is what i should be looking at, it's bzr+ssh [05:05] Yeah, that would be relatively better. [05:06] LP has never been impressively fast for me. Rarely found it painfully slow. Though I don't offhand remember the last time I used it for anything but bzr. [05:09] Anyway, I gotta go. I have an urgent appointment with my recliner and not-moving. [05:09] sounds good. :) Thanks again. === marienz_ is now known as marienz [22:59] Good morning [23:00] Hello [23:00] I need advise [23:02] Hi Tsu [23:04] I would like to run Bazaar on a NAS running this: "Linux version 2.6.22.18 (wyc@SWTEST3) (gcc version 4.2.1) #22 Mon Aug 30 19:09:34 CST 2010" [23:04] Hi Spiv [23:04] Is it possible? [23:04] I have python already installed. [23:05] If you have python already installed, then it should be possible. [23:05] I've install Python-2.5.4-2 [23:06] Although do you need to install Bazaar on the NAS? Bazaar works fine over e.g. SFTP [23:06] I would like to run bazaar as a smart server on the nas [23:06] Ah, ok. [23:06] That's a new enough Python, so that's fine. [23:07] I was checking the available packages... [23:07] Is the NAS based on Ubuntu or Fedora or something like that? If it is, I'd probably try a Bazaar package for one of those. [23:07] Otherwise installing from the source tarball should work fine. [23:08] Nope... I don't think so [23:09] Yes, I was checking the source tarball... [23:10] http://wiki.bazaar.canonical.com/InstallationFaq may help you [23:15] hey spiv [23:15] how's your day? [23:18] Thank you for the instalation FAQ... [23:18] Ok, I don't have Crypto nor paramiko [23:19] jelmer_: good so far, but it only just started :) [23:19] But I have xml.etree.cElementTree.. [23:19] Tsu: paramiko is only needed for the client, not the server, I think. [23:20] Tsu: ditto Crypto [23:20] Hmmm... ok :D [23:21] Better that way [23:21] :D [23:21] (paramiko is needed for the client to access sftp:// URLs, paramiko+Crypto is needed for bzr+ssh and sftp if you don't have a system ssh client installed) [23:22] excellent [23:25] spiv, another question. [23:26] Do you know if the mercurial plugin is going to be updated to the latest bzrlib? [23:27] Tsu: bzr-hg trunk should work with current bzrlib [23:28] ok. [23:31] jelmer: Hi, what do you think about adding a subvertpy-daily recipe build? (To unblock bzr-svn dailys) [23:31] maxb: there is one [23:31] oh [23:31] * maxb looks closer [23:31] although I did only add it recently :) [23:32] maxb: https://code.launchpad.net/~bzr/+recipe/subvertpy-daily [23:32] ah, good [23:32] Also, I'm wondering what to do about bzr-explorer daily for karmic [23:32] It's currently broken because xvfb in karmic is broken unless you additionally Build-Depend on xauth [23:33] urgh [23:33] We could cheat, and add that extra Build-Depend to the unstable branch, or we could add a daily-ppa branch just for this, or we could just shrug, and abandon karmic for this package [23:33] I guess we can add a branch to the recipe that adds that dependency? [23:37] hmmm... what's "distcc"? [23:37] ugh, dependency hell... subvertpy-daily failing because of missing python-pydoctor [23:37] maxb: just fixed that :) [23:37] Tsu: A distributed C compiler [23:38] Tsu: an neat tool for distributing compilation across multiple machines [23:38] I see... [23:39] * maxb fixes bzr-grep to not run its tests under xvfb [23:39] running "sudo python setup.py install" is giving me this error: [23:39] running install [23:39] running build [23:39] running build_py [23:39] running build_ext [23:39] building 'bzrlib._annotator_pyx' extension [23:39] distcc gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/ffp/include/python2.5 -c bzrlib/_ annotator_pyx.c -o build/temp.linux-armv5tejl-2.5/bzrlib/_annotator_pyx.o [23:39] unable to execute distcc: No such file or directory [23:40] which is normal, since I don't have distcc on my NAS :D [23:40] wgrant: well, you've got CC=distcc exported then :) [23:41] that, or your python was built with distcc and has remembered that [23:42] Do I really? [23:43] bah [23:43] Tsu: ^ [23:43] wgrant: I was typing something else to you [23:45] Actually, it might be that distutils is confused on that system. [23:53] nice... [23:53] :) [23:53] python bzr [23:53] Bazaar 2.3.0 -- a free distributed version-control tool [23:53] http://bazaar.canonical.com/ [23:53] python bzr is workin :D [23:53] Tsu: great :) [23:53] :) [23:54] :/mnt/HD/HD_a2/ffp/home/root/bin/bzr# python bzr serve & [23:54] :/mnt/HD/HD_a2/ffp/home/root/bin/bzr# listening on port: 4155 [23:54] Nice... [23:54] :D [23:56] ok... [23:56] it looks like it's working... [23:56] I'll give it some more testing tomorrow [23:56] thank you all! [23:56] cya all tomorrow :D [23:56] Tsu: you're welcome [23:57] thank you spiv [23:57] cya [23:57]