[00:46] I have a patch file that was submitted to me - http://bzr.pastebin.com/m3b6d833a - I'm trying to use the patch command to apply the patch but it's saying only garbage was found [00:47] oops... wrong order [00:48] morning all [01:04] jelmer: k, thx [01:27] I'm getting lost in the website, so, how do I set up bzr to get through my proxy server? [01:28] which OS? [01:28] and http proxy for http urls? [01:29] debian [01:29] ahuh [01:29] bzr checkout http://some.repo.com/trunk just sits there doing nothing [01:29] I manually copied file XY.py from branch A to B, and then bzr added in under B. Is there a way to show that the file XY.py originally came from branch A? [01:29] set the http_proxy env var [01:30] hmm, ok [01:30] export http_proxy=http://whatever:port/ ; bzr checkout http://... [01:30] thanks bob2 [01:31] did it work? :) [01:31] it's strange it not use setting somewhere else in debian [01:31] oh well [01:31] most (non-gui) things will pick up http_proxy [01:31] well, svn/wget worked without setting, that why I confused [01:31] I set it up during debian install [01:31] that is weird [01:32] yeah [01:32] anyways, it a workaround :) will bzr remember proxy used? [01:32] or I need to set http_proxy all the time now? [01:33] it won't [01:33] you can add the export line to ~/.bashrc [01:34] okies, thanks bob2 :) [02:03] * igc out for a few hours - bbl [03:27] * SamB wishes for the nth time that git kept branch nicks about ... === krisfree is now known as krisfremen [03:56] SamB: Interesting that you say that. I've tended to feel that Bazaar's branch nick concept is superfluous. I freely admit, of course, that branch nicks haven't found their way into my workflow as such, so I haven't quite seen the need for them. [03:57] [they're up there with revision messages in the "would be useful as history if you could fix typos", IMHO] [03:58] but every so often I wonder what I'm missing as to their importance. [04:02] I like nicks. They help you get the basic idea of a branch from a glance. [04:03] Reading the commit messages takes more effort. [04:05] AfC: well, yeah, there is that ... [04:12] Peng_: that's fine, except that when you're collaborating with someone and you call the branch 'bug-strict-aliasing' and they call the branch 'myExcellentWorkingDirecotry' that's a nice bit of data that is, [04:12] once again, [04:12] forever more in bzr history and quite unhelpful. [04:13] AfC: Haha, good point. I do that on one branch I share between two machines. [04:13] Peng_: if there was a mechanism (technical or social) to force people to be consistent about branch naming, then perhaps the nick thing would be useful. [04:13] Peng_: but given that there isn't [and never was going to be] [04:14] People are usually consistent, though. [04:14] I must admit that I find the fact that it is printed in the standard `bzr log` output ludicrous. [04:14] No they aren't [04:15] Heh. [04:19] Peng_: so consider this: http://rafb.net/p/QuFzGb68.html [04:19] branch nicks | uniq [04:20] now, admittedly, I am the author or the many of those branches, and *I* use a self-consistent naming scheme. [04:20] at least recently. But you can readily see where I have collaborated with others, or reviewed and merged contributions, and there things are all over the map. Not to mention my own changing tastes. [04:21] Overall, having this displayed prominently as history seems, as I said, somewhat ludicrous. [04:22] The "myMainline" are always charming. "TreeStore implementation" merging to "treestore" illustrates the problem more clearly, I think. [04:22] The only thing that makes the branches related is a) the fact they are branches at all, and b) their interconnections at head and tail with other branches [especially mainline]. [04:23] Branch nick, as such, seems to have nothing to do with this. [04:23] So, like I said, I wonder what I am missing. [04:24] Looks like Loggerhead developers use "loggerhead", "trunk" and "trunk-rich" for the mainline. i hadn't really noticed. [04:31] Peng_: that would count as a "social" mechanism for keeping it aligned (ie, people had agreed). [04:32] ... except if that's 'mainline', then it seems to have more than one alias. Which would seem to be contrary to the purpose of the idea. [04:32] Or, at least, contrary to what it might be. [04:49] AfC: s/mainline/trunk/, then. I didn't mean to use any term in particular. [07:54] ola [08:30] lifeless: hi! [08:30] Hi davidstrauss === stefanlsd_ is now known as stefanlsd === knielsen_ is now known as knielsen [10:27] "So, I used bzr to download the notification plugin for Sonata. All these SVN systems are a pain in the ass, but whatever." (from http://smyte.wordpress.com/2009/05/18/mpd-sonata-notify-osd/) [10:29] haha === thunderstruck is now known as gnomefreak [12:08] is it just me or is bundlebuggy dead? are we supposed to exclusively use launchpad already? [12:15] Hi, ...we are (at work) using http+webdav to psuh changes...we want to be notified for each push or commit ... [12:15] Because of external commiters, we don't want to use bzr-email for each client....which other solutions does we have? [12:16] thanks for your help [12:46] eMerzh, you'd have to install a e-mail notification plugin on the server === Kissaki^0ff is now known as Kissaki [12:57] amanica, thanks.. but currently, i don't have a smart server... just an apache...this is not enough i gess? [12:58] eMerzh, its not too hard to get a smartserver set up behind apache [12:59] amanica, ok can we still commit by sftp too? [12:59] mm.. you'd have to use bzr+https if you want the serverside hooks to fire [13:00] ok, thanks for your help i will look for this :) [13:59] hi guys, can someone help me out, I´m not able to create a bundle with "bzr send -o ...". I always get a "bzr error not a branch" error. Any ideas what I can do? [14:01] are you running it in a branch? [14:02] yes, I´ve created a shared repository on the server with the option --notree. Then I´ve done a checkout on another client (has only read rights). After finishing the work I just want to create a patch to send it to the computer with write access. But I always get the error, I´ve still tried to unbind the checkout branch ... [14:03] what does bzr info says? [14:03] just a second .. [14:04] BTW, "checkout branch" likely isn't a meaningful term... [14:04] ok sorry [14:05] I´m just a beginner in using bazaar :( [14:05] Well, it's not a _sin_ :) [14:05] ^^ [14:05] but seems like luks has found the error [14:05] It's just muddy. Makes it harder to work out what's actually going on, and it can cloud your thinking about things. [14:06] NEBAP|work: if a program says X is wrong, the first thing to check should be X :) [14:06] you´re right, I´ll try to learn the "vocabulary" and make things clearer ;) [14:07] so, my repository has a similar structure to this: MyProject/Trunk/SubProjects(features) [14:08] on the pc that throws the errors, "bzr info" tells me that "MyProject" and "Trunk" are standalone trees [14:08] while "SubProject" is a branch related to "trunk" [14:08] is that the right structure? [14:09] or better a "good structure" to manage a project in bazaar [14:13] but seems like something else is wrong .. bzr info tells me that the branch root is "C:\....\MyProject" which is correct. But it also tells me that the submit branch is "trunk" which causes him to search for it in "C:\....\MyProject\trunk\Feature\trunk\" not in "C:\....\MyProject\trunk" === nevans1 is now known as nevans === garyvdm is now known as GaryvdM_ === GaryvdM_ is now known as GaryvdM === KX_ is now known as KX [17:06] I have a missing .bzr/repository/pack-names file on a repo I haven't touched in a while. Is there anything I can do to recover? [17:11] hexmode: Can you elaborate a bit? Is there an error that you are getting? [17:19] GaryvdM: yes.... but it is a little late now... I decided I didn't care about the old revs. [17:19] ok [17:29] Hi jelmer - I'm trying to use bzr-colocated. bzr init --colocated BRANCHNAME seems to be broken. [17:30] If I do bzr init --colocated BRANCH; bzr switch BRANCH; bzr log - I get a Not a branch error. [17:31] If I check on the disk - it's created a folder for the branch (.bzr/branches/BRANCH), but it is empty. === KX is now known as FooBar === FooBar is now known as BarFooBaz === BarFooBaz is now known as KX [19:34] hi. [19:34] hi [19:35] is there a way to check out a deleted branch at a specific revision using bzr-svn? [19:38] I suppose I could check out the branches dir and roll it back to that rev.... but there's a lot of branches in there. =/ [20:26] I manually copied file XY.py from branch A to B, and then bzr added in under B. Is there a way to show that the file XY.py originally came from branch A? [20:39] ryanakca: when you add the file, specify --file-ids-from=ARG [20:39] eg: bzr add XY.py --file-ids-from=A [20:39] GaryvdM: and if its already added? [20:39] half a dozen revisions ago? [20:40] are those revision public? if not, I think you can use rebase [20:41] I'm not 100% sure. [21:06] hi people. I was trying out bzr-rebase. and I am getting some weird conditions. I am doing a pull and I get 'No revisions to pull'. I do a rebase and I get 'No revisions to rebase'. When I do a push I get 'Unable to push ... because it would change the ordering... Use rebase and try again or push to a non-root path'. [21:07] does this mean I have my repo broken? [21:09] btw.. I am trying to push to a svn repo (using bzr-svn) [21:09] I am using bzr 1.14 and bzr-svn 0.5.4 [21:13] hi all! is there a way to change the email recorded in the logs of a local branch? [21:15] servilio: "bzr whoami" [21:17] dash: yep, but it doesn't change the authorship info of what is already committed [21:18] that's true [21:20] dash: have any idea/pointer where can I find how to change the authorship (actually, only the e-mail I need to change) of past commits? [21:21] ricardo - lets look at one thing at a time. - Where are you pulling from? Have you tried bzr pull --overwrite? [21:21] servilio - Are these revision public yet? [21:22] If they are - it not recomended to do that. [21:22] GaryvdM: not yet [21:22] GaryvdM, its a bit more complicated... I am trying out the feature for rewriting authors in svn [21:22] so I have one repo A that is a branch of svn [21:22] one repo B which is a branch of A [21:23] I made a change in B and pushed to A, and also made a change in A directly [21:23] and then tried to push to svn [21:23] GaryvdM: and I'd like to set the proper authorship info before committing to the public repo [21:23] servilio: I think there may be a way to do it with rebase [21:24] * servilio goes to read bzr help rebase [21:26] servilio - It seems not . Sorry [21:27] ricardo: where did the rebase come in? [21:27] GaryvdM: can't find it either [21:27] GaryvdM: thanks anyway! === nevans1 is now known as nevans [21:28] GaryvdM, at some point between pulling/pushing between A and B, I tried to push to svn (from A) [21:29] and I got this error message (cannot push because....) and so I tried to rebase in order to fix the commit order [21:29] but there is nothing to rebase apparently [21:29] so I am stuck with not being able to push [21:30] ricardo: what is the exact error that you get when you push? === nevans1 is now known as nevans [21:32] GaryvdM, I was getting bzr: ERROR: Unable to push revision 'root@xxxx' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path [21:32] but never mind, as this is a test, I just uncommitted a few revisions, and tried again [21:32] it worked. in particular I had a merge revision , and it was this merge revision that was causing the problems [21:33] ricardo: ok - I think that is something specific to bzr-svn - which I am not to familiar with. [21:37] GaryvdM, np... as I said, since this is a test, I am not too worried [21:37] I will test it a bit further, and if I see no other issues, I'll go for it [21:37] thanks for the help [21:51] hey. how do i download a specific version of a project? [21:58] GaryvdM: rebase? [21:58] (it isn't in bzr help commands) [21:59] i'm not sure what's rebase [21:59] ryanakca: It's a plugin. [21:59] i want to use a reversion of a project [22:02] ryanakca: disclamier: I've never done this. Recreate the revision that adds that file, then rebase the remainder if the revision on the new revision [22:03] I'm not sure though if rebase uses paths, or file-id. If the latter - It won't work. [22:11] it uses file ids [22:12] well.. any idea? [22:13] good night then [22:24] jelmer: know of a way to take advantage of the fix for bug 372559 of bzr-svn? [22:24] Launchpad bug 372559 in bzr-svn "KeyError u'trunk3' on branch" [Undecided,Fix released] https://launchpad.net/bugs/372559 [22:24] servilio: how do you mean? [22:25] jelmer: I am using bzr 1.14 + bzr.svn 0.5.4 and I am being hit by that bug [22:26] jelmer: already downloaded bzr.svn 0.6 but it depends on 1.15, which isn't released yet, and I have no idea how stable it is ATM with RC1 [22:27] servilio: I'd recommend waiting for 1.15, which will be out in 3 days [22:27] jelmer: so I was wondering what would be more reliable: backport the fix to 0.5.4 locally, or upgrade to 1.15rc1 altogether [22:27] servilio: in that case, I'd upgrade to 1.15rc1 altogether [22:28] jelmer: so, it is production stable already? [22:28] that'd be great [22:28] servilio: well, rcs are usually quite stable [22:29] servilio: and I haven't seen any brown bag issues with 1.15rc1 [22:30] jelmer: great! [22:30] jelmer: what do you think of using bzr in a buildout sandbox? or a virtualenv? [22:31] I'd like to wait for the packages for my distro to be available (Debian Lenny here) [22:33] servilio: I don't know, have never used it in that environment [22:33] servilio: I usually push packages to sid the day a release is out [22:40] jelmer: great! [22:41] jelmer: so, do you think it would be easy creating a 1.15rc1 .deb from the 1.14 deb-src? [22:43] * servilio is checking packages.debian.org... [22:46] no luck with p.D.o [22:46] and FTP shows no packages for 1.15rc1 [22:50] servilio: I haven't uploaded 1.15rc1 yet because there's no new bzrtools out yet [22:51] servilio: You can build a 1.15rc1 package from the bzr branch on bzr.debian.org though [22:51] http://bzr.debian.org/pkg-bazaar/bzr/unstable [22:51] jelmer: how would I do that? [22:52] servilio: if you have bzr-builddeb installed, run: === nevans1 is now known as nevans [22:54] bzr bd http://bzr.debian.org/pkg-bazaar/bzr/unstable [22:54] or check out that branch locally and run "bzr bd" there === nevans1 is now known as nevans [22:58] jelmer: will that build the corresponding bzrtools pkg? [22:58] servilio: no, it'll only build bzr itself [22:58] ok [22:58] servilio: you will have to deinstall bzrtools if you upgrade to bzr 1.15rc1 now [22:59] I am looking at gf.recipe.bzr [http://pypi.python.org/pypi/gf.recipe.bzr/1.0rc4] [22:59] jelmer: encountering a cache bug on latest rev of bzr-svn 0.6 [22:59] jelmer: http://pastebin.com/m2ab5f3c2 [23:00] I can post a lp bug, if you'd like. But I figured I'd ping you here first, because this isn't exactly a release. :) [23:03] nevans: not sure what that's about from the top of my head, any chance you can file a bug? [23:03] jelmer: sure thing. [23:06] hey - short question: why does the following not work as expected: bzrlib.branch.Branch.open("lp:some-project") (with bzr-1.14) [23:06] resulting exception: bzrlib.errors.NotBranchError: Not a branch: "/home/necoro/dev/portato/trunk/plugins/lp:some-project/" [23:06] so - it does not resolve the "lp:" URL [23:06] nevans: you need to do a directory service lookup [23:06] nevans: that will give you back a proper branch URL [23:07] s/nevans/Necoro/ [23:07] Necoro: Try doing this before the branch open [23:07] Necoro: "from bzrlib.plugin import load_plugins; load_plugins()" [23:10] jelmer: ok - I _do_ load plugins (for exactly this feature) ... but in another thread ... (or more specific: I load the plugins, and then create a thread which looks up the branch) [23:11] seems like bzr changed the behavior there (because it used to work a couple of versions ago ;)) [23:17] Necoro: strange, I don't think anything has changed in this area recently [23:19] hmm ... "Connection closed: please check connectivity and permissions" ... seems to have problems with ssh or sth similar .. [23:20] (it should not resolve the lp:-address to a bzr+ssh at all ... only to http://) [23:23] Necoro: it has always resolved to a bzr+ssh:// URL if there was a lp login username known === Kissaki is now known as Kissaki^0ff [23:25] hmm ... if I do "bzr branch lp:bla", it tells me, that there is not launchpad-ID [23:25] if I do this via python-shell, it just returns the http:// address, w/o the "no ID"-warning [23:25] and in my programm ... well - it takes the bzr+ssh version ^^ [23:31] jelmer: gotta go now, thanks a lot! will try your suggestion as soon as I get back [23:42] jelmer: got it - the bug is on my side [23:43] switching to root-user in the program via a graphical su ... and this is not setting the environment - i.e. HOME still points to the original user