[00:01] morning all [00:01] hi garyvdm, jml [00:01] Hi igc [00:01] igc: g'day [00:02] nightly ppa is broken for bzrtools again [00:02] bzr claims 1.17dev [00:02] but package says 1.15ish [00:02] and bzrtools from the ppa doesn't like 1.17 yet [00:03] thumper: yeah, I was going to ping you about that. [00:04] jml: why ping me? I don't do anything with the ppa [00:04] thumper: just in reference to our earlier conversation, is all. [00:04] istr it's either statik or james_w who maintains the ppa. [00:04] I think it is james_w given the uploader :) [00:05] aye [00:05] james_w: is bzr.dev packaged as 1.16 or 1.17... ? [00:06] bzr.dev is packaged as 1.15+ currently [00:06] which is an oversight [00:08] man, those tooltips on the branch listings are pretty irritating === afk is now known as mthaddon [00:09] jml: so, when do you want to get together for EP stuff? [00:09] jml: any afternoon this week would be good for me [00:30] lifeless: tomorrow is best for me. [00:30] lifeless: what time is good? [00:31] lifeless: also, wrt preserving NEWS headings -- I'm not 100% clear on what you mean. [00:31] lifeless: when I get clear, I'll be happy to patch the releasing guide. [00:32] jml: there are a number of headings like INTERNAL [00:32] they should exist, with no entries, under IN DEVELOPMENT [00:33] ahh ok [00:33] jml: tomorrow is fine [00:33] say after lunch? 1ish? [00:33] so when adding the IN DEVELOPMENT section back in, when merging the release branch back, the RM should also add in the empty headings? [00:33] yes [00:33] cool. [00:34] otherwise devs add the randomly [00:34] and we get order changes and conflicts and spurious new section names [00:34] that's easy enough. [00:35] yup :) [00:35] lifeless: 1ish is good. [00:38] bbl [00:46] garyvdm: hi [00:47] Hi bialix [00:47] You are up early/late [00:47] I have a question about Diff button in qlog when there is ext diff configured [00:47] ok [00:47] late [00:48] Same :-) [00:48] in Windows I see small button with triangle on it [00:48] how you created it? [00:49] Call button.setMenu [00:49] see lib/diff.py line 118 [00:49] that's all? [00:49] Yes [00:50] yeah, I found this code [00:50] and it's the same on Linux? [00:50] Yes :-) [00:50] nice [00:50] I'm tinking about improving our Browse... button for selecting branch or merge directive [00:50] allthough - it is not a narrow button when using the gtk style :-( [00:51] I want to use the same approach [00:51] how bad it in gtk? [00:51] screenshot comming... [00:51] * bialix waiting [00:52] btw, what you think about adding simple support for gathering list of available branches on code page of project at lp? [00:53] I've played with urllib2 and I think we can grab lp:urls from code page [00:54] it use to look like this: http://garyvdm.googlepages.com/qlog.png [00:54] now it looks like : .... [00:55] busy uploading. [00:55] garyvdm: you might like to look at python-launchpadlib too [00:55] it's kind of poorly documented [00:55] there is no pastebin for images, is it? [00:56] but it lets you poke through basically the whole data model of launcphad [00:56] hello btw [00:56] hi poolie [00:56] bialix: imgur.com maybe [00:56] bialix: my internet is just bad... [00:56] crop just button from image [00:56] dash: i'll try that [00:56] to make image small [00:57] lifeless, spiv, all, i'm going to close my mail client soon... [00:57] http://imgur.com/HBbWZ [00:57] imgur is cool dash [00:57] so i'm looking for (a) moral support (b) pointers to anything you think i really must reply to [00:58] bialix: basically the button is too wide. [00:58] yep [00:59] maybe explicit width settings will help? [00:59] Yes - just have not really looked at it. [00:59] poolie: launchpadlib has too much dependencies [01:00] simplejson, wadllib, httplib2? [01:00] +lazr.ui + oath [01:00] poolie: +1 :) [01:01] + don't know what elase [01:01] jml, could you run "bzr info http://bazaar.launchpad.net/~mbp/bzr/doc/" [01:01] bialix: I've been think about qmain a bit, bit have been coding the tree widget refactoring mostly. I've made some good progress tonight. [01:01] poolie: uhm, nothing offhand that is critical [01:01] i get a weird message about redirection [01:01] garyvdm: I'm using Ian's bzr explorer, it' nice [01:01] me too [01:02] poolie: same, nothing I can think of needing your attention now. [01:02] garyvdm: will be nice to have there your tree widget though [01:02] garyvdm: why it has segfaulted? [01:03] In parent() i was returning a valid index for the root - it should be an invalid index. [01:03] poolie: perhaps try --no-plugins? ISTR a bug report about weird redirections that turned out to be due to bzr-svn [01:03] ah, ok [01:04] garyvdm: I hope you will place folders at top, as in qbrowse [01:04] garyvdm: this is most often used sort order for explorer-like tools [01:05] Yes - and later be-able to control that by being able to click on the headings [01:05] as you wish [01:06] we need to show unknown/ignored there too, do we? [01:06] Low priority at the moment. [01:06] Yes [01:06] If you are browsing a working tree. [01:06] and maybe have ability to filter items by status all/versioned/modified/unknown/ignored [01:07] yes - one widget to do all of that [01:07] I've got my work cut out :-) [01:07] cool [01:07] QSortFilterProxyModel will be my friend for that. [01:08] ah [01:08] nice [01:08] With special performances cases for workingtree unknown/ignored I assume. [01:08] garyvdm: I've made attempt to look into QtTest lib (for testing Qt GUI). [01:09] it's rather limited [01:09] I don't think we need a silver bullet for test. [01:09] re test: may be it makes sense to think how to separate GUI and logic/model [01:10] so we can test logic/model easily [01:10] QtTest is not even a bullet, IMO [01:10] Yes thats way I started on tests for LogGraphProvider. [01:11] poolie: http://paste.ubuntu.com/196702/ [01:11] IIRC, there was desire to move it into bzrlib core? [01:12] Yes [01:13] It would be nice for bzr-gtk to reuse LogGraphProvider, but It would require alot of effort. [01:14] Maybe I'll do it .... [01:14] ... when I run out of things to do on qbzr [01:14] ha ha [01:18] garyvdm: can you add this at line 117 in diff.py: self.menu_button.setFixedWidth(24) [01:19] and check if in gtk style it's better now? [01:19] width could be ~20 [01:20] Yes - it does look better [01:20] but we need to make the width dynamic [01:20] Maybe guess it as 1/2 the height? [01:21] or maybe play wit Size Policy [01:21] with [01:21] ok [01:21] 1/2 is ok for me [01:23] it seems I need to get some sleep. [01:24] * bialix ~ [01:28] Hi [01:29] Howdie. [01:29] I think no, but just to be sure, does bzr have something like "git branch"/"git checkout" (ie, several branches in the same directory)? [01:29] RainCT: No. There's some work-in-progress stuff. Co-located branches or something. [01:30] And like "git format-patch" neither, right? [01:31] bzr send [01:31] hey RainCT [01:31] And looms can work for some of the use-cases of multiple branches in the same directory. [01:32] jelmer: hey :) [01:32] as can a shared treeless repo [01:32] hi jelmer [01:32] jelmer: does tdb allow repeated keys? [01:33] lifeless: hi [01:33] Shared, treeless repo + checkout working tree is about it, just a bit more fiddly :) [01:33] lifeless: nope [01:38] Hello === Kissaki is now known as Kissaki^0ff [01:55] How can I disable interactive login via ssh while allowing bzr commands through bzr+ssh? [01:59] man 5 authorized_keys documents it [01:59] under the AUTHORIZED_KEYS FILE FORMAT heading [02:03] lifeless: Sorry, I believe I asked my question poorly. I shouldn't have said interactive - I didn't mean password-based login. I meant disabling any login that will spawn a shell. Launchpad seems to do something similar - if I try to ssh, it kicks me out with "No login shells.", but I can still run bzr+ssh commands. [02:04] I'm trying to mirror that behavior on my own system. [02:04] sensae: I answered what you intended to ask [02:04] I wasn't talking about password vs non-password [02:09] Ah, I see it further down. Thanks. [02:19] Is it possible to change a commit author on a commit? [02:19] no; you can uncommit it and commit it again with a diferent author. [02:20] Oh my [02:20] umm, i just moved my branch from a linux box to a windows box, using cygwin, and i can't get diff to work [02:21] everything else seems to work, except the diffs [02:22] krisfremen: does bzr status work? [02:23] yes [02:24] what does diff seem to be doing wrong? [02:24] it doesn't print anything [02:24] bzr just exits and doesn't print anything at all [02:25] is there anything in the bzr.log [02:25] you can get the path for that from 'bzr --version' [02:26] 1.666 return code 0 [02:27] it thinks there are no differences [02:28] http://pastebin.com/d69f6f59c [02:28] but i just made a commit [02:28] well it wouldn't expect any changes after a commit [02:38] lifeless: Do you know what option would give me the desired effect? [02:39] sensae: command=bzr serve --allow-writes [02:39] sensae: or something like that [02:39] I don't remember the exact command line [02:40] thanks for the tip spiv, you're probably right [02:53] yes, you were right [02:53] i think it's fixed in a later release of bzr-svn [02:54] lifeless: At this point, I'm stumped. Googling found "command="bzr serve --allow-writes --inet --directory=/"", and I'm having no luck. [02:59] sensae: bzr asks ssh to run "bzr serve --inet --directory=/ --allow-writes", FWIW. [03:00] sensae: see also contrib/bzr_ssh_path_limiter in the bzr source tree [03:00] spiv: No dice with that either. I've tried a lot of different commands, I'm just getting "Please check connectivity and permissions" [03:01] Alright, I'll take a look [03:01] sensae: maybe you need to specify command="/usr/bin/bzr ...", or something like that? [03:02] sensae: $PATH might not be set how you expect at that point, because no .bashrc or whatever would have been run. [03:03] spiv: No luck with that either :/ [03:03] where is bzr installed on your system? [03:03] (on the remote system you are trying to configure) [03:03] spiv: .bashrc should be run, actually. That's a common vulnerability. [03:03] spiv: /usr/bin/bzr , I verified with a whereis [03:03] wgrant: oh really? wacky! [03:03] sensae: *nod* [03:04] spiv: Yep - it runs the command in a shell. [03:05] spiv: Hm. This path limiter seems useful anyway, guess I'll try using it and see where it gets me. [03:09] spiv: ..and it got me nowhere. [03:12] sensae: yeah, I'd expect it to have the same issue you were already having, although I don't know what that could be. [03:12] lifeless: why is bug 387555 a bug? [03:12] Launchpad bug 387555 in bzr "aliases can override main command names now" [Critical,Triaged] https://launchpad.net/bugs/387555 [03:13] sensae: perhaps check ~/.bzr.log on the remote side, and also try "ssh -vvv user@host" directly. [03:14] poolie: I'm not entirely convinced that it is. However Aaron reported the change in behaviour, and I'll comment further once I look at it. [03:14] poolie: if it *is* a bug it will bit people badly in the next release unfixed, by making 'bzr shelve' run the wrong shelve. [03:14] poolie: that bug doesn't mean by 'alias' what i first thought when i read the summary [03:15] Updating branch... Launchpad is processing new changes to this branch and will be available in a few minutes. Reload to see the changes. [03:15] spiv: Hm, log doesn't exist for the user I'm trying this as [03:15] Very cool! [03:16] sensae: ok, so bzr almost certainly isn't getting run. [03:19] sensae: maybe try using a really simple command, like 'command="/bin/echo hello" ssh-rss ...' as a sanity check? [03:20] beuno, rockstar, Peng_: have any of you looked at https://code.edge.launchpad.net/~zigarn/loggerhead/nested-branches/+merge/7307 ? [03:20] mwhudson, nope, I hadn't. [03:20] i don't think i want to merge it [03:21] but i guess i should think of some reasons other than a gut feeling [03:21] lifeless: the guide for upgrading to 2a seems reasonable [03:21] you could run it past some lp people too... [03:22] spiv: Debug messages say "forcing command: /bin/echo hello" but without the debug flags, I get nothing. [03:24] mwhudson: I haven't. It sounded complex, so I didn't even try. :D [03:24] thumper: jml: mwhudson: any comments on my draft for upgrading repositories across the rich root barrier? [03:25] Hey, look over there! *points* [03:25] * Peng_ sticks bug #382765 on someone's back. [03:25] Launchpad bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] https://launchpad.net/bugs/382765 [03:27] sensae: weird. [03:27] lifeless: I have been meaning to look at it for 1.5 days now, but have not had the opportunity. [03:28] spiv: Fixed it, and I feel pretty stupid now. My test user's shell was set to /bin/false in /etc/passwd :/ Works as expected now. [03:28] sensae: ah! [03:28] sensae: glad it's working for you [03:28] spiv: Thanks for all the help, I think without it I would have given up. [03:35] sensae: not a problem :) [03:40] Do tags always tag the whole branch or is it possible to tag sub-directories or single files? [03:40] tags tag commits [03:40] so 'whole thing' [03:40] oh, then so [03:40] then no [03:40] I have a problem [03:42] myutils = Branch(); myutils.add(one_util_v1.2); myutils.add(another_util_v5.9) [03:42] RenatoSilva: This is part of why we suggested that you use separate branches. [03:42] I'd have to tag myutils, but I would like to tag each file [03:43] wgrant: I see [03:43] wgrant: but I'll need to set up one dir for each file right? [03:43] RenatoSilva: Yes. [03:43] can the same .bzr dir store multiple branches? [03:44] That's complicated. [03:45] yeah, the whole issue is [03:45] Now I just have to figure out why bzr is crashing on a push. x.x [03:47] wgrant: I think that cvs allows to tag any tree [03:47] RenatoSilva: Launchpad only stores single branches. [03:47] RenatoSilva: bzr|hg|git != CVS [03:47] RenatoSilva: Yes, but CVS is veeeeery different from Bazaar. [03:47] RenatoSilva: few patterns that work well in CVS work well in any of the modern version control systems. [03:48] wgrant: it would be nice maybe if we could have 'contextual' tags, they would not tag full commits but commits on a target sub-dir or file [03:49] RenatoSilva: Why? [03:49] Is there any way with bzr-git to push to/pull from a non-master branch? [03:49] RAOF: not yet, no [03:50] RAOF: i think you can git-import which will get you a repo containing all branches [03:50] RenatoSilva: are you tagging releases? [03:50] mwhudson: But you can't push to a non-master branch. OK. [03:50] RAOF: afaik [03:51] wgrant: so that I create myutils and global tags like Release_1.0, Release_1.1 etc... but could also have independent release tags with the 'contextual' tags: myutils/util_one --> Release_5.6, etc... [03:52] RenatoSilva: again, it sounds like you want to treat these files as separate things [03:52] RenatoSilva: You're not meant to colocate lots of separate pieces of software in one branch. [03:52] RenatoSilva: separate things should be in separate branches if you want to put metadata like that [03:52] It's not like Subversion, where you throw hundreds and hundreds of projects into one repository. [03:53] lifeless: the contextual tags would be just for reference / browsing, to track the history of a subdir or file [03:53] lifeless: If I separate the things, I would need one directory for each file [03:53] to create a branch [03:53] RenatoSilva: I must admit I don't really see the benefit of tagging only part of a tree [03:54] wgrant: I tried bzr-svn branching a small project out of Apache's Subversion repo... only to discover they had >700,000 revisions there. I decided not to wait :| [03:54] AfC: Yep... Zope does it too. [03:54] AfC: svn.apache.org really hate launchpad :) [03:54] mwhudson: I bet [03:54] at one point all of canonical's ip addresses were banned even [03:55] mwhudson: last year when I was trying to get gtk+ out of svn.gnome.org, it took ~30 minutes to get 100 revisions. Subversion performs *horribly* when asked for historical editions of files. [03:55] Apache really is in its own little world [03:59] lifeless: let's say you have a myutils branch, with tags R10, R11 R12 and you have the specific_abc_utility wich has it's own versioning like 9.04, 9.10 etc. If you could do something like $bzr tag R9.04 -d abc_utility.py, then you could later take a look at that particular revision of that file, using something like $bzr tags -d abc_utility.py. [03:59] RenatoSilva: You don't have that sort of branch, though. [04:00] RenatoSilva: yes; OTOH you will have a horribly confusing set of tags [04:01] or you'll have to run commands to query 'all tags' specfically [04:01] it's like eclipse, galileo is eclipse 3.5, this is the main line of versioning, but every sub-project has its own different versioning [04:01] we put sub projects into different branches [04:01] it makes it clear [04:02] not that I'd hold eclipse up as a paragon of clarity for its module and versioning system [04:03] lifeless: not confusing maybe, they could be separate tags, contextual tags, they would appear only if you ask to, like $bzr tags --include-contextual or so [04:03] That is confusing... [04:03] that is itself confusing [04:03] :) [04:04] it would continue to work the same way, only people who noticed such issue would be interested about it... [04:05] Assuming that you weren't terrified of having an extra directory segment, what is the benefit? [04:06] RenatoSilva: it would have significant knockon effects: firstly when saying to a user 'get version X' the user would need to know that there are invisible tags they need to supply a magic path to see. [04:06] secondly, the data storage model would be made more complex. We'd have to write code to support it in the CLI, web UI, gtk/qt interfaces and more. [04:07] What I'm saying is that there is a signficant, measurable cost in doing what you propose. [04:07] So we should get a greater benefit by doing it than it costs, or it is likely not worth doing. [04:07] (we) is the users+developers of bzr combined. [04:09] lifeless: I don't get your 1st point [04:09] at the moment, if I say, version 10.6, there are two ways, and only two, to get it. A branch called 10.6, or a tag in trunk called 10.6 [04:09] your proposal adds a third way [04:10] a tag in trunk that 'bzr tags' *does not list* called 10.6 [04:10] it should not list if it's not a branch tag (a contextual tag) [04:11] when you do bzr tags, you're doing it under the branch [04:11] the point is about the cognitive overhead of learning yet another way to categorise things [04:11] only if you ask so, it would operate under a subset [04:11] now, I'll agree that we may have gone too far with whole-tree versioning; I've made that argument myself from time to time. [04:12] but we need to accurately measure and assess the costs of thingslike this, not just assert that they are worth doing. [04:12] lifeless: you mean each dir could be a branch? [04:13] with the nested trees feature that is being finished at the moment, yes they can be [04:13] just like cvs modules [04:13] not at all. Like a small subset of cvs modules perhaps. [04:14] cvs modules are actually far more complex than most users think they are. [04:14] [complex and problematic] [04:15] if you have a cvs repo in front of you, a big tree, and you wonder: "well where are the modules/branches/projects"? The answer is: your project can be anything you want, because each dir is a cvs module (ok, there's no atomic commit but I guess svn works this way) [04:15] svn works differently again [04:16] wouldn't branch inside branches be a complicated stuff? more than the sub-tags? [04:16] it is complicated but it has very significant benefits [04:16] it lets you do things you can't do without [04:17] it would let you have sub-tags right? [04:17] not unless you split your project up into nested projects [04:18] I wonder how git adresses all this [04:18] and hg [04:18] RenatoSilva: You might find that 3rd generation distributed revision control has different ("best") practises than perhaps you are used to. You might just want to give things a try the way they work well in [in this case, Bazaar] and see how you get on. [04:18] git and hg do exactly what bzr does [04:19] AfC: in my example it means one dir for each single file [04:19] Because they are also 3rd generation distributed version control systems :) [04:19] there are some minor spelling differences, but at the level this discussion is at they are identical. [04:19] AfC: which is a bit annoying [04:19] RenatoSilva: {shrug} ... whether one file or one hundred, if the branches have separate identities, so be it. [04:20] RenatoSilva: so you have a choice. You can either: use CVS. Use one branch per file. Tag releases for all files at once. [04:20] calm donw guys [04:20] I'm jsut talking about it [04:21] RenatoSilva: there is an inconsistency in what you are asking: you're saying you have files that are sufficiently well managed that they get individual releases, but you aren't willing to pay the [tiny] cost of having a separate branch to achieve that management. [04:23] lifeless: because they's just single files, it could be together in one single dir, I think it's annoying one dir + .zr for just one file, repeated several times. Just my opinion. As you said the choice is mine. I'm just trying to know how it works [04:25] lifeless: incidentally, I would value your comment or contribution on the email thread on bazaar-list titled "I pulled HOW much?". I suspect I have observed a similar behaviour, and am curious if indeed there is a quick "fix" (sic). [04:25] AfC: The second reply *did* say there's a patch up. [04:25] AfC: (And it works, too.) [04:25] Peng_: yes. No kidding. [04:26] Peng_: but as John went to quite some trouble to suggest that perhaps his implementation needed consideration, I thought I would see if Robert had anything to say on the topic. [04:26] AfC: Okie dokie. [04:26] (!) how about if I apply a tag like Utility_ABC_Release_10 in the branch? [04:26] (Okey dokey? I dunno.) [04:29] AfC: I'll have a look [04:30] RenatoSilva: if that works for you, great. [04:30] Urgh, anybody have a solution for making bazaar create files with a group permission of 7, without using umask on every dev account? :/ [04:30] Peng_: it's one of those things you hear spoken (by American presidents and other illiterate peasants). I don't think you'd ever see it written down, except maybe in a movie script. [04:30] sensae: you can set it in /etc/ssh/rc I think [04:30] sensae: or something like that [04:30] AfC: I believe the branch jam linked to fixes it; I'm actually reviewing that code atm. [04:31] AfC: (I spent some time at UDS discussing and pairing on that issue with jam) [04:31] lifeless: real example: http://bazaar.launchpad.net/~renatosilva/+junk/utilities.ruby/files [04:31] the branch itself is not versioned, but some files inside it [04:32] currently it's revision 1, but take a look at: [04:32] RenatoSilva: branches can't be versioned in bzr. [04:33] http://bazaar.launchpad.net/~renatosilva/%2Bjunk/utilities.ruby/annotate/head%3A/trf.rb [04:33] inside the file it stands it's the version 2009.4.22, the same way for the other files [04:35] so my idea is to $bzr tag trf_2009.4.22 and $bzr tag ganyclean_2009.2.28 [04:35] RenatoSilva: if you want to manage that file as its own independent entity, make a separate branch for just that file. Really :) [04:35] I think it would replace the sub-tags nicely [04:36] RenatoSilva: you can do that. can I ask.. what do you want the tags for anyway? [04:36] RenatoSilva: I'm not sure why that wouldn't work well for you? [04:36] spiv: cognitive overhead I think. [04:36] lifeless: to find previous _release_ versions of the files [04:36] RenatoSilva: 'bzr log filename' can report on that for you. [04:37] I just realized I accidentally disabled all plugins in Loggerhead. Maybe that's why it stopped leaking memory. [04:37] (or, well, gaining memory at least.) [04:37] RenatoSilva: if when you are doing a release you say 'release 2009.2.28' in your commit message for the file. [04:37] lifeless: I mean _release_ tags, not raw revisions [04:38] RenatoSilva: yes, I know what you mean. But for individual files it seems like they *have* to change when you do a per file release. [04:38] so I don't see why tags are preferrable. [04:38] lifeless: oh I see, put that in the commit comment is another option, altough I don't know which one is better [04:38] the way people generally manage releases with bzr is to run 'bzr branch trunk RELEASE-X' [04:40] I think search in the tags could be easier than searching in the comments [04:40] the comments would better explain the changes, I think tag is better for tagging such commit as "this is release x or y" [04:40] RenatoSilva: 'bzr log -m release FILENAME' [04:41] lifeless: ok [04:41] I have to read more on bzr (more than those 5 minutes :) ) [04:41] * spiv -> lunch [04:42] but I'm pretty happy because I can do the basics and I will solve a problem at work [04:44] I have a project at work versioned with CVS, but I change it at home too (and can't commit to work). I will solve this by using bzr... [04:45] good luck, I hope it works smoothly for that [04:45] lifeless: I need a little more push in the right direction than just what file :p How would I go about it? [04:46] thank you guys for helping [04:46] as per man 5 authorized_keys: [04:46] If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; o... [04:47] so you can put commands to set umask etc in those scripts [04:47] So you'd recommend setting the umask for devs as a fix? [04:48] that + sticky bit is the easiest way to ensure consistent permissions in a unix server [04:49] lifeless: Alright, thanks. That's what I was looking for - an opinion of the best way to go about it :) [04:53] why would I want QBzrEclipse rather than the non-Q? [04:54] What does Qt has with Eclipse? It has its own gui in SWT, I couldn't understand really [04:54] RenatoSilva: The bzr-eclipse plugin uses SWT for its interface whereas this plugin uses the QBzr plug-in. This does mean that the interface may not have the same look and feel as Eclipse does. The advantage of this approach though is that you get a consistent graphical user interface to Bazaar whether you are using the command line, TortoiseBzr or Eclipse. The QBzr plugin also provides a very nice interface for Bazaar. [05:00] spiv: nice. [05:00] spiv: [I hope you guys can land that before 1.16] [05:00] I I write an utility for eclipse, would it be suitable to link the branch with eclipse project? [05:01] Or should the branches be direct work on the project, patch proposals? [05:13] RenatoSilva: It wouldn't be suitable to have on the eclipse project. [05:13]