[00:42] NfNitLoop: pong (sorry for the delay) [00:42] NfNitLoop: still around? [00:43] beuno: thanks for the redirect ;-) (don't hide, if I can get some spare time, NetBeans is the next IDE to integrate:-D) [01:01] Verterok: I'm around-ish. :) [01:02] Hi NfNitLoop [01:03] H'lo. [01:03] I don't know that I'll actually be writing (or even needing) a Netbeans bzr addon, I was mostly inquiring if anyone had started that work. [01:04] NfNitLoop: just to let you know, as part of bzr-eclipse (but not coupled) I wrota a Java library that wraps all the mechanics to call bzr-xml and it parsing [01:05] aah, cool. [01:05] so that would be portable, eh? [01:05] It's not too tightly coupled to the eclipse APIs? [01:05] NfNitLoop: it's a standalone Java lib :-D [01:06] ah, well then. :) I'll be sure to keep it in mind should I become inspired to write an addon. :) [01:07] I use bzr-eclipse, though, in the meantime. Good stuff. :) [01:07] Actually, while I've got your ear... [01:07] I started to look the NetBeans hg plugin, it's nice, but to adapt it to bzr, it need a major rewrite [01:08] I set up eclipse to show a quickdiff with the latest bzr revision, but for some reason it seems to stop updating after i've committed. [01:08] seen anything like that before? [01:08] NfNitLoop: Oh, Great you like it [01:08] Yup! [01:08] oh, weird. could you fill a bug? :) [01:09] Sure. [01:09] I'll have to figure out how to reproduce it first. :) [01:09] I'm going to make a new build soon, maybe I can work on this before that [01:10] 'k. Well, I'm off to dinner. *wave* [01:10] no problem, just fill the bug, I'll try to reproduce it [01:10] blueyed: hi [01:10] NfNitLoop: bon appétit [01:11] blueyed: the problem is, I have a plugin but there is no start-commit hook yet [01:23] aha.. loggerhead fails on my .qs file [01:28] .qs == ? [01:29] quickstart [01:30] since kickstart uses ks [01:30] what is a quickstart [01:30] an automated installer for gentoo, modeled after kickstart , which is an automated installer for fedora [01:31] ah [01:41] jelmer: so the pre-commit hook cannot modify the tree (with calling "bzr add" or some such)? [01:42] blueyed: nope [01:42] blueyed: at that point the tree is already finished [01:42] blueyed: we need a new hook (in WorkingTree) [01:43] yay for 500 errors :( [01:44] jelmer: ok, so I can put my half-assed plugin aside and get the package as good as possible for FFe (and to send it upstream, who has been very responsive). [01:45] * johnny uses too many vcs [01:45] now in one day, i have to use svn, bzr, git, mtn ,cvs :( [01:46] johnny: a lot of practice ;) [01:47] even just contributing to make ltsp work in gentoo requires svn,bzr,and git [01:47] if i was an official dev, i'd have to use cvs too [01:47] most of my cvs is read.. not write atm luckily === mw is now known as mw|out [01:49] I just committed some changes to my local repo that I'd like to uncommit, but still have the changes in the repo... will "uncommit" do that? [01:50] s/repo/branch/ [01:50] blueyed: all the work in upstream is already done, it's bzr that needs patching [01:50] blueyed: not sure I understand what you mean [01:53] jelmer: for Ubuntu. bzr has been integrated in Debian, but there are still some issues and I've hoped I could add the pre-commit somehow, too. [01:54] blueyed: the pre-commit stuff isn't in debian yet either [02:00] jelmer: btw, bzr-svn rules [02:00] thanks for it [02:01] mxpxpod: thanks, that's good to hear [02:01] blueyed: bug 186422 [02:01] Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422 [02:01] jelmer: I use it to track and develop all of my svn projects that don't have externals [02:02] jelmer: I've seen that bug already.. (and your work on it, which suddenly stopped) [02:02] mxpxpod: hopefully externals will be supported soon too, once bzr itself supports nested trees [02:02] jelmer: I've tried bzr-svn, too, but it had serious memory problems (which I have worked around). [02:03] blueyed: most of those should be fixed in hardy [02:03] the only thing I wish I could do would be to get svn revision numbers along-side bzr revision numbers in the log [02:03] jelmer: great to hear. [02:03] blueyed: the bugs were actually in python-subversion [02:06] blueyed: is it likely that bzr 1.4 will make it into hardy? If so, I could probably have a look at getting that start-commit hook in.. [02:06] jelmer: when is it to be released? [02:07] jelmer: 1.3 has just been released, not? [02:07] ..and the rc for 1.3.1 [02:07] jelmer: so, quite unlikely [02:08] jdong: 1.4rc1 is planned for next friday [02:09] jelmer: hmm if Debian can get their packages for 1.4 up soon after that I would try filing a freeze exception for it... [02:10] jelmer: but I think the release managers may be a bit gunshy after the 1.3->1.3.1 thing... :( [02:14] jelmer: if you have the time, please try getting hook improvements in. [02:36] Hmm, there's no mutabletree tests? [02:37] jelmer: Nope, you can do anything you like to 'em. [02:37] That's what makes them so mutable :-) [03:38] abentley: lol [04:27] jelmer: nice, thanks! Those hooks get installed like the current ones, as a plugin, correct? [04:35] blueyed: yes, and the matching plugin is already in my etckeeper git repository [04:40] blueyed: hmm, it looks like upstream merged another branch that adds support for bzr [04:40] jelmer: yes, it has been submitted in LP and I've forwarded it.. it's quite the same though. [04:41] I have some fixes laying around here, and looked at your branch also.. I'll try to submit it tomorrow.. [04:45] Good night. [06:15] New bug: #212083 in bzr-gtk "viz displays wrong revnos, tries to display NULL revision" [Undecided,New] https://launchpad.net/bugs/212083 [07:41] jelmer: you around? i filed the 170000 exception bug... investigating stuff now [08:30] hello #bzr [10:00] I've noticed when I commit a change --- even a small one --- to an upstream repository via ftp there seems to be a fairly large download from the repo. Is this normal? [10:01] Are you using a lightweight checkout? That would make it worse than usual. [10:02] Is upstream using the latest disk format (packs)? [10:02] Also, the smart server would provide better performance. [10:02] (Also, FTP? Ew.) [10:03] It's a full checkout, rich-root-pack. [10:03] The repo is on the 60 MB of free web space I get with my ISP, ftp only. [10:04] I haven't looked to see if I can get the server running, but I very much doubt I'd be able to. [10:04] Yeah, if you only have FTP access, that's very unlikely. [10:04] It would be quite easy if you had SSH, but... [10:05] I'll pony up for a real web server one day. [10:05] If it's a FOSS project, you could host it on Launchpad. https://launchpad.net/ [10:06] cammoblammo: You don't need a real web server. You could get the smart server running on many shared hosts, if they provided SSH. Even just using nice, encrypted SFTP would be better than FTP... [10:07] Unfortunately, it's not. It's mainly papers written in LaTeX, music written in LilyPond and other things with weirdly capitalised names. [10:07] They don't have ssh. That was the first thing I asked when I signed up. You get what you pay for, I guess. [10:08] Oh, what bzr version? Performance has gotten better over time. [10:09] bzr version 1.3. I suppose it doesn't get too much better than that! [10:09] :) [10:09] It does seem to have improved since 1.2 [10:09] What's the download for? Does it have to compare with what the repo has before it commits? [10:10] Yes. [10:10] It also has to upload the new data, of course. [10:11] Pack repos also have to be repacked occasionally, which requires downloading a portion of the history and uploading it again. [10:12] Of course, Then again, a 1 or 2 MB download in order to upload a 3kb diff seems a little unproportional. This is probably the only complaint I have after moving from svn. [10:13] How large is the branch? [10:14] Peng: According to bzr info -v it's 13436 KiB [10:15] Downloading 1 to 2 MB sounds bad. [10:15] I'm not a bzr expert, so I can't be of any more help.. [10:15] Feels bad too, especially when my office shares a 256 kbps 'net connection, and two other workers are using heavy web apps. I can be very unpopular sometimes! [10:16] Ouch. [10:16] Peng: That's cool. I just wanted to make sure it was normal and the problem was my braindead way of having to use it. [10:17] It surprises me, but I'm really not an expert. I doubt you're doing anything wrong. [10:17] Tell my coworkers that ;-) [10:18] At least you're not running BitTorrent. ;) [10:20] Peng: True. In fact, we have a 600 MB per month limit on our connection, after which we pay something like a dollar a meg. Our corporate headquarters assures us it's all we need. [10:21] Peng: It's not all /I/ need, though. [10:25] Wow. [10:25] Um. [10:25] Where did you find this ISP? [10:26] Or are you in Nowhere, Africa where the nearest power line is 500 miles away? [10:27] Peng: I didn't find it. It was in the memo that came from HQ, along with a modem/router, instructions to install it and a phone number to ring to get our IT department to pcAnywhere in so they could get us on the VPN properly. [10:27] Peng: I live in the country, but the same thing goes for offices in metropolitan Melbourne. [10:28] Peng: 'Information Technology' is something of a misnomer. [10:29] You could each chip in like $10 and get a real Internet connection for the office. :P [10:31] We could, but then we'd lose the 10.x.x.x IP addresses we've been so lovingly given in order to connect to our 'precious' web apps. Besides, they'd have to authorise the release of the line from our ISP and they'd keep charging us $25 p/m! [10:32] If they ever found the GNU/Linux computer in my office, there could be some real trouble... [10:36] It must be technically possible to get a real connection, use it for the outside, and keep the old one for the corporate stuff. [10:36] But anyway... [10:37] The company sounds pretty cheap. Do you have cardboard desks too? :\ [10:47] Peng: You'd think so. Getting another connection is a bit of work, and the only reason we really need it is so I can use bzr, which is officially verboten anyway. It'll be easier and cheaper to move my repo to a better hosting service. === doko_ is now known as doko [10:55] cammoblammo: ftp, sftp and rsync are dumb transports [10:56] asabil: That's very true. [10:56] so they are not really efficient, and iirc bzr repositories are not append only (correct me if I am wrong) [10:57] the best you could do is move the repository to a host that has an ssh connection, so that you can use the bzr+ssh transport [10:58] asabil: I think you're right, unfortunately. If my ISP used ssh it would be nice, but they don't seem to see the need. It's free space, after all. [10:59] cammoblammo: you can also try bzr init --append-revisions-only [11:00] never used it, but it seems to force an append only repository similar to mercurial's [11:01] asabil: I'm guessing functionality is lost? Or am I reading the help wrong? [11:02] yes you might lose some functionality [11:02] an uncommit followed by a push won't work [11:03] I doubt that would help. [11:03] a push --overwrite won't work either I think [11:03] I expect that has to do with history, not files. [11:03] It's not like it would use a completely different repo format. [11:03] And if for some reason it turned off repacking, that would be awful for performance. [11:04] right [11:04] cammoblammo: do you have to host your code somewhere else ? [11:04] I mean you can still use a local server in your office [11:04] can't you ? [11:08] asabil: I can host it at home, but it would be nice to have it offsite somewhere. I'm still thinking in svn term, though. There's no reason why my home branch couldn't be a notional 'repository' and still have my host for backups and uploading when I'm on holiday. [11:08] yep [11:09] or you can also use some other machine in your office [11:10] I can't connect to the office from outside --- everything's firewalled up the wazoo. Their ISP policy might be crap but the security's pretty tight. [11:11] do you need to connect to the office from outside ? [11:11] I mean, if I understood it correctly, you just need a hosting for backup purposes [11:12] and you are the only one working on that branch [11:12] right ? [11:12] I should mention that I do most of my work from home. I only have a branch at the office for convenience. It's largely work related, but I can choose where I work! [11:13] yes that's fine, just create a branch on your laptop for example [11:13] and when you get to the office push the branch to your backup server [11:13] and keep working on your own branch on your laptop [11:14] I could just have a branch on my USB drive. When I moved house a few weeks ago and I was without a connection that worked quite well. [11:15] My laptop... well, it's pretty crusty and I only use it when I'm away. [11:16] I added "http://ppa.launchpad.net/bzr/ubuntu" to my repositories, however, synaptic reports that some packages are unauthorized. Which keys must I add in order to avoid this message? I added the key of the uploader (mpl) but this didn't help. [11:37] Bronger: apt-get update should tell you the key ids. [11:37] Bronger: after that you can use gpg to fetch these from the keyservers. [11:37] Yes, I know this procedure. It worked well for bzr-svn. [11:37] Bronger: now, that is critical, call the key owner to verify the fingerprint :-P [11:38] Bronger: after that you export the key from the gpg keyring and add it with apt-jet [11:38] apt-key [11:38] A second source that is a simple server which is improbable to be hacked is enough. ;-) [11:41] yacc, apt-get just tells me that there aren't any updates. Isn't there a possibilitry to just give a URL and Ubuntu tells me with which ID it it signed so that I can look for this ID on the net? [11:42] apt-get install package should also complain :-P [11:45] Yes, but only that it couldn't be authenticated. Isn't it signed at all? [11:47] Bronger: that's theoretically possible too. === asak__ is now known as asak [11:50] you could also make apt-get refetch the data and recomplain, using such a standard tool like rm :-P [11:58] Bronger: the packages aren't signed at all yet unfortunately [12:10] New bug: #212193 in bzr "bzr crashed while pushing" [Undecided,New] https://launchpad.net/bugs/212193 [12:25] New bug: #212195 in bzr "Cannot use backslash character in file name" [Undecided,New] https://launchpad.net/bugs/212195 [12:35] hello [12:35] is there a good writeup of branching/merging with bzr? [12:36] i want to make a branch for a feature i'm working on [12:46] bzr branch my-feature [12:46] from [12:46] hack hack hack commit [12:46] cd from [12:46] bzr merge ../my-feature [12:46] comit [12:50] ah, that's all? thanks [12:50] and do i need to keep that branch for further hacking? [12:52] or do i need to rebranch after the merge or something? [12:54] You can do what you want. [12:55] You can just delete the branch if you want to. [12:56] You can "cd my-feature && bzr merge ../from && bzr commit -m 'Merge from from' && hack hack hack" and eventually merge it back into from again. [12:56] Stavros: This helped the penny drop for me: [12:56] Stavros: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#organizing-branches [12:56] aha, hmm, well, i'm wondering how the graph will look in that case [12:56] ah, i'll read that, thanks [12:57] np [12:57] although i did read everything before it first :) [12:59] haha [12:59] i'll try that too, then :p [14:09] just to get this straight, when you are working on a feature branch, you "merge" instead of "pushing" because the branches might have diverged, correct? [14:11] When the branches have diverged, you merge. When they have not, you push/pull. [14:11] If you try to do the wrong thing, bzr will tell you. [14:11] chandlerc: ping [14:17] Peng: great, that's what i needed to know, thanks [15:10] New bug: #212289 in bzr "test_diff.TestDiffFromTool.test_prepare_files fails on Windows" [Undecided,New] https://launchpad.net/bugs/212289 [15:15] asabil: Logically, all bazaar repositories are append-only. Physically, knit repositories are append-only and pack repositories are write-once. [15:15] Physically on the file level, that is. [15:18] oh oki, didn't know [15:18] thanks === mw|out is now known as mw [16:10] New bug: #212325 in bzr-pqm "Should support pqm_cc / pqm_bcc settings" [Undecided,New] https://launchpad.net/bugs/212325 [16:17] hmm, bzr always gives me trouble updating tags, anyone know why that is? [16:20] New bug: #212333 in bzr-pqm "Doesn't expand directory services in URLs" [Undecided,New] https://launchpad.net/bugs/212333 [17:16] Can one just use the GNU Arch functionality of Savannah.gnu.org to manage Bazaar branches? [17:35] Bronger: what sort of gnu arch-specific stuff does savannah support? [17:37] Actuall I don't understand really what's there on the server side. http://lists.gnu.org/archive/html/savannah-hackers-public/2008-03/msg00033.html suggests that I already can use Bazaar on Savannah. But Bazaar is *nowehere* mentioned on the site. I can only activate GNU Arch services for a particular project. [17:38] And, I don't know how similar Arch and Bazaar are so that support for one implies support for the other as well. [17:42] Bronger: it looks like the arch support is simply a sftp server [17:42] Bronger: if that is the case, you should be able to use bzr with it as well [17:43] Okay, thank you! So far, I've used Bazaar in remote operation only with Launchpad. Let's see whether I manage this sftp thing, too. ;-) === mw is now known as mw|brb [18:01] hello [18:04] what does it mean if someone says Patch against bzr? [18:11] BeeUteefool: can you give some more context? [18:12] * GNOME_Desktop_User_Guide_Inconsistency, changed group to layout (922 bytes, text/plain) [18:12] Fixed this in gnome-user-docs. [18:12] Patch against bzr. [18:13] please visit this link so that you'll get more context... https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/205140 [18:13] Launchpad bug 205140 in gnome-user-docs "'GNOME Desktop User Guide' Inconsistency" [Undecided,Confirmed] [18:14] so what does it mean this Patch against bzr? [18:36] With 1.3, is anyone seeing "ssh: connect to host bzr.fedorahosted.org port 22: Connection timed out" === mw|brb is now known as mw [18:37] I've been seeing this since upgrading. I've also had bzr just hang somewhere near the start of a pull... I'm wondering if it's all related. [18:39] hmm.... and it looks like bzr-webserver works with bzr-1.2 but not bzr-1.3 :-( [19:05] Hi [19:05] I'm trying to push to an SVN repo with bzr [19:05] but I get "Unable to handle http code 401: Authorization Required" [19:07] anyone knows how to handle this? [19:15] xif: include user+password in the URL? [19:15] svn+http://user:password@hostname/path [19:16] bzr: ERROR: Invalid url supplied to transport: [19:16] it treats the : as a port number. [19:16] xif: don't think so, I'm using the same format, albeit with https. [19:17] bzr: ERROR: Invalid url supplied to transport: "invalid port number [19:17] xif: OTOH, you might have some specific "values" in your URL. [19:17] Try: [19:17] Access it via svn: [19:17] svn ls http://.... [19:17] make svn remember the password [19:18] try bzr with username but without password [19:19] yacc: doesn't work :/ [19:19] `svn ls` works just fine [19:19] bzr without user+password doesn't work [19:19] xif: jelmer is your best bet then :-P [19:20] Well, you need to specify the user for sure. [19:20] I think I found the possible cause of the problem though [19:20] Yes? [19:20] my username contains a @ [19:20] any idea how to fix that? [19:21] (this seems to be a cause for the parsing error above) [19:21] xif: hi [19:21] hello jelmer [19:21] xif: try without including the username + password in the url [19:22] bzr: ERROR: Invalid http response for http://svn.devjavu.com/xif/linux_settings/.bzr/branch-format: Unable to handle http code 401: Authorization Required [19:22] please prefix the url with svn+ [19:26] (svn+http://svn.devjavu.com/...) [19:26] OK, sec [19:26] I'm in the middle of upgrading bzr+bzr-svn [19:26] bzr-svn: Depends: python-central (>= 0.6) but 0.5.15ubuntu2 is to be installed [19:30] what distro? [19:31] Ubuntu Gutsy [19:32] the problem is that the most up-to-date python-central for Gutsy is 0.5.15 [19:32] I think there are quite recent versions in gutsy-backports [19:32] of bzr and bzr-svn [19:33] jelmer: OK, any idea how I install it from there? [19:34] I do have latest stable bzr installed [19:34] OK, found it [19:35] jelmer: thanks for reminding me; need to get bzr 1.3.1-ish backports going :) [19:36] BeeUteefool: i think it means someone has a patch which applies against the tip of a bzr branch [19:36] it's an odd way to work, because it would be easier to have their work in a bzr branch [19:37] OK, nothing works [19:38] xif: installing the packages you mean? [19:38] jelmer: yeah, I get the same error after adding gutsy backports to the sources.list [19:38] xif: about python-central you mean? [19:38] needs python-central >= 0.6, only has 0.5.15 [19:38] yup. [19:39] xif: Do you happen to have any other entrise in sources.list, such as ppa? [19:39] yes [19:40] deb http://ppa.launchpad.net/bzr/ubuntu gutsy main [19:40] deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main [19:40] maybe I should have just stayed with bzr 0.9? [19:41] (the latest in Gutsy's repositories) [19:41] trying to upgrade seems to put me in a worse position than I was. [19:42] you mean 0.90? [19:42] yes [19:42] xif: the PPA tends to be out-of-sync a lot more often than backports [19:42] so what should I do? [19:43] remove all the PPA entries and try to install from backports? [19:43] xif: It'll probably work better if you remove PPA [19:43] k, trying [19:43] xif: yeah, I recommend removing the PPA entires and using Backports [19:44] xif: I can only upload to the hardy PPA [19:44] xif: I think the gutsy one is at least a couple of versions behind [19:45] OK, be advised that the latest bar in backports is 1.0-1~gutsy1 [19:45] installing that right now. [19:48] OK, I downgraded to 0.90 again [19:48] jelmer: tried the following: [19:48] bzr svn-push svn+http://svn.devjavu.com/xif/linux_settings [19:48] result: [19:48] bzr: ERROR: libsvn._core.SubversionException: ("Undefined tunnel scheme 'http'", 125002) [19:49] I think maybe I should save some time and just use SVN. === oleavr is now known as oleavr-food [19:52] xif: and with "bzr push" rather than "bzr svn-push" ? [19:53] jelmer: same error. [19:53] jelmer: (note that I'm on 0.90 again) [19:56] OK, I already spend two hours on this. [19:57] investing more time in this doesn't seem logical, but thanks jelmer. [19:58] don't go with svn :( [20:02] johnny: it's not like I have much choice, I need to commit to a remote SVN server. [20:02] uggh. [20:03] lots of the gnome folks are so irritated with svn, they are creating their own git repositories and committing to that for their own work,and then running some script to convert to svn [20:03] kinda silly :( [20:04] well, the best option for me would have been to keep using my bzr repo and commit from it. [20:04] except it doesn't work. [20:06] johnny: it's silly and then not so, svn being the lowest common denominator, that is needed for a somewhat modern VCS (atomic file set changes, but missing some metadata, notice how each of the SVN interoperability tools tend to define and use their own merging properties, e.g. svk, bzr-svn) [20:07] sure, but i'm used to using other vcs for my upstream work :) [20:08] so working with svn still feels uncomfortable due to lack of local history [20:12] johnny: I always use svk with svn, it's relationship with svn being way stronger than say bzr-svn, it basically works. [20:12] If you can wait the 2secs or so perl takes to compile SVK on each command [20:13] i've been using monotone for quite some time, never saw a reason to use svk i guess [20:13] and use svn for my own stuff in the process that is [20:15] yacc: you mean because it doesn't have the branching scheme stuff or other things as well? === mw is now known as mw|out === oleavr-food is now known as oleavr [21:26] New bug: #212477 in bzr "bzr init-repo over sftp fails" [Undecided,New] https://launchpad.net/bugs/212477 [21:54] johnny: you know, SVN ain't so bad [21:54] obviously it sucks when you don't have server access. [21:54] and it would be great to sync only when I want to. [21:55] but as long as the intertubes work... [22:08] Except for the lack of renames, linear history, bad performance (or so I've heard; FSFS's file layout isn't good though), bad disk space use... [22:09] Apparently the API is ok though, or else jelmer would have long gone insane working on bzr-svn. ;) [22:11] Peng: Not sure if he hasn't gone insane :-P [22:12] Well, he *does* only use one space in between sentences. [22:13] jelmer: my comment was "pragmatic". Svn is "simple enough" that even sub-average developers can somehow use it, and most more advanced VCS have some form to interoperate with svn. And svk makes it bearable in practice. [22:13] Even more bearable would be using any of the other VCSes... [22:14] But, I don't know what the conversation has been. [22:14] I just like insulting svn. :) [22:17] yacc: I meant more in terms of comparison between bzr-svn and svk [22:20] I'm just starting out with bzr. We're two people with laptops and we'd like to follow the "partner" workflow described at http://bazaar-vcs.org/Workflows is there a more detailed howto for that? [22:21] i.e. what commands to enter, what our choice of transports are (we'd like to use email or I'm) but can't seem to make "bzr send" work ("no submit branch known or specified") [22:21] er, "or IM" :-) [22:35] stefan_today: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sharing-with-peers [22:38] stefan_today: and http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes [22:38] stefan_today, you can do bzr send -o file.patch [22:38] and email the file to eachother [22:39] (which is basically what the 2nd link says) ;) [22:41] jelmer, around? [22:42] so the "no submit branch known or specified" message is ignorable? [22:42] stefan_today, well, it depends [22:43] the workflow I usually have [22:43] is branch trunk (or whatever you are working on) [22:43] then, branch that locally to a "feature branch" [22:43] so, there you have a submit branch to compare against [22:45] the submit branch being your first local branch? does the recipient of that merge directive need to have access to trunk? [22:46] stefan_today, yes, the sumbit branch will automatically be the first local branch (where you branched from) [22:47] the other recipient oes not have to have access to trunk, no. He recieves a standard patch with some bzr metadata that he can use to merge, if he has a branch with common ancestry [22:54] ok, so if one of us were to zip up and send a branch (including .bzr directory) to the other as a starting point, we could each branch from that original branch (so we have common history) and email merge directives back and forth thereafter? [22:56] stefan_today, yeap, exactly [22:59] beuno: hi [23:00] jelmer, hey :) [23:00] I was thinking about starting to cook up something like we talked about in the sprint, about having easier collaboration in a network [23:01] have one screen where you see everybody in the network, what they are working on, etc [23:01] using avahi and al that magic [23:01] beuno: ah, something like a GUI for avahi? [23:01] jelmer, exactly [23:01] jamesh may have some thoughts about that [23:02] do you think I should work on it as part of bzr-gtk or a seperate project? [23:09] cool, we're up and running. thanks beuno. thanks bimberi [23:10] stefan_today, welcome and good luck :) [23:22] beuno: doing it as part of bzr-gtk sounds sensible (if it's going to be gtk based :-) [23:23] jelmer, absolutely, pygtk [23:23] as long as bzr-gtk doesn't get a hard dependency on bzr-avahi, but that shouldn't be hard [23:25] jelmer, I'll do my best. And if it does, I'll just seperate it === pmezard is now known as pmezard|afk