=== poolie changed the topic of #bzr to: Bazaar version control system | please test 1.18rc1 | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ [07:26] morning [07:26] considering there is 1.18rc1 does it mean next bzr release won't be 2.0? [07:36] gour, it means the one on monday will be 1.18 but we'll shortly follow with 2.0b1 or rc1 [07:36] see the recent 'metronome' mail [07:36] poolie: ohh, thanks [07:36] np [07:56] * gour is waiting for bzr-2 to see if it could work nicely with bzr-fastimport & darcs repos using LP [08:07] gour: there's no need to wait [08:07] gour: just set the repo format to 2a [08:07] 2.0's primary difference from the release before it will be to change the default format [08:09] lifeless: hmm, so, 2a is available in 1.17? [08:09] yes [08:09] and 1.16 [08:09] but its best to use as recent a release ass possible - we've been bugfixing like made [08:10] to be frank, constant change of repo-formats was the main reason why i went back to darcs :-/ [08:10] *mad* [08:10] ok. i've 1.17 on arch [08:10] gour: we hope 2a to be the last word for quite some time :) [08:10] * gour hopes as well...the old creation of new formats was, imho, disaster [08:11] emacs is going to switch soon? [08:22] gour: the thing that caused actual problems AFAICT was rich roots more than anything else; and thats addressed by 2a - everyone has to upgrade to rich roots when they move to 2a [08:22] poolie1: did the talk go well? [08:23] hasn't happened yet [08:23] it's in about an hour [08:23] hugh's was good [08:23] most of it is in mandarin; aside from that it's a lot like an early lca [08:24] lifeless: i could agree...still, introducing so many formats was, imho, bad PR [08:25] lifeless: what about LP? works with 2a? [08:25] yes [09:16] lifeless: still here? staging seems to be down btw [09:16] not necessarily an emergency [16:05] Can bazaar create patch files? [16:22] Colonel-Rosa: bzr bundle or bzr send [17:44] hi garyvdm [17:44] Hi [17:44] I've finished rework of commit data save/restore [17:46] Cool [17:46] I'd like someone (you or vila) will review it [17:49] ok [17:52] bialix, uh, if garyvdm has to review something that will take years :p [17:52] * pygi hides [17:52] * pygi waves [17:52] * garyvdm waves [17:52] pygi: this is no problem [17:52] bbl - dinner [17:52] garyvdm, bon appetit :) [17:52] bialix, it was a joke :) [17:53] you are joking about gary all the time [17:53] ok ok, I'll stop :) [17:53] * pygi stops [17:53] this looks suspicious [17:53] why? [17:53] never mind, it was joke [17:54] xD [17:54] I forget adding smilie [17:54] * pygi needs to stop joking with people [17:54] but this is just my observation [17:54] never mind [18:07] re [18:44] i guess im blind, but whats a good way to get all files added on a fresh commit (with no parents)? [18:44] for all the other cases i can mostly use revisiontree.changes_from(other_revisiontree) [18:54] hmm, i can just use list_files [18:57] D'oh. I wonder YTF a branch-specific config value would be masked by a generic default from ~/.bazaar/locations.conf . [18:57] Seems backward to me. [18:58] It looks like locations.conf is even overriding the value I passed on the command line. [19:17] ronny: I guess you can get changes_from against a NULL_REVISION revision tree [19:33] luks: works fine, thanks [19:33] \o/ the first diff support unittests for anyvc pass === vxnick is now known as vxnick-AFK [19:54] pygi: ping? [20:11] bialix: I took a look at commit_data. I'm happy to merge now (so that we get user testing from trunk users.) Feed back from Vincent is important, but we get get that later. [20:12] garyvdm: thanks. I'll merge it soon (maybe tomorrow). [20:13] when I worked on bugs.py I thought that we have to use too much private bzrlib config API (with leading underscore) [20:13] maybe we need to provide some patches for bzrlib/config.py, but later [20:14] garyvdm: about find_branches/iter_branches: I'd prefer to have new method iter_branches [20:14] Yes - I think lets merge it, and then you can continue to work on improving it in those regards. [20:14] in this case backward compatibility will be easier for us [20:15] * bialix nods [20:17] I'm working on Bug 412029 and then Bug 412035. Still not sure how I'm going to do the later. [20:17] Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029 [20:17] Launchpad bug 412035 in qbzr "qlog: Add ui to select parent to diff with." [Medium,Confirmed] https://launchpad.net/bugs/412035 [20:17] But it is so important. That bug so often forces me to the command line [20:19] bug 412029? [20:19] Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029 [20:19] ah yes [20:20] it's nasty bug [20:20] garyvdm: about 412035 [20:21] we have context menu for invoking diff, right? [20:21] why not force user to select parent here [20:21] Yes, but also a button, and the file list. [20:21] we can force users to select parent all the time [20:21] I hope I can find a way for all 3. [20:22] it could be nagging [20:22] and people start crying [20:23] so we either should provide more options in context menu (as you did to select between different diff tools) [20:23] or use special dialog [20:24] garyvdm: what about creating short-cut diff option: default diff tool, left-hand parent always [20:24] and rich diff option: with all possible options to select [20:24] something like Advanced search in LP bugs UI [20:24] garyvdm: ? [20:24] Yes - a combo box would provide that to. [20:25] (default to left hand parent) [20:25] no, I mean special dialog [20:25] Oh - ok [20:25] how often you need special options? [20:26] so with short-cut people will have old behavior [20:26] and with new rich options dialog they will have to select and run diff [20:26] What I'm really looking for is a way to select the parent, when selecting the revison(s) in the list. [20:26] in 2 steps: dialog with options -> OK -> launch diff [20:27] You can show short summary info about parent revisions? [20:27] e.g. revno + author + summary [20:27] something like bzr log --line [20:27] put this into combobox [20:28] radiobuttons could be unoptimal for octopus merge case [20:31] I'm going to do bug 412029 first - Because I think that that might affect my ideas... [20:31] Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029 [20:32] ok [20:32] I'm planning to work on Bug #392920 because it beats me on win32 quite regularly [20:32] Launchpad bug 392920 in qbzr "can't commit if message has backslashes" [High,In progress] https://launchpad.net/bugs/392920 [20:33] garyvdm: after this I think working on auto screenshots and docs + site [20:35] * bialix mutters: maybe auto screenshots could be used as semi automated tests later [20:35] bialix: I was thinking the same thing... [20:36] garyvdm: I hope to use qbzr trunk history for generating screenshots [20:36] wow! [20:36] just need to figure out better places/revisions [20:36] and maybe your help for programmatically manipulate with twisties in qlog [20:40] garyvdm: I'm done for tonight. Good night and easy hacking! [20:45] "An attempt to access a url outside the server jail was made" ... just upgraded the bzr and bzrtools on a host that was serving through apache httpd, and now get this from clients. can anyone help? (1.10 -> 1.17) [20:45] kenichi, are both client and server 1.17? [20:45] yes [20:46] garyvdm, pong? [20:51] beuno: anything else? [20:53] garyvdm, once you're around, tell me what you needed :) [21:17] Hi pygi: I think that you were work together with vila on the bzr-gtk, save and restore commit messages. [21:18] garyvdm, I'm not sure, but I don't think so? [21:18] bialix has been working on and improved version for qbzr. I know that vila is interested in making some of the code common, so I though that you would like to take a look at what bialix has done. [21:19] see: https://code.launchpad.net/~qbzr-dev/qbzr/commit_data/+merge/10040 [21:22] vila, were we working on that? I don't think so. Perhaps Szi? [21:25] moin [23:43] morning === igc1 is now known as igc