[00:01] lifeless: hmm, it may be more useful to have that pqm than I thought after all [00:02] lifeless: I found myself looking for the revision to match a particular merge request, and now it looks like we have a test regression [00:09] (btw, thanks igc and Odd_Bloke, :D) [00:09] np [00:09] beuno: :) [00:09] beuno: I'll have a read a little later [00:10] jelmer: kk [00:11] lifeless, great, thanks! I'll wait then, no real hurry. [00:11] beuno: perhaps mail me the link so I don't lose it ;) [00:12] lifeless, on it's way [00:15] hello lifeless, welcome back [00:20] i like the webpage. very clean & simple [00:25] Aloha, which one? [00:25] the bazaar mainpage === BasicMac is now known as BasicOX === BasicOX is now known as BasicOSX === kiko is now known as kiko-zzz [00:40] New bug: #186876 in bzr-svn ""The file id FOO is not present in the tree" on svn-import" [Undecided,New] https://launchpad.net/bugs/186876 [00:55] w00t, the python-subversion memory leak bug has finally been fixed in hardy [01:11] jelmer: neat! [01:57] * igc food === not-xjjk is now known as xjjk === mw is now known as mw|out [04:25] New bug: #186920 in bzr "bzr launchpad does not handle proxy when used for name resolution " [Undecided,New] https://launchpad.net/bugs/186920 [04:30] New bug: #178772 in trac-bzr "Must use datetime for trac 0.11" [High,In progress] https://launchpad.net/bugs/178772 [04:51] bbiab [05:05] New bug: #116659 in trac-bzr "Phantom changesets in timeline" [Medium,Triaged] https://launchpad.net/bugs/116659 [06:01] is http://bazaar-vcs.org/KnitMerge an accurate depiction of the current merge algorithm used by bzr? [06:01] rcohen, it's approximately correct for merge --knit [06:02] it is not the default merge algorithm [06:02] ah, what's the default algorithm? [06:02] the knit algorithm looks very similar to the codeville merge algorithm [06:02] a 3-way merge [06:03] it is [06:03] which i have some experience with [06:04] is the 2-way diff done directly between the 2 sides, or is a match done against the knit/weave first and then lined up? [06:04] i'd have to check the code [06:04] but i believe it is done on the text first [06:04] so it will be more forgiving of accidental convergence [06:04] which aiui cdv is more paranoid about [06:05] um [06:05] it's been suggested that we should make this the default merge type [06:05] codeville does the former [06:05] (hi, i wrote most of codeville) [06:05] though i think the latter would have some advantages [06:05] i wondered :) [06:05] i've become a big fan of convergence [06:06] as it has this nice side effect of cherry-picking just working, even if someone produces a diff and applies it to a different branch [06:08] the codeville algorithm has had some small tweaks, but it definitely supports accidental convergence [06:09] you'll have to tell me if this is accurate, but i believe the biggest difference between what cdv does and the knit merge is that cdv tracks spaces between lines instead of lines themselves [06:09] this was done to catch line removals without adds [06:11] rcohen: you may find --lca interesting [06:12] since you have a weave, i think you can actually make some improvements over what codeville is doing [06:12] not that the codeville merge is bad or anything :) been working very well in practice [06:13] back later [06:15] hmm, i guess you handle the deleted lines when you determine line ancestry on both sides, so that's kosher [06:16] my gut feeling is that you'd do better by matching the 2 sides against the weave instead of directly against each other [06:17] matching directly introduces a less precise resolution step which can cause some problems [06:18] these usually show up when files have their contents reordered or something does a cut-and-paste job and makes minor modifications [06:18] s/something/someone/ [06:20] off the topic of merging, does bzr support '...' globbing (like in perforce) or something like it? [06:23] '...' is like '*' but recurses through subdirectories [06:23] rcohen, merging is kind of swapped out for me [06:23] yes, ** [06:23] very nice [06:24] it's ok, i happen to have paged a bunch of it back in today [06:24] it was swapped out for quite a while there [06:26] do you work at/on bittorrent too? [06:26] not anymore [06:27] i never contributed much in terms of code [06:33] still not sure how i feel about being management [06:34] same here [06:39] i just wanted to poke my head in, looks like bzr is shaping up nicely [06:39] yes [06:39] and i'm glad at least one other project cares about a sane UI :) [06:39] performance seems to be pretty good now, and other things are coming along [06:40] launchpad.net hosting is becoming quite popular, and its ui should keep improving too [06:40] i guess you're in the us? we're having a developer conference in london in march, if you happen to be nearby [06:42] i'd love to visit london again, but sadly i doubt it'll happen [06:43] i'm in san francisco [06:43] you in lexington? [06:43] no, i'm in Sydney [06:45] how does networking performance compare? [06:46] better than hg and git over plain http, according to ian's measurements [06:46] and fairly good for the smart server, though we still have more to do for avoiding round trips [06:47] the server also implements access controls? [06:47] yes [06:47] are you interested in getting involved? or in using bzr? [06:48] you don't use client-side SSL certificates or anything crazy like that, do you? [06:48] possibly [06:48] no, normally people use ssh [06:48] we use paramiko on windows so you don't need an external ssh client [06:49] i haven't had much spare time for quite a while, which is why codeville has been in bug fix mode for a long time [07:13] rcohen: see http://doc.bazaar-vcs.org/bzr.dev/developers/lca-merge.html (if you haven't already) for abentley's write-up on lca merge [07:22] how do you make files that are under version control not under version control anymore? [07:22] i know its not bzr rm. i learned that the hard way [07:22] i'll take a look at it, though i'm not a huge fan of 3-way merges because they end up not using a lot of good history information [07:22] Aloha: bzr rm --keep? [07:23] TFKyle, thnx [07:23] (oh, also bzr revert I think might do it they're newly added) [07:25] how do you guys handle debian directory of projects you're working on? do you include it or exclude it? [07:25] Aloha: I include it and use bzr-builddeb [07:25] for the one project I've debianized I include it [07:25] mtaylor, whats bzr-builddeb do? [07:26] Aloha: bzr-builddeb will split it out for you so you can still have an "orig" tarball and a then your debian stuff [07:26] Aloha: it's got a few different operational modes [07:26] Aloha: but including the debian source in your source branch is definiltely something it handles easily [07:27] my program isn't really functional if it not a package because it looks in /usr/share/pixmaps for images [07:27] i do dh_install to move them there [07:27] Aloha: yeah - I'd include the debian dir then [07:27] mtaylor, thnx [07:27] Aloha: but I'd still look in to bzr builddeb ... it'll make things easier on it [07:27] on you, rather :) [07:28] mtaylor, cool i'll research it [07:28] Aloha: don't konw if you've played with it, but there's also a tool called debcommit which will let you make changelog entries and then use them as your commit message [07:28] (somes in devscripts, I think) [07:28] mtaylor, i use dch for my changelog [07:28] Aloha: yup [07:29] Aloha: so once you do that, you just do a debcommit [07:29] mtaylor, cool thnx [07:29] and it'll read the new changelog entires and do a bzr commit for you with the new changelog entires as the message [07:29] so you don't have to do it twice [07:29] wonder if it'd be reasonable to autogenerate a changelog from bzr history [07:30] though that wouldn't handle distribution/etc. [07:30] might be... MySQL does that from bk sources for its changelog [07:30] I like the drive-the-bzr-history from the changelog approach though myself... but I'm a debian bigot, :) [07:31] thing I dislike about that is you have to be on a debian system to make commits unless you do it manually [07:31] yes [07:31] that is true [07:31] why wouldn't you be on a debian system? ;) [07:31] but then... I hate not being on a debian system [07:31] :) [07:31] * TFKyle doesn't use debian personally, except when he's making debian packages :D [07:31] * mtaylor shudders [07:31] * Aloha luvs debian [07:31] * mtaylor has heard of such people [07:32] do you use gentoo? [07:32] yep [07:32] freaking masochist [07:32] that's what I'm saying [07:32] but you know - whatever makes you happy! [07:32] * TFKyle loves gentoo, except the politics of course [07:32] well, I think the politics blow everywhere [07:32] amen [07:33] though, I have to admit, it isn't quite as bad as the Canadian House Of Commons/Question Period :P [07:35] canada in general blows ;) j/k [07:35] I used to use Gentoo, but eventually dropped it. I didn't like the idea of pushing out updates to the stable portage branch that bricked the system if you didn't answer correctly to questions in the upgrade phase, and gave no suggestion to what the "right" answer was except in some reply to a forum message hidden in the depths of oblivion. [07:36] Canada's not even a real country, right? [07:36] * TFKyle has been using ~arch since forever personally [07:36] * Odd_Bloke used Gentoo until he accidentally hosed his system, then used Ubuntu until he realised that Debian was both better _and_ newer. :p [07:37] * TFKyle disagrees with that, but meh [07:37] Gentoo seems to have looked at FreeBSD, and tried to replicate it for Linux but completely missed the big picture. [07:37] * mtaylor recently tried to apt-get dist-upgrade from gutsy to lenny on one of his machines [07:37] didn't really work out [07:37] at all [07:37] havn't really given debian/ubuntu that much testing though, dislike the idea of not having rolling updates [07:37] system totally unusable [07:38] TFKyle: I use unstable, so I do get them. [07:38] I wish ubuntu had an unstable [07:38] or a rolling unstable [07:38] mtaylor: There's gutsy-proposed or somesuch, which may or may not do something along those lines. [07:38] Odd_Bloke: yeah... not quite the same though [07:39] Odd_Bloke: I miss the good-old days of apt-get upgrading every morning [07:39] I keep trying Linux distributions, but I always end up coming back to FreeBSD. [07:39] Ubuntu's rolling unstable would have to be Debian unstable. :p [07:39] Odd_Bloke: :) [07:39] Debolaz: I hear that from people, and I've tried FreeBSD, but I don't like it for the same reason I don't like Gentoo... [07:40] which is that I don't want to compile mozilla or openoffice or X [07:40] ever [07:40] To be fair, Gentoo has binary packages to avoid painful compilations. [07:40] that, and I'm used to linux, so many of the freebsd file locations seem weird to me [07:40] Odd_Bloke: fair enough [07:40] * TFKyle is compiling oo.o right now, just for the heat though :P [07:40] Odd_Bloke: it did not back when I used it last [07:40] And the first two of those three I don't think I have installed on any of my Debian systems. [07:41] * mtaylor has to have openoffice for work [07:41] -48C with the windchill outside [07:41] TFKyle: good god man. [07:41] TFKyle: are you on the north pole? [07:41] mtaylor: nope, Regina, Saskatchewan, pretty close to the US [07:42] http://chris-lamb.co.uk/2008/01/05/debian-packages-sorted-by-build-time-and-build-space/ shows how bad OO.o compilation is. :p [07:42] i'm in hawaii its like 70F heh [07:42] * Odd_Bloke prefers Abiword. [07:42] mtaylor: Well, there are elements which FreeBSD and Gentoo has in common that might be undesirable for many people. But what I want is a system with a consistent design that has every aspect of it well documented. I don't *want* to compile things from source, and I do think the ports and binary package system leaves a few things to be desired. But I feel the good outweighs the bad in the case of FreeBSD. [07:42] * Aloha prefers gedit [07:42] While Gentoo doesn't really have any adventage aside from a large collection in portage. [07:42] Well, that's a lie. I prefer LaTeX, but for those times when people demand really ugly documents, I prefer Abiword. [07:43] * mtaylor _prefers_ emacs [07:43] As for text editor, vim is clearly the best. [07:43] Crap, now we have to fight at dawn. [07:43] damn [07:43] I'm too tired for that [07:43] can we just both agree that nano is annoying every time it starts? [07:43] Odd_Bloke, gvim ;) [07:44] and that we both wish it wasn't the default editor alternative [07:44] joe++ # Best damn editor ever. ;-) [07:44] mtaylor: Indeed. [07:44] emacs # Nice OS, bad editor [07:44] Debolaz: I totally agree about the consistent design part [07:44] joe/joe++ experience required. [07:44] nano's a bit too suckish imo, it gets the job done in some cases but using it as your main text editor would suck [07:44] Debolaz: which is the thing I like about debian, too, and one of the places where I think Debian and FreeBSD are similar [07:45] i got a bug i think [07:45] its syntax highlighting isn't that great even when enabled imo [07:45] Debolaz: I try to explain this to RH-using folks and they just don't seem to get it [07:45] when i do apt-get install bzr it installs 1.01~gutsy1 [07:45] TFKyle: nano has syntax highlighting? [07:45] but... [07:45] Aloha: where are you installing from? [07:46] mtaylor: newer versions do, though it's disabled by default unless you enable it in the config file iirc [07:46] mtaylor, where? [07:46] but apt-cache show bzr shows Version: 0.90-1 [07:46] I feel certain Linux distributions thinks it's perfectly ok to put things randomly in /opt, /var, /usr/local, etc etc, without any reasoning for what goes where except "it felt right at the time". [07:46] Aloha: yeah. 1.01~gutsy1 is old [07:46] Aloha: apt-cache show bzr will show you multiple versions [07:46] Aloha: scroll back further [07:46] you're seeing the one from gutsy itself at the bottom of the list [07:47] Aloha: but you should add deb http://ppa.launchpad.net/bzr/ubuntu gutsy main to your sources [07:47] mtaylor, ok thnx [07:48] mtaylor: Hehe, RH and SUSE are on my banlist for systems I admin. [07:48] Rh is ok. only because centos came out of it [07:48] Debolaz: I wish I could say the same [07:48] RHEL is used by the CS department here, and it's pretty painful. [07:48] Debolaz: but I'm a consultant for MySQL, so I have to touch whatever they're running [07:49] NFS and DNS randomly fail, and RH have been completely unhelpful as far as support goes. [07:49] my VPS runs centos [07:50] if it _has_ to be redhat based, Centos isn't bad [07:50] although I have to say RHEL5 took a major step forward by actually learning from Centos [07:50] rather than just sticking with the RH status quo [07:50] mtaylor, we're moving from putting those packages on bazaar-vcs.org to ppa [07:51] poolie: good. so is bazaar-vcs going to point to the ppa now? [07:51] i'll just change the web page now [07:51] sweet [07:51] * Debolaz should make an effort to learn bzr if he intends to keep hanging around in this channel. :-) [07:51] was bazaar created by canonical? [07:51] i need to also work out how/whether to redirect the existing archive [07:51] Aloha: and friends [07:52] poolie, everyone? ;) [07:52] poolie: good luck with that! :) [07:52] Debolaz: might not be a waste of your time :) [07:53] how do i get the key from bzr ppa? [07:55] mtaylor: Hehe. I am in doubt if I'll be replacing git anytime soon, but learning is never a bad thing. Especially since everyone keeps saying how fantastic bzr has come lately. :) [07:55] Debolaz: I think that if git is working fine for you, then great [07:55] bzr's been fantastic for quite a while :P [07:55] Debolaz: but I'm personally thrilled with bzr's ability to work with non-bzr systems too [07:56] makes migrating or running heterogenous GREAT [07:56] Aloha, there is no key for it at the moment, but it's meant to be coming soon [07:56] like in the next launchpad release [07:56] poolie, ok cool [07:56] My main complaint about git is the horribly weird frontend tools. Made it really difficult to understand the system at first. [07:56] * TFKyle wonders when lp will allow people to kill packages from their ppa [07:56] I'd be using mercurial if mercurial had been better with the thing you pointed out there, working wih non-mercurial systems. [07:57] Git actually works well against subversion, which is an important feature for me. [07:57] bzr push seems kind of an aggressive adjective heh [07:58] "bzr politely-request-you-take-these-updates" [07:59] night all [07:59] bzr take-it-rough [07:59] bzr be-my-bitch [08:00] * mtaylor wants to make a bzr-plugin that provides dirty aliases for all the builtins [08:00] that shouldn't be too hard to do [08:00] thinks it would take all of 20 minutes to write [08:00] mtaylor: https://launchpad.net/bzr-cheap-taiwanese" [08:00] ? [08:00] mostly just from the time spent copying and pasting stuff [08:00] mtaylor: its python; do it on the gly [08:00] *fly* [08:01] no plugin required - just use aliases :-) [08:01] lifeless: sure... but I have to actually type in the names of commands and the aliases for them [08:01] hmm, monkeypatch stuff so the old commands don't work anymore :P [08:01] not sure that would be coc-compliant! [08:03] TFKyle: As regards deleting PPA packages, I thought I saw something in the most recent LP release notes about now being able to do that. [08:03] I don't use PPAs myself, so I don't actually know that this is the case. :p [08:04] I think they've added the capability to the backend, but nothing in the frontend, though i havn't looked for a few weeks [08:04] thumper just posted an alias plugin, like in the shell [08:04] s/frontend/ui/ [08:04] yes, it was just annouce [08:05] ah, it is there, cool [08:13] * thumper should email the patch to the list === doko_ is now known as doko [08:36] Can anyone point me to docs on how to maintain an integration branch in bzr? [08:36] I have a few upstream svn branches that I'd like to occasionally import into different directories in my bzr tree. [08:37] No need to keep full svn history in bzr; I just need to pull down the releases every month, mash them together, and build a single app out of them. [08:37] Can bzr do this? [08:39] bronson: Do you need to keep the different upstream versions in your version control at all? [08:40] Odd_Bloke: yes, because I need to be able to tweak them and bring my patches forward. [08:40] that's what bzr-load-dirs was for [08:40] I think bzr import does the same thing [08:40] bob2: bzr svn-import? [08:41] Doesn't that create an entire repository? [08:41] no, "bzr import" [08:41] bzr: ERROR: unknown command "import" [08:41] Do I need 1.1? [08:41] I'm on 1.0. [08:41] hm, maybe [08:42] it doesn't do what I thought it does, though, so never mind [08:42] 'bzr import' is part of bzrtools. [08:43] ah, ok [08:43] https://lists.ubuntu.com/archives/bazaar/2006q2/012039.html is how to do it [08:43] shame no one has automated it yet [08:43] http://paste.pocoo.org/show/24401/ is the help for it. [08:44] Ick, that's a lot of manual labor. [08:45] Guess I'll have to keep using svn/piston. :( [08:47] How would I do this in bzr if svn wasn't a part of the picture? [08:48] Let's say libst and libtu were maintained as bzr branches... I'd like to include them directly in my app. [08:49] Is there an easy way to import upstream libst into a local/libst in my app's repo, then pull changes using regular bzr commands? [08:49] config-manager [08:50] Hm, interesting. [08:50] I'll have to play with it. [08:50] bronson: You could have a bzr branch for your stuff, which contains other bzr branches. [08:51] But this wouldn't ensure that the revisions of the sub-branches would be the same everywhere. [08:51] But reading the docs, config-manager has an icky, tla sort of feel to it... [08:51] I could be wrong. [08:51] haha [08:51] it may perhaps date from that era [08:52] bronson: Posting to the list might help you out, as you'd be able to describe the scenario in more detail and more eyes will see it. [08:52] True. I was hoping this was an easy question. [08:53] Guess not. Oh well. [08:53] I'll hit the list if I can't find easily another vcs that will do it. [08:53] Thanks for your help. [08:54] bronson: No worries. [08:56] bronson, this is handled by the subtree feature [08:56] poolie: that sounds promising. [08:56] please post to the list and someone can give you a pointer [09:36] how do you create release tarball with bzr? === kiko-zzz is now known as kiko [10:03] Aloha: bzr export foo-1.0.tar.bz2 /path/too/foobranch [10:03] Aloha: is one option [10:03] Aloha: personally I use autoconf and automake and do 'make dist' :-) [10:04] i don't have those though. my program is Ruby [10:06] does ruby not have some kind of distribution maker? [10:07] Kinnison, maybe i'm not sure [10:07] python has distutils [10:07] perl has Makemaker [10:07] I'm sure ruby must have something [10:07] ruby has makemaker [10:07] i'm asking in #ruby-lang [10:17] I think it is rake [10:18] Aloha: ruby has rake iirc [10:22] Makemaker is ugly. :( [10:23] Hi I notice that the bazaar website is not updated very frequently. is there anywhere else that the current developments are captured? [10:24] I'd like to volunteer time to help distribute this information if that would help? [10:24] Hi folks, im new to bzr. Im wondering if several branches can be created under one main working directory, each containing number of not overlapping subdirs? [10:25] zurgutt: no (if I understand you correctly - several branches, not containign any files or dirs with the same name, checked out in the same directory) [10:26] essentially groups of subdirs belong to separate projects and id like to be able to work with one group as unit, commit it etc [10:27] deepjoy: Most of the development work takes place on the mailing list, as well as in the bug and specification management parts of Launchpad. [10:27] it'd be neat if someone was willing to do a weekly "bzr traffic" news thing [10:30] one solution offered was to symlink those groups of dirs under separate workspace dirs elsewhere and there create branch for each. Im just trying to make sure im not missing any simpler way of doing this, named branches or whatnot :) [10:35] odd_bloke: cool I'll subscribe to the mailing list and try doing that for a few weeks [10:36] I think a non-python/bzr intricacy level information is required for popular uptake [10:37] What sort of stuff would you expect to see in the news thing? [10:37] new formats and their level of experimentalness, that changes at least once a week [10:38] feature dissection from a layman's perspective. e,g, "bzr+http needs verb addition" translates to "bzr over http performance improvements" [10:39] does that make sense? [10:40] How useful would that be on a week-by-week basis? It seems more likely that something of this ilk when a new release happens might be more effective/useful... [10:41] thats why I though the website was a better place to put such information [10:45] I dunno, I think it's too transient to go on the website. [10:45] Perhaps a blog post talking about a new version (i.e. paraphrasing the interesting parts of the NEWS file) might work. [10:47] how do you install branch into current directory without creatingnew directory? [10:48] how do you install branch into current directory without creating a new directory? [10:48] like if i wanted to do bzr branch http://bazaar.launchpad.net/~tjgillies/shakabuntu-surf/devel [10:49] "bzr co http://blah/ ." works, while branch does not [10:49] so you could co, then "bzr reconfigure" it to a branch [10:50] New bug: #186975 in bzr "cannot rename files to names with slashes" [Undecided,New] https://launchpad.net/bugs/186975 [10:51] i push a checkout back to devel or does it need to be a branch? [10:51] i'm trying to have an upstream working directory and a package working directory and i'm trying to sync their files [10:52] because i'm upstream and maintainer === weigon_ is now known as weigon [11:40] New bug: #187008 in bzr-svn "bzr-svn try to use too long knit name incompatible with Windows filesystem" [Undecided,New] https://launchpad.net/bugs/187008 [11:48] Is it possible to specify a port when performing a bzr operation over sftp? [11:48] gmb: have you tried sftp://host.com:4444/path ? [11:49] dato: I've tried it, but there is much sitting there and doing nothing going on :/ [11:49] it should work [11:49] Hmm. [11:49] tcpdump for the win [11:49] Ah. [11:49] No, wait, my balls up. [11:50] It might be working now... the fact that my connection has slowed to a crawl suggests so... [11:50] Thanks. [11:54] :) [12:29] jelmer: hi [12:29] bialix: Hey [12:30] I'm playing with bzr-svn and I'm stuck [12:30] C:\work\Temp\scmrtos.repo>bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/trunk/ [12:30] bzr: ERROR: /trunk is not a valid Subversion branch path. [12:30] See 'bzr help svn-branching-schemes' for details. [12:31] try removing subversion.conf and try again [12:31] appears to work fine here so far [12:35] subversion.conf in the bazaar config directory, not sure where that is on Windows, but I'm sure you do :-) [12:40] it's strange because bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ works fine [12:40] that's because that's probably the first url you tried [12:40] but it ends with branch containing trunk, branches, tags subdirs [12:41] bialix: if you remove subversion.conf, you should be able branch /trunk again [12:41] also I have similar problems with trac-hacks.org svn repo [12:42] branching scrmtrtos trunk works fine here [12:44] yeah, after deleting subversion.conf it does [12:44] jelmer: overall it seems that bzr-svn standalone installer verison works fine [12:45] bialix: cool [12:45] bialix: does the test suite run ok? [12:45] I just don't understand all limitations of svn support [12:45] I don't run it [12:45] yet [12:49] I would be interested in seeing the output when you get around to that :-) [12:49] test suite output? [12:50] yeah [12:50] I suspect there will be at least some failures [13:01] jelmer: when I try to branch another branch from scmrtos svn repo I get the same error. [13:02] again delete subversion.conf? [13:02] something really weird going on here, IMO [13:02] bialix: what path are you trying to branch exactly? [13:05] um, wait [13:06] no, sorry, operator error [13:06] now it works fine [13:07] does bzr-svn allows to create new branches in svn repo? [13:08] yes, using the "svn-push" command [13:10] tags is used as branches or they mapped to bzr tags? [13:14] tags are used as branches for now === bialix__ is now known as bialix [13:21] jelmer: one more question please. do I need bzr-svn plugin installed all the time to work with branched svn trunk? [13:21] bialix: no, not at all [13:21] only when interacting with svn [13:22] ah, ok, cool [13:22] (pulling/merging from svn or pushing to svn) [13:22] indeed cool [13:25] New bug: #187037 in bzr-gtk "gpush fails with unsupported operand type(s) for /: 'float' and 'NoneType'" [Undecided,New] https://launchpad.net/bugs/187037 [13:43] abentley: ping [13:43] vila: pong [13:44] vila: bonjour [13:44]