[00:46] <MTecknology> 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] <MTecknology> oops... wrong order
[00:48] <igc> morning all
[01:04] <ronny> jelmer: k, thx
[01:27] <jessicah> I'm getting lost in the website, so, how do I set up bzr to get through my proxy server?
[01:28] <bob2> which OS?
[01:28] <bob2> and http proxy for http urls?
[01:29] <jessicah> debian
[01:29] <jessicah> ahuh
[01:29] <jessicah> bzr checkout http://some.repo.com/trunk just sits there doing nothing
[01:29] <ryanakca> 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] <bob2> set the http_proxy env var
[01:30] <jessicah> hmm, ok
[01:30] <bob2> export http_proxy=http://whatever:port/ ; bzr checkout http://...
[01:30] <jessicah> thanks bob2
[01:31] <bob2> did it work? :)
[01:31] <jessicah> it's strange it not use setting somewhere else in debian
[01:31] <jessicah> oh well
[01:31] <bob2> most (non-gui) things will pick up http_proxy
[01:31] <jessicah> well, svn/wget worked without setting, that why I confused
[01:31] <jessicah> I set it up during debian install
[01:31] <bob2> that is weird
[01:32] <jessicah> yeah
[01:32] <jessicah> anyways, it a workaround :) will bzr remember proxy used?
[01:32] <jessicah> or I need to set http_proxy all the time now?
[01:33] <bob2> it won't
[01:33] <bob2> you can add the export line to ~/.bashrc
[01:34] <jessicah> 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 ...
[03:56] <AfC> 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] <AfC> [they're up there with revision messages in the "would be useful as history if you could fix typos", IMHO]
[03:58] <AfC> but every so often I wonder what I'm missing as to their importance.
[04:02] <Peng_> I like nicks. They help you get the basic idea of a branch from a glance.
[04:03] <Peng_> Reading the commit messages takes more effort.
[04:05] <SamB> AfC: well, yeah, there is that ...
[04:12] <AfC> 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] <AfC> once again,
[04:12] <AfC> forever more in bzr history and quite unhelpful.
[04:13] <Peng_> AfC: Haha, good point. I do that on one branch I share between two machines.
[04:13] <AfC> 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] <AfC> Peng_: but given that there isn't [and never was going to be]
[04:14] <Peng_> People are usually consistent, though.
[04:14] <AfC> I must admit that I find the fact that it is printed in the standard `bzr log` output ludicrous.
[04:14] <AfC> No they aren't
[04:15] <Peng_> Heh.
[04:19] <AfC> Peng_: so consider this: http://rafb.net/p/QuFzGb68.html
[04:19] <AfC> branch nicks | uniq
[04:20] <AfC> now, admittedly, I am the author or the many of those branches, and *I* use a self-consistent naming scheme.
[04:20] <AfC> 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] <AfC> Overall, having this displayed prominently as history seems, as I said, somewhat ludicrous.
[04:22] <AfC> The "myMainline" are always charming. "TreeStore implementation" merging to "treestore" illustrates the problem more clearly, I think.
[04:22] <AfC> 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] <AfC> Branch nick, as such, seems to have nothing to do with this.
[04:23] <AfC> So, like I said, I wonder what I am missing.
[04:24] <Peng_> Looks like Loggerhead developers use "loggerhead", "trunk" and "trunk-rich" for the mainline. i hadn't really noticed.
[04:31] <AfC> Peng_: that would count as a "social" mechanism for keeping it aligned (ie, people had agreed).
[04:32] <AfC> ... 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] <AfC> Or, at least, contrary to what it might be.
[04:49] <Peng_> AfC: s/mainline/trunk/, then. I didn't mean to use any term in particular.
[07:54] <lifeless> ola
[08:30] <davidstrauss> lifeless: hi!
[08:30] <lifeless> Hi davidstrauss
[10:27] <kfogel> "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] <jml> haha
[12:08] <amanica> is it just me or is bundlebuggy dead? are we supposed to exclusively use launchpad already?
[12:15] <eMerzh> Hi, ...we are (at work) using http+webdav to psuh changes...we want to be notified for each push or commit ...
[12:15] <eMerzh> Because of external commiters, we don't want to use bzr-email for each client....which other solutions does we have?
[12:16] <eMerzh> thanks for your help
[12:46] <amanica> eMerzh, you'd have to install a e-mail notification plugin on the server
[12:57] <eMerzh> amanica, thanks.. but currently, i don't have a smart server... just an apache...this is not enough i gess?
[12:58] <amanica> eMerzh, its not too hard to get a smartserver set up behind apache
[12:59] <eMerzh> amanica, ok can we still commit by sftp too?
[12:59] <amanica> mm.. you'd have to use bzr+https if you want the serverside hooks to fire
[13:00] <eMerzh> ok, thanks for your help i will look for this :)
[13:59] <NEBAP|work> 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] <luks> are you running it in a branch?
[14:02] <NEBAP|work> 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] <luks> what does bzr info says?
[14:03] <NEBAP|work> just a second ..
[14:04] <fullermd> BTW, "checkout branch" likely isn't a meaningful term...
[14:04] <NEBAP|work> ok sorry
[14:05] <NEBAP|work> I´m just a beginner in using bazaar :(
[14:05] <fullermd> Well, it's not a _sin_   :)
[14:05] <NEBAP|work> ^^
[14:05] <NEBAP|work> but seems like luks has found the error
[14:05] <fullermd> 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] <luks> NEBAP|work: if a program says X is wrong, the first thing to check should be X :)
[14:06] <NEBAP|work> you´re right, I´ll try to learn the "vocabulary" and make things clearer ;)
[14:07] <NEBAP|work> so, my repository has a similar structure to this: MyProject/Trunk/SubProjects(features)
[14:08] <NEBAP|work> on the pc that throws the errors, "bzr info" tells me that "MyProject" and "Trunk" are standalone trees
[14:08] <NEBAP|work> while "SubProject" is a branch related to "trunk"
[14:08] <NEBAP|work> is that the right structure?
[14:09] <NEBAP|work> or better a "good structure" to manage a project in bazaar
[14:13] <NEBAP|work> 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"
[17:06] <hexmode> 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] <GaryvdM> hexmode: Can you elaborate a bit? Is there an error that you are getting?
[17:19] <hexmode> GaryvdM: yes.... but it is a little late now... I decided I didn't care about the old revs.
[17:19] <GaryvdM> ok
[17:29] <GaryvdM> Hi jelmer - I'm trying to use bzr-colocated. bzr init --colocated BRANCHNAME seems to be broken.
[17:30] <GaryvdM> If I do bzr init --colocated BRANCH; bzr switch BRANCH; bzr log - I get a Not a branch error.
[17:31] <GaryvdM> If I check on the disk - it's created a folder for the branch (.bzr/branches/BRANCH), but it is empty.
[19:34] <dash> hi.
[19:34] <jelmer> hi
[19:35] <dash> is there a way to check out a deleted branch at a specific revision using bzr-svn?
[19:38] <dash> 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] <ryanakca> 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] <GaryvdM> ryanakca: when you add the file, specify --file-ids-from=ARG
[20:39] <GaryvdM> eg: bzr add XY.py --file-ids-from=A
[20:39] <ryanakca> GaryvdM: and if its already added?
[20:39] <ryanakca> half a dozen revisions ago?
[20:40] <GaryvdM> are those revision public? if not, I think you can use rebase
[20:41] <GaryvdM> I'm not 100% sure.
[21:06] <ricardo> 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] <ricardo> does this mean I have my repo broken?
[21:09] <ricardo> btw.. I am trying to push to a svn repo (using bzr-svn)
[21:09] <ricardo> I am using bzr 1.14 and bzr-svn 0.5.4
[21:13] <servilio> hi all! is there a way to change the email recorded in the logs of a local branch?
[21:15] <dash> servilio: "bzr whoami"
[21:17] <servilio> dash: yep, but it doesn't change the authorship info of what is already committed
[21:18] <dash> that's true
[21:20] <servilio> 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] <GaryvdM> ricardo - lets look at one thing at a time. - Where are you pulling from? Have you tried bzr pull --overwrite?
[21:21] <GaryvdM> servilio - Are these revision public yet?
[21:22] <GaryvdM> If they are - it not recomended to do that.
[21:22] <servilio> GaryvdM: not yet
[21:22] <ricardo> GaryvdM, its a bit more complicated... I am trying out the feature for rewriting authors in svn
[21:22] <ricardo> so I have one repo A that is a branch of svn
[21:22] <ricardo> one repo B which is a branch of A
[21:23] <ricardo> I made a change in B and pushed to A, and also made a change in A directly
[21:23] <ricardo> and then tried to push to svn
[21:23] <servilio> GaryvdM: and I'd like to set the proper authorship info before committing to the public repo
[21:23] <GaryvdM> servilio: I think there may be a way to do it with rebase
[21:24]  * servilio goes to read bzr help rebase
[21:26] <GaryvdM> servilio - It seems not . Sorry
[21:27] <GaryvdM> ricardo: where did the rebase come in?
[21:27] <servilio> GaryvdM: can't find it either
[21:27] <servilio> GaryvdM: thanks anyway!
[21:28] <ricardo> GaryvdM, at some point between pulling/pushing between A and B, I tried to push to svn (from A)
[21:29] <ricardo> and I got this error message (cannot push because....) and  so I tried to rebase in order to fix the commit order
[21:29] <ricardo> but there is nothing to rebase apparently
[21:29] <ricardo> so I am stuck with not being able to push
[21:30] <GaryvdM> ricardo: what is the exact error that you get when you push?
[21:32] <ricardo> 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] <ricardo> but never mind, as this is a test, I just uncommitted a few revisions, and tried again
[21:32] <ricardo> it worked. in particular I had a merge revision , and it was this merge revision that was causing the problems
[21:33] <GaryvdM> ricardo: ok - I think that is something specific to bzr-svn - which I am not to familiar with.
[21:37] <ricardo> GaryvdM, np... as I said, since this is a test, I am not too worried
[21:37] <ricardo> I will test it a bit further, and if I see no other issues, I'll go for it
[21:37] <ricardo> thanks for the help
[21:51] <Ddorda> hey. how do i download a specific version of a project?
[21:58] <ryanakca> GaryvdM: rebase?
[21:58] <ryanakca> (it isn't in bzr help commands)
[21:59] <Ddorda> i'm not sure what's rebase
[21:59] <GaryvdM> ryanakca: It's a plugin.
[21:59] <Ddorda> i want to use a reversion of a project
[22:02] <GaryvdM> 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] <GaryvdM> I'm not sure though if rebase uses paths, or file-id. If the latter - It won't work.
[22:11] <jelmer> it uses file ids
[22:12] <Ddorda> well.. any idea?
[22:13] <Ddorda> good night then
[22:24] <servilio> jelmer: know of a way to take advantage of the fix for bug 372559 of bzr-svn?
[22:24] <jelmer> servilio: how do you mean?
[22:25] <servilio> jelmer: I am using bzr 1.14 + bzr.svn 0.5.4 and I am being hit by that bug
[22:26] <servilio> 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] <jelmer> servilio: I'd recommend waiting for 1.15, which will be out in 3 days
[22:27] <servilio> 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] <jelmer> servilio: in that case, I'd upgrade to 1.15rc1 altogether
[22:28] <servilio> jelmer: so, it is production stable already?
[22:28] <servilio> that'd be great
[22:28] <jelmer> servilio: well, rcs are usually quite stable
[22:29] <jelmer> servilio: and I haven't seen any brown bag issues with 1.15rc1
[22:30] <servilio> jelmer: great!
[22:30] <servilio> jelmer: what do you think of using bzr in a buildout sandbox? or a virtualenv?
[22:31] <servilio> I'd like to wait for the packages for my distro to be available (Debian Lenny here)
[22:33] <jelmer> servilio: I don't know, have never used it in that environment
[22:33] <jelmer> servilio: I usually push packages to sid the day a release is out
[22:40] <servilio> jelmer: great!
[22:41] <servilio> 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] <servilio> no luck with p.D.o
[22:46] <servilio> and FTP shows no packages for 1.15rc1
[22:50] <jelmer> servilio: I haven't uploaded 1.15rc1 yet because there's no new bzrtools out yet
[22:51] <jelmer> servilio: You can build a 1.15rc1 package from the bzr branch on bzr.debian.org though
[22:51] <jelmer> http://bzr.debian.org/pkg-bazaar/bzr/unstable
[22:51] <servilio> jelmer: how would I do that?
[22:52] <jelmer> servilio: if you have bzr-builddeb installed, run:
[22:54] <jelmer> bzr bd http://bzr.debian.org/pkg-bazaar/bzr/unstable
[22:54] <jelmer> or check out that branch locally and run "bzr bd" there
[22:58] <servilio> jelmer: will that build the corresponding bzrtools pkg?
[22:58] <jelmer> servilio: no, it'll only build bzr itself
[22:58] <servilio> ok
[22:58] <jelmer> servilio: you will have to deinstall bzrtools if you upgrade to bzr 1.15rc1 now
[22:59] <servilio> I am looking at gf.recipe.bzr [http://pypi.python.org/pypi/gf.recipe.bzr/1.0rc4]
[22:59] <nevans> jelmer: encountering a cache bug on latest rev of bzr-svn 0.6
[22:59] <nevans> jelmer: http://pastebin.com/m2ab5f3c2
[23:00] <nevans> 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] <jelmer> nevans: not sure what that's about from the top of my head, any chance you can file a bug?
[23:03] <nevans> jelmer: sure thing.
[23:06] <Necoro> hey - short question: why does the following not work as expected: bzrlib.branch.Branch.open("lp:some-project") (with bzr-1.14)
[23:06] <Necoro> resulting exception: bzrlib.errors.NotBranchError: Not a branch: "/home/necoro/dev/portato/trunk/plugins/lp:some-project/"
[23:06] <Necoro> so - it does not resolve the "lp:" URL
[23:06] <jelmer> nevans: you need to do a directory service lookup
[23:06] <jelmer> nevans: that will give you back a proper branch URL
[23:07] <jelmer> s/nevans/Necoro/
[23:07] <jelmer> Necoro: Try doing this before the branch open
[23:07] <jelmer> Necoro: "from bzrlib.plugin import load_plugins; load_plugins()"
[23:10] <Necoro> 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] <Necoro> seems like bzr changed the behavior there (because it used to work a couple of versions ago ;))
[23:17] <jelmer> Necoro: strange, I don't think anything has changed in this area recently
[23:19] <Necoro> hmm ... "Connection closed: please check connectivity and permissions" ... seems to have problems with ssh or sth similar ..
[23:20] <Necoro> (it should not resolve the lp:-address to a bzr+ssh at all ... only to http://)
[23:23] <jelmer> Necoro: it has always resolved to a bzr+ssh:// URL if there was a lp login username known
[23:25] <Necoro> hmm ... if I do "bzr branch lp:bla", it tells me, that there is not launchpad-ID
[23:25] <Necoro> if I do this via python-shell, it just returns the http:// address, w/o the "no ID"-warning
[23:25] <Necoro> and in my programm ... well - it takes the bzr+ssh version ^^
[23:31] <servilio> jelmer: gotta go now, thanks a lot! will try your suggestion as soon as I get back
[23:42] <Necoro> jelmer: got it - the bug is on my side
[23:43] <Necoro> 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