correctly when scrolling [12:30] luks - yes - if we want the background across the whole line [12:30] jelmer: what is this 1000000 magic factor in the subvertpy timestamp functions about? [12:31] luks: No - it does not have that abiliy afaik [12:32] is not div element should be resized on full width of window? [12:32] then it can draw background on full width [12:32] not in QTextBrowse [12:32] bad [12:32] * bialix bbl [12:32] bialix: On thing that we currently do in qdiff is run the whole file through pygments. You could may be experiment with passing only the part of the file we diapaly through pygments [12:33] *display [12:33] I need to collect speed statistics first [12:34] btw, I like how WinMerge shows the diff [12:34] there is always full file [12:34] and deletion on each side shown as holes [12:34] I'm not sure if pygments can do that [12:34] I'd like to accomodate this for qdiff [12:35] higlighting parts of a file is a more complex problem === cprov-afk is now known as cprov [12:37] ronny: hi [12:37] ronny: you can't change the commit date during a commit [12:37] ronny: the only way you can change the commit time is by changing the revision property afterwards [12:38] (which requires the commit hooks to be adjusted to allow that) [12:38] oh darn [12:39] jelmer: btw, why that magic timestamp factor? [12:39] yes [12:39] ronny: magic timestamp facto? [12:40] luks/bialix: When I get around to it, I want to create "qdiffmerge" which will allow 3-way diff, editing, and (this is why I want to write it, not just use meld) the ability to annotate in that window. [12:40] It's a big job, so I keep on putting it off :-~ [12:40] jelmer: the 1000000 you use in time_from/to_ctime [12:45] jelmer: how do i get the revno a commit created [12:45] meh, svn is fail :( [12:48] jelmer: i'll print a warning instead of setting a svn date for now [12:49] ->lunch, bbl [13:02] ronny: there's a callback used by commit that will be called with the result author, date and revno [13:04] ronny: the 10^6 stuff is used because that seems the times are usually usecs in the svn world === mrevell-lunch is now known as mrevell [13:23] hi vila? [13:24] poolie1: hey ! [13:40] jelmer: how can i use that calback stuff when using a ra editor === james_w` is now known as james_w === kiko-fud is now known as kiko === Edwin is now known as Guest70933 [14:33] --help [14:35] Bazaar -- a free distributed version-control tool [14:35] http://bazaar-vcs.org/ [14:35] Basic commands: [14:35] bzr init makes this directory a versioned branch [14:35] ...... === sabdfl1 is now known as sabdfl === Guest70933 is now known as EdwinGrubbs [15:56] ronny: you can specify a callback to get_commit_editor() [15:56] I think it's called "done" or something in the docstring [16:18] its called callback [16:48] * SamB wonders why it is *repository formats* that are considered rich-root or not, rather than branches/revisions [16:56] spiv: so, 1.18 *is* going to have this Repository.insert_stream_1.18 hpss method, yes? [17:00] SamB: it's repositories that store revisions, not breanches and not working trees [17:00] jelmer: yeah, I know [17:01] but don't only some of the revisions actually use rich-root at all? === ja1 is now known as jam [17:04] ping vila about kerguelen :) [17:05] jam: goood morning jam :) [17:06] so... you have to delete bzrlib/_chunks_to_lines.pyd before running setup.py, as it loads osutils.py which loads chunks_to_lines [17:07] evil! [17:07] SamB: evil-ish. Mostly that you can't delete an open file on Windows, which causes difficulties sometimes [17:08] jam: I meant having the C-ish module import a python module, actually ... [17:09] SamB: it doesn't [17:09] setup.py imports osutils.py imports chunks_to_lines.pyd [17:09] oh [17:10] just that setup.py also *rebuilds* chunks_to_lines.pyd [17:10] if it is considered out of date [17:10] but it always fails if it already exists... [17:10] I guess I didn't interpret "it" correctly === deryck is now known as deryck[lunch] [17:20] garyvdm: how it's going? [17:20] Hi bialix [17:20] hi garyvdm [17:20] hmmmm [17:20] Not on to release yet. [17:20] is there some blockers for you? [17:21] jam: hello [17:21] Fixing qdiff perferformance [17:21] Nearly done with that :-) [17:21] hi bialix [17:21] and garyvdm [17:21] jam: garyvdm working on qbzr release [17:21] bialix: I'm not on as strict timetable for 1.18rc1, so just let me know when you think you're ready [17:21] what's your plans on bzr installer? [17:22] Hi jam - when do you plan to do the wininstallers for 1.18rc? [17:22] :-) [17:22] all windows people looking at jam [17:22] jam - never mind. there was a irc delay [17:22] garyvdm, bialix: I plan to do them.... eventually :) [17:22] jam - I'll let you know when I've done the qbzr release. [17:23] Please will you wait for that before you do 1.18rc1 installers [17:23] if garyvdm will fall asleep I'll do it [17:24] bialix: I've got qdiff much faster - just some small bug to fix. [17:24] that's great! [17:24] bialix: Please can you try out the qannotate changes. [17:24] does they're already in trunk? I did not saw commit mail yet [17:25] garyvdm: do you remember what's problem with bzr-pipeline? Bug #395817 [17:25] Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatible." [Medium,New] https://launchpad.net/bugs/395817 [17:26] Yes - I know how I think we should fix that - will just take a while. [17:26] I'll explain in a sec [17:27] if you think we have to fix it on our side, then I'd mark bug as Confirmed [17:31] bialix: It probably involve changes in bzrlib, qbzr and bzr-pipeline [17:31] or just bzrlib, and qbzr [17:32] should we involve bzr into bug report then? [17:33] Not yet [17:34] ok, so won't touch it yet [17:34] so I won't === patrick is now known as Guest65098 [17:37] ~~~~~~~~/qIRCNICK patrickcd [17:39] bialix: re pipeline problem - I've got a 2 ideas on how to fix. Both are a lot of work :-( I have not decided which is best. [17:40] Idea 1: [17:41] Add --using to merge --preview [17:41] and [17:42] Add a way to hook qdiff into diff --using [17:42] which would be reused by merge --preview [17:42] so you could do merge --preview --using qdiff [17:42] Idea 2: === beuno is now known as beuno-lunch [17:44] Change bzrlib to some how allow for multiple plugins to change a command. [17:44] Not 100% certain how that can be done though. [17:45] bialix: so I have pushed my qdiff improvements if you want to try them out. [17:45] And I'm going to start updating news now. [17:45] idea #2 require discussion with core devs [17:45] Yes [17:45] perhaps Aaron or Martin should know better [17:45] Idea 3: monkey patching :) [17:46] luks: what's that? [17:46] modify cmd_merge instead of subclassing it [17:46] you can add an option and overwrite _do_preview [17:46] and now I should hide :) [17:46] why not? [17:47] does monkey patching taboo in #bzr? [17:47] luks: Yes - that way one of my ideas, but I'm not sure where one would do that? [17:47] bialix: I guess any bzr dev would complain [17:47] since it's misusing a private API [17:47] about monkey patching from qbzr plugin? [17:48] from any plugin [17:48] Which we are doing atm.... [17:48] recently there was added some hooks re command loading [17:48] garyvdm: in bzrlib.plugins.qbzr.__init__ [17:48] I wonder if they will be used here [17:48] but of course proper hooks in cmd_merge would be a better solution [17:49] luks: lazly? [17:49] garyvdm: you can overwrite the method by a trivial method that either calls something else or the original _do_preview [17:50] A pro of Idea 1 would get us away from interfacing a private method [17:50] the something else would be lazily loaded [17:50] luks - I see [17:50] not that I suggest using something like this long-term [17:50] but it would work until there are proper hooks in cmd_merge for --using [17:51] IIUC you mean registry of diff viewers [17:52] Yes - that is what I had in mind for idea 1 [17:52] it's could be complicated because PreviewTree is internal representation of merge results and has not actual mirror on the disk [17:53] bialix: It would be easy to write to disk. [17:53] However, for qdiff, it would not be written to disk. [17:53] just to throw it after? [17:54] bialix: well, that [17:54] 's what diff --using does [17:54] right [17:54] +1 then [17:54] bialix: have you tried qdiff yet? [17:55] so, we'd need to start supporting `bzr diff --using qbzr` first, I guess [17:55] yea [17:55] garyvdm: not yet [17:55] * bialix pulls [17:56] bialix, luks: I found that qdiff was spending more time in format_for_ttype than in pygmentstaking longer in [17:56] ^H^H^H^H^H^H^H^H^H^H^H [17:56] So I now cache that. [17:57] And I made the line/block drawing only draw what's on screen. [17:57] much faster now. [17:58] garyvdm: WOW [17:58] WOW WOW WOW [17:58] it flies now [17:58] :-) [17:58] you're wizard! [17:59] * bialix heads to home now, be back after ~ 1 hour === raimue is now known as Raim [18:05] hey. who do i complain to about bzr rspush deleting vital files which were part of .bzrignore? [18:13] beuno-lunch, I'm just headed out for lunch myself. But I've sent a summary to the mailing list for the wireframes. it would be great if you could take a peek and hopefully pass this along to one of your designers. === mrevell is now known as mrevell-dinner [18:34] jam: qannotate can now annotate the working tree - so now qannotate can do every that gannotate can do :-) [18:34] *everything === deryck[lunch] is now known as deryck [18:34] except for moving between revisions [18:34] luks: It can! [18:35] oh === EdwinGrubbs is now known as Edwin-lunch [18:35] cool [18:35] luks: right click on a revision, click on "Annotate this revision." [18:35] UI bug, it should not have a trailing period :) [18:36] * garyvdm fixes [18:36] emmajane, will do [18:38] * garyvdm -> dinner [18:40] * SamB wonders why bzr switches packs in mid-transfer [18:41] (why can't it just write to a temporary pack and then figure out where to really put the the revisions later?) [18:41] hm, I find myself running "bzr branch ../foo ../bar && bzr switch ../bar" too often. has anybody thought about adding a --switch option to branch before? [18:41] luks: bzr switch -b [18:42] oh? [18:42] the ../ is sorta implicit, too [18:42] in what version was that included? [18:42] so you would just do "bzr switch -b bar", if foo was what you had checked out [18:43] luks: 1.17, maybe? [18:43] I have 1.17 here and no switch -b [18:43] oh [18:43] well, whatever's in the PPA then [18:43] hm, but switch -b branches of the current branch, right? [18:44] I believe you could specify a second arg if you wanted to branch from something else [18:44] it's inspired by git checkout -b [18:45] oh, so apparently I have 1.17rc here [18:45] and it was added in 1.17 [18:45] weird that there was a new feature added after the rc [18:45] yeah [18:48] I must be blind [18:48] upgraded to 1.17, still don't see the option [18:49] oh? [18:49] not in builtins.py either [18:50] and not mentioned in NEWS [18:50] but the docs on bazaar-vcs.org mention it [18:50] strange [18:51] last entry in New Features in the tarball is "bzr send now aborts if ..." [18:51] maybe you're looking at the bzr.dev docs? === beuno-lunch is now known as beuno [18:51] I am, but under the 1.17 section [18:51] oh? [18:52] it was probably added on the wrong place in bzr.dev [18:53] * LarstiQ annotates [18:56] hm, right, to switch -b is not useful to me [18:56] I'm usually in a situation where I have a feature branch and I want to work on another feature [18:56] this way I'd have to switch to trunk, switch -b to the new branch [18:56] which is not not easier than branch && switch [18:56] luks: how about cbranch? [18:57] LarstiQ: doesn't that do something almost entirely different? [18:57] what does it do? the help text is confusing [18:57] SamB: something witt branches and checkouts? ;) [18:57] I don't want to create a new checkout [18:57] LarstiQ: but it makes a new checkout, doesn'ty it? [18:58] I want to use the same checkout, but create a new branch [18:58] SamB: ah hmm, you'd still need to switch, yeah ok, doesn't help [18:59] what do you think about adding "bzr switch -b [SOURCE] TO_LOCATION"? [19:00] would it be acceptable to add a new argument between the existing ones? [19:01] luks: should be the other way, I think [19:01] bzr switch -b to_location [source] [19:01] yeah, well, that would be compatible with older switch, but inconsitent with branch [19:01] bzr switch source -b to_location? [19:02] that's the same as -b source to_location [19:02] not if -b is an option [19:02] I believe the option parser ignores position of --options [19:02] oh, even more confusing :) [19:02] the idea is to mimic 'git checkout -b' [19:02] luks: one of us is confused about argument/option :) [19:03] argument is 'foo', option is '-f' or '--foo' [19:03] right? [19:03] luks: argument doesn't take an argument, option takes an argument [19:04] well, to_location is not -b's argument [19:04] d'oh [19:04] it apparantly should be? [19:05] probably not, because you need it even without -b [19:05] bzr switch to_location is the main use case [19:05] or maybe checkout is just supposed to treat it's args different depending on whether or not -b was passed [19:06] git indeed uses "checkout -b target source" [19:06] luks: well, I meant judging by git-checkout(1) [19:06] I'd prefer the argument ordering from branch [19:06] which is the same as for cp/mv [19:06] it would mess up our finger memory [19:07] well, I'll write the patch and let people on the bazaar ML judge it [19:07] and having optional arguments at the beginning is quite odd [19:08] it would depend on -b [19:08] "bzr switch foo bar" would raise an error [19:08] even so [19:08] or, "source" could be -b's argument [19:08] no, that's an incompatible change [19:09] or, darn, it's not in a release is it? [19:09] incompatible changes aren't outruled per se [19:09] well, anyways, it isn't terribly compatible with my fingers ... [19:09] and especially when not released :) [19:09] isn't it possible to have an option with has optional argument? [19:10] I'd want the '-b' short form removed if you're going to do things so different [19:10] so both "-b" and "-b source" are valid? [19:10] luks: no... [19:10] well, I hope not, anyway [19:11] oh well, I'll just write it the hacky way and let the patch to be rejected :) [19:11] hm, or I write a plugin [19:12] dunno how I missed that bzr switch -b bar foo [19:12] doesn't work yet [19:17] cool, it seems optparse explicitly supports optional arguments in the middle [19:18] I can have takes_args = ['source?', 'to_location'], def run(self, to_location, source=None) and it does the right thing [19:19] the wrong thing! [19:19] well, what you meant, sure ;-) [19:20] interesting :) [19:22] hm, or maybe not [19:24] does anybody know of a bzr command that take arguments in "target source" other? [19:25] export [19:27] luks: I think the order to use is "required [optional]", generally [19:28] SamB: I know, but I couldn't live with switch source target [19:29] it seems everything fails, so I'll write a sbranch plugin for myself [19:29] er, sorry, with source target source [19:29] luks: `bzr export` wasn't helpful? [19:29] (but you can see, it's hard to write the other way :)) [19:29] needs more source [19:29] LarstiQ: I always found it weird [19:29] * SamB pours on some worcestershire source [19:30] LarstiQ: I just wanted to know if there is a precedent [19:35] I wonder why was the option added to switch and not branch though [19:35] since branch has more options for things like revision [19:44] luks: it's a convenience command [19:46] luks: because at the time I got motivated enough to implement "-b" I was thinking about switch [19:46] there is certainly an argument for "bzr branch --switch" [19:46] nobody has cared enough to do it :) [19:47] in fact, I generally work that way as well, but I wrote 'bzr-start' to handle that for me [19:47] lp:~jameinel/+junk/bzr-start [19:47] uses the 'submit:' branch to decide what the source should be [19:48] so "bzr start ../lp/my-new-feature" [19:48] branches from bzr.dev, and switches to it [19:48] jam: does http://paste.pocoo.org/show/133506/ look sensible? [19:48] (for inclusion in bzr.dev) [19:48] luks: I think if we add the "two location" variant, we should just make "bzr branch --switch" rather than "bzr switch -b target source" [19:49] ok [19:49] luks: though that is *my* opinion [19:49] I'll submit a patch for that [19:49] note there has been some recent discussion [19:49] I like it better, too [19:49] where lifeless and abentley have mentioned wanting "bzr switch --new" [19:49] because they want to use it for bzr-loom and bzr-pipeline [19:49] ah [19:50] and they didn't like "-b" since it would be "new-loom" or "new-pipe" [19:50] or whatever [19:50] so at least think about that briefly [19:50] *I* like "bzr branch --switch ../source ../target" [19:50] me too [19:51] maybe minus the ../ ? [19:51] in my case it's more often ../branches/source ../branches/target [19:51] or would that relative location handle that as well? [19:51] luks: so "switch" knows about relative locations and "branch" doesn't [19:52] one of the problems about *creating* branches is that it can be unclear [19:52] if you typed "bzr branch source target" [19:52] is source relative to the current tip? [19:52] is target? [19:52] or is target relative to the working dir? [19:52] I generally like using real path, because I can tab-complete on that [19:52] if source is relative to X is target then relative to X ? [19:53] luks: that's incentive for better tab completion [19:53] LarstiQ: hard to implement as a bash extension if bzr startup time is as it is [19:54] luks, LarstiQ: I think, in general, it is a UI issue that is hodgepodged right now, and nobody has gone through and figured out what it should be [19:54] I really like the way it works in git [19:54] garyvdm: ping [19:54] switch, IIRC, is the *only* command to support "bzr switch foo" to mean "bzr switch $CURRENT/../foo" [19:54] Hi bialix [19:54] garyvdm: so is it ready yet ? [19:54] :) [19:54] Busy with the release... [19:54] evening Gary [19:54] not yet [19:55] btw garyvdm, you seem to be doing *far* too much development work on release day [19:55] garyvdm: I've fixed some typos in NEWs [19:55] take it from the bzr project, that is a very good way to break things :) [19:55] garyvdm: can you look at them? [19:55] bialix: Yes [19:56] one sec [19:57] yam: I know it not good. If there are bugs, I'll do 0.13.1 before bzr 1.18(2.0?) final. [19:57] loggerhead should really not annotate files by default [19:57] *jam [19:58] garyvdm: http://paste.ubuntu.com/250990/ [19:58] jam/bialix: do you guys think I should leave the annotate and diff change out the release. [19:58] diff fixes are superious [19:58] garyvdm: I don't really care. I think they seem like good things [19:59] jam: we have regressions all the time [19:59] bialix: Please commit and push. [19:59] Just recommending that you do the work right after a release [19:59] rather than right before [19:59] so even release day is ok [19:59] bialix: "spurious" ? [19:59] ? [19:59] WDYM? [19:59] (1:58:54 PM) bialix: diff fixes are superious [20:00] I'm trying to understand what you mean by "superious" [20:00] SUPER++ [20:00] bialix: Normally we catch the regressions before we release. [20:00] it seems I've construct the word using russian grammar [20:00] bialix: I was concerned you meant :http://www.merriam-webster.com/dictionary/spurious [20:00] " outwardly similar or corresponding to something without having its genuine qualities" [20:01] (often used as, you changed something that didn't really need to be changed, for no real net benefit) [20:01] jam! [20:01] you are laughing fromme [20:01] don;t [20:01] not laughing [20:01] just not sure whether you meant "those are really good" [20:01] versus "those really didn't help anything" [20:01] spurious == don't help [20:02] super++ == help a lot [20:02] the latter [20:02] I've just realized [20:02] Gary perhaps pronounced similar to Harry? [20:03] Yes [20:03] wizard Gary [20:03] Lol [20:04] I'm glad 0.13 won't be boring maintenance release [20:04] pushed [20:05] wow, paste.ubuntu.com correctly displays russian. kudo for people coding it [20:06] garyvdm: do you need any other help with release from me? [20:06] I don't think so. Maybe with Inno, but If I get stuck, I'll mail you. [20:07] I'll build installer tomorrow morning, don't worry about it [20:07] it seems official bzr rc installer will go first ;-) [20:09] garyvdm: so, write some optimistic announce mail, this release really deserve it. there is a lot of tasty improvements [20:09] thanks a lot [20:10] Ok - I'll maybe include some screen shots [20:10] good idea [20:13] Sorry for the intrusion, but is there anyone here that can help me with something which looks like a corrupted bzr repository (bug 405251)? [20:13] Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251 [20:14] jam: it seems I might take the lazy way and just start using your bzr-start instead of patching branch :) you shouldn't point me to the plugin [20:14] :) [20:14] well, I wrote it because it works well for this mode of operation [20:14] and is *just* special enough [20:15] that i didn't think it was worthy of being a core command [20:15] 99% of cases I branch from trunk, so submit location works fine for me [20:15] I don't really like the name 'start', though it works well for me [20:16] jam: qbzr 0.13 tar uploaded and taged revision pushed. === Edwin-lunch is now known as EdwinGrubbs [20:18] of course, I usually also wait for bzrtools 1.18 to be released, so no real pressure from you guys :) [20:18] lol [20:20] luks: There is a command in the .deb building world that automatically downloads the latest source package. I can't remember what it is. I think it starts with "u". Do you know what it is? [20:21] uscan? [20:21] why are you not using bzr builddeb though? [20:22] (or maybe you mean uupdate) [20:22] I used to work with watch files that called uupdate automatically [20:22]