=== kiko is now known as kiko-afk === mw is now known as mw|out [02:58] Are there any ways for multiple people to access repos on my machine through a single ssh account, but not let everyone have access to every repository? [03:55] When I am in the commit log editor after running "bzr commit", "bzr diff" gives an error message about some locks and can't produce a diff. Is this expected? Is it possible to change this? Should I report a bug? [09:10] hi, one question, can't bzr handle umlauts in filenames? [09:11] if have a bzr repo pushed to a sftp location and branched it via http and the umlaut is replace by two ## [09:12] i created the repo on a linux machine with utf8 and branched it on a mac os box [09:12] the mac file system does unicode NFD normalisation [09:13] bzr will preserve the umlaut happily - branch it onto e.g. a iso-8859-1 locale, or windows, or even utf16 and it should all work fine, but mac's give us grief [09:14] ah ok :) damn mac filesystem [09:14] ah i just found the unicode page on bazaar-vcs.org [09:16] so it doesn't work right now? [09:20] well, it should preserve the filenam when you go back to unix IIRC, it will depend on what bzr st shows [09:20] but yeah, expect some glitches I think :( [09:20] gotta run, ciao [09:22] cu and thanks for the help === quicksil1er is now known as quicksilver === asak_ is now known as asak [17:22] ping [17:25] pong [17:35] New bug: #186194 in bzr "option to follow symlinks" [Undecided,New] https://launchpad.net/bugs/186194 [17:56] Hey guys, i have a problem with the launchpad plugin it seems. On the launchpad page, it says that i can push using the lp:~username.... string, but doing that bzr errors out with a "cannot lock" error because it redirects to an http location. Is this is a bzr thing or is the launchpad page wrong? === abadger1991 is now known as abadger1999 [18:45] Hey ! [18:45] I'd like to know if it is possible to specify a port when you commit on bzr+ssh :) [18:46] cause I'm behind a proxy and one of the only open port is 443 [18:46] so I have to commit through that :D [18:46] I made my sshd listen on both port 443 and 22 but I need to specify it on the command line [18:53] afaik bzr+ssh://host:port/ should work [18:57] hum OK [18:57] thx [19:09] hello [19:09] is there a visual studio bzr plugin available? === abadger1999 is now known as abadger1999_afk [21:21] jelmer: ping [21:22] schierbeck, pong [21:22] | * [21:22] * [21:22] * [21:22] | * [21:22] hah! [21:23] jelmer: do you have 2 minutes to talk about the viz? [21:23] :-) [21:23] sure [21:24] i'm thinking about adding in the About window again [21:25] i think it's important that it's there [21:25] but should Olive and the viz share the same window? [21:25] i kind of consider them different applications, which happen to reuse some of the same widgets [21:26] yeah, same here [21:26] Adding an about dialog would be a good idea [21:28] the thing is, i consider the viz to be part of the core bzr-gtk, while Olive is more peripheral to me [21:28] but then again, i'm not an Olive user myself [21:28] i think they should have different About dialogues [21:30] I think there already is a bzr-gtk About dialog [21:30] we could just use that [21:32] okay [21:32] i'll hook up the menu to it [21:39] jelmer: the current about dialog shows info on bazaar, not bzr-gtk [21:40] it should be adapted then [21:44] done [21:44] i'll push it to lp, 30 sec [21:45] this version also reads in COPYING instead of just displaying "GPL v2" in the license window [21:46] http://bazaar.launchpad.net/~dasch/bzr-gtk/viz-about-dialog [21:50] jelmer: do i need to send in a merge request? after all, we're the only two active devs atm [21:50] Ooh, people are touching viz? [21:51] schierbeck: well, a patch to the list would be useful in any case [21:51] fullermd: :) [21:51] jelmer: okay, i'll send it in [21:51] * fullermd pimps for bug 183627. [21:51] Launchpad bug 183627 in bzr-gtk "viz crams revid onto your clipboard" [Undecided,New] https://launchpad.net/bugs/183627 [21:53] jelmer: sent [21:55] fullermd: i'm not sure how to get around it [21:55] the fields ought to be selectable === bitmonk_ is now known as bitmonk [22:00] Selectable is great; it's the autoselecting part that's... well, kinda offensive. [22:06] fullermd: i know, i'm looking into having it not do it [22:07] * fullermd nods. [22:07] It's not like it's a big thing. [22:07] it's puzzling me atm [22:07] Just a rather irritating small thing. [22:07] yup [22:08] jelmer: at some point we need to talk about the Changes page [22:08] i still think it's a good idea [22:09] schierbeck: ok, will have a look at your merge request later today [22:10] thanks :) [22:10] schierbeck: I still don't, for various reasons [22:11] fair enough, just as long as we can discuss it [22:12] Perhaps we can come to a compromise or something [22:13] yup [22:14] i'm thinking about perhaps getting rid of the Relations page, to cut down on complexity [22:14] It's not as much the complexity that I have problems with [22:14] It's the fact that it mixes metadata with contents in the same widget [22:14] a widget which is meant to be relatively small (sufficient to display that metadata) [22:15] and doesn't allow diffing against multiple parents [22:15] the current version does allow diffing against multiple parents [22:15] still haven't implemented the file list [22:15] but it's coming [22:16] The file list is going to take up a fair chunk of space [22:16] more even than the metadata usually needs [22:16] i'm thinking about using a toggle button to show and hide it [22:16] I would rather just have an optional diff widget below the metadata [22:17] i don't think it'll be a real issue [22:17] i think another widget *would* add to the complexity [22:17] It's separate of the metadata [22:17] The size is really going to be an issue [22:17] would still introduce more content on the ui at the same time [22:18] i think we should try it out before deciding on that; i really get a lot of requests for this feature [22:19] besides, in the viz, the revisionview widget is as wide as the diff window itself is [22:19] I've tried your branch, and it really doesn't work well for large commits [22:20] yeah, it needs the file selector widget [22:20] yes it would be as wide, but the metadata bit is supposed to be quite small [22:20] (in height, that is) [22:21] the user can freely change the height if it becomes necessary [22:21] i just think it's important to show the diff in a relevant context [22:22] otherwise, changing parents would be confusing [22:22] and besides, it doesn't harm; the extra tab takes up minimal space [22:22] the diff is only loaded when the page has focus [22:23] i think we should include it in a release -- if it gets a bad reception, we'll take it out again. [22:38] re [22:39] schierbeck: how would showing the diff below not be in the relevant context? [22:39] schierbeck: I think metadata and contents are conceptually different and should be displayed in a different area [22:39] it would, but i just don't see how adding another main widget to the window will help [22:39] that also makes it possible to view the revision metadata and contets at the same time [22:39] jelmer: i don't think our users think about it that way [22:40] i just don't see the need [22:40] and if we needed to display both metadata *and* content, we *would* run in to size problems [22:42] schierbeck: I doubt that, see giggle's layout for example [22:43] jelmer: i hate giggle's layout :) [22:43] way too crowded [22:43] we should only display the absolutely necessary to the user [22:43] Well, giggle has more than this [22:43] yup [22:43] too much more [22:43] schierbeck: Just putting everything in tabs is confusing as well imho [22:44] it's incremental complexity; the user chooses to see more [22:45] We could make the widget with the diff on the bottom of the screen detachable [22:45] so you get the same effect you have now [22:45] if you want to [22:46] i think that would introduce a *lot* of complexity -- think the detachable menus in the GIMP [22:46] it's just confusing [22:46] but if the users want it, sure [22:46] yes, a lot of detachable things is confusing, but a couple doesn't hurt [22:46] i think we should start out simple, and see how the user base reacts [22:46] if they want a detachable widget, we'll create one [22:47] but we need to start somewhere [22:47] ok, so let's leave that out of the picture for now then [22:47] ok [22:48] in any case, the diff bit could be hideable [22:48] yup [22:49] but i still think we should go for minimal intrusion [22:49] That's not an argument for using a tab though.. [22:50] we could just make the bottom widget hidden by default and add a button to enable showing it [22:50] well, it's the solution that adds the least complexity to the startup view [22:50] New bug: #186238 in bzr "TB when cloning an SVN trunk into repo in "subversion" format" [Undecided,New] https://launchpad.net/bugs/186238 [22:51] i'd like the advanced users to be able to have an inline diff view, but not to bother newbies [22:51] schierbeck: if we hide the widget by default but add a toggle button to allow showing it, that's equilly intrusive as a tab [22:52] jelmer: but when it's shown, it takes up much more vertical space [22:52] making it hard to see the contents [22:52] schierbeck: Yes, but you could resize it any way you want [22:52] perhaps we could add a toggle that switched between the two layouts [22:52] jelmer: still, treeview + revisionsview + diffview [22:53] "Show changes beneath revision info" [22:53] if it's on, the tab disappears, and the diff view is shown at the bottom [22:53] ? [22:54] compromise? [22:55] schierbeck: Having more than one way to show it in this case doesn't make sense imho [22:56] we'll, then we're in disagreement :) [22:56] i like the tab approach the best, you the separate widget approach [22:56] we really could use some more opinions [22:57] Conceptually the contents just aren't part of the metadata nor do they have the same size constraints [22:57] jelmer: i really don't think that's going to be an issue [22:58] in the context of the viz, it won't matter at all [22:58] and we can just disable it anywhere else [23:00] fullmermd: ping [23:00] My plan is to clone an SVN trunk as a local Bazaar branch. This works, however, I cannot use it within a Bazaar repo. Moreover, I cannot setup a Bazaar repo and clone a secondary branch of that SVN branch into this repo. So, is it completely impossible to use shared repositories if subversion is involved? [23:00] bronger: what error do you get? [23:00] It complains that the formats don't fit together. [23:01] bronger: see the FAQ, use bzr init-repo --rich-root-pack [23:01] bzr: ERROR: Repository KnitPackRepository('file:///home/bronger/src/bobcat/.bzr/repository/') is not compatible with repository SvnRepository('https://svn.origo.ethz.ch/bobcat') [23:01] -- OR -- [23:01] bzr: ERROR: Repository KnitPackRepository('file:///home/bronger/src/bobcat/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bronger/src/bobcat-svn-mirror/.bzr/repository/') [23:01] Depending on what I do exactly. [23:03] schierbeck: There's no reason for the other tabs to be that large though [23:03] schierbeck: and it doesn't allow the metadata to be visible at the same time as the contents [23:04] jelmer: i don't think we really need to show the metadata at the same time, and having the widgets next to each other will take up an unreasonable amount of space [23:04] i just don't think it'll fit [23:05] * jelmer tries [23:06] * schierbeck waits :) [23:09] jelmer: let's pick it up again tomorrow, i have to go [23:09] see ya! [23:30] New bug: #127945 in bzr-svn "Integrate creating new branch functionality into standard push/branch" [Low,Triaged] https://launchpad.net/bugs/127945