[00:00] Verterok: But you wouldn't necessarily want to display all revision properties [00:01] jelmer: right, because of that show_properties isn't implemented in the core, bzr-svn should provide it's own LogFormatter implementation to handle it's own properties ;) [00:01] Verterok, Right, but I would want to hook into the default LogFormatters [00:04] jelmer: ok, so this isn't going to work for you [00:04] thanks, I'll keep thinking how this could be done [00:05] Verterok: Thanks [00:06] jelmer: np :-) [00:19] wow. I just typed bzr st on a svn branch by accident [00:19] now it appears to be recalculating something expensive [00:25] jelmer: maybe my proposed solution can be used after all. I just found that registered LogFormatter can be removed from the registry [00:25] so, bzr-svn can override the default formatter if it provides a show_properties or similar hook [00:25] jml: Ah, yep, it would be caching some revision metadata [00:28] jelmer: but I'm not 100% sure of what I'm saying...I'm going to try to implement it and see if it works :P [00:28] Verterok, that would block others from registering custom handlers though no? [00:31] jelmer: it depends on how and when bzr-svn take control. [00:31] * Verterok getting bzr-svn to look how it works [00:33] jelmer: i'm having a hell of a time getting python svn support to work on osx leopard, know of any handy guides? [00:33] have spent some time in #svn [00:34] bitmonk: you may want to talk to mwh, he has compiled svn on MacOSX afaik [00:34] * bitmonk nods [00:34] i have as well, just not in a while. [00:34] I don't have a Mac myself so I don't have any experience with it [00:40] jelmer: y're right, it will block all others :-( [00:42] does bzr-svn work with 1.0? [00:42] aadis: yes [00:44] jelmer: another (and last for today) approach: plugins can register it's own show_properties(dict) and it's stored at class level in the LogFormatter. This way a LogFormatter can have n show_properties [00:45] Verterok: Yes, I think something like that would work [00:48] jelmer: ok, I'll make a proof of concept [00:49] cool [00:53] anyone had any success with bzr 1.0, rich-root, trac+bzr ? [00:56] aadis: what errors are you getting? [00:56] jelmer: one sec, i'll paste [01:13] jelmer: sorry, that took a while [01:13] i'm getting this: "TypeError: can't compare datetime.datetime to float" [01:14] under "Browse Source" [01:15] i'm assuming trac+bzr works for repos created with: --rich-root-pack --no-trees [01:15] aadis, I think that's an old error [01:15] and unrelated to rich-root-pack [01:15] or rich-root [01:17] ah, mixing 0.10 and 0.11 plugins. i see. [01:20] but now this "ZipImportError: bad local file header in /usr/lib/python2.5/site-packages/TracBzr-0.2-py2.5.egg" [01:20] i just built and installed the plugin, fresh checkout. weird. [01:43] jelmer: I have a working implementation of the show_properties for 'log --long', I can upload it to a server if you want to take a look and see if it's the right approach [01:52] * Verterok dinner === Verterok is now known as Verterok_ [02:32] luks: ping [02:44] Verterok_, ah cool [02:44] Verterok_, yeah, that'd be nice === Verterok_ is now known as Verterok [03:01] jelmer: ok, it's a patch against the latest bzr.dev, get it from: http://freeshells.ch/~guillo/code/properties_log.patch [03:27] Verterok, cool [03:27] Verterok, I'll have a look tomorrow, thanks! [03:27] jelmer: ok, tell me then what do you think about it. [03:27] I'm leaving too [03:28] * Verterok heading to bed [03:36] seeya === Verterok is now known as Verterok_ [04:27] Has anyone integrated bzr with the Roundup issue tracker? === pcapriotti__ is now known as pcapriotti [12:17] <``Cube> jelmer: ping [12:19] <``Cube> jelmer: what's with the icons? === pcapriotti_ is now known as pcapriotti [13:46] <``Cube> jelmer: ??? [13:46] <``Cube> you there [13:52] He was there...ten hours ago. [14:09] <``Cube> hehe ;= [14:09] <``Cube> jelmer: you here now? [14:10] Ohhh. The `` in your nick kept making me think you were using /me. [14:44] <``Cube> lol [16:02] <``Cube> hello [16:02] <``Cube> anybody there? [16:04] ``Cube: Hi [16:05] <``Cube> WOW [16:05] <``Cube> hello jelmer! [16:05] <``Cube> been seeking you for 5 hours now [16:05] <``Cube> nevermind, what about the icons? [16:07] <``Cube> jelmer: !!!! [16:08] ``Cube: Sorry, no news on that yet [16:08] ``Cube: I haven't even sent mail to the list yet [16:08] <``Cube> hmm [16:08] <``Cube> ... [16:08] <``Cube> ok [16:08] <``Cube> when will you do that? [16:09] <``Cube> jelmer [16:09] I'll send an email right now - should I cc you? [16:14] <``Cube> yea, would be cool [16:14] <``Cube> jelmer: ill give you the email in private chat [16:14] ok [16:24] <``Cube> jelmer: sent? === bigdo1 is now known as bigdog === Verterok_ is now known as Verterok [19:08] <``Cube> jelmer: and? [19:11] <``Cube> does anyone here know DANIEL SCHIERBECK? [19:12] <``Cube> I think he works for bazaar [19:16] ``Cube: Sorry, got distracted by some other things [19:16] ``Cube: Will send the email within the next hour [19:18] <``Cube> uh [19:18] <``Cube> ok [19:18] <``Cube> can you tell me one thing: [19:18] <``Cube> can I start with tangofing the current high resolution bazaar icon? [19:21] ``Cube: yes, I think that would be a good idea [19:21] ``Cube: did you get bzr-gtk running? [20:41] <``Cube> jelmer: I got the icons ready, I have a 192x192, 144x149, 48x48 and working on the 32x32, 22x22 and 16x16 will come [20:41] Cool! [20:41] <``Cube> yea [20:41] <``Cube> do you want to see them? [20:41] <``Cube> maybe they're totally crap [20:41] <``Cube> sorry for that language [20:41] <``Cube> would you like to check'em out? [20:42] <``Cube> or not, jelmer [20:42] <``Cube> and could you give me the IRC name or daniel schierbeck [20:42] ``Cube: Please [20:42] <``Cube> cool, ill upload them, one second [20:42] his IRC nick is schierbeck usually [20:42] <``Cube> oh ok, thanks! [20:43] ``Cube: I've just sent that email. Sorry it took so long. [20:44] <``Cube> eh, no problem [20:44] <``Cube> hope ill be allowed to make them [20:44] <``Cube> and I hope they'll be good enough [20:44] ``Cube: Btw, I have another request, somewhat related.. any chance you could do an icon for bzr-svn? [20:44] <``Cube> well, one thing to keep in mind: even if you think they're totally bad, don't just say no: I can change them completely [20:45] * jelmer looks forward to seeing them :-) [20:45] <``Cube> eh, I think that belongs to the icons I should do? (= sure!) [20:47] <``Cube> http://cubibubi.cu.funpic.de/tango/bazaar/ [20:47] <``Cube> AND KEEP IN MIND WHAT I JUST SAID PLEASE [20:47] <``Cube> there can be changed so much... [20:47] <``Cube> I'm really looking forward to your first impression... [20:47] <``Cube> hope it's going to be positive [20:48] w00t [20:48] yep :-) [20:48] <``Cube> heh [20:48] <``Cube> really? [20:48] <``Cube> you like them? [20:49] Yeah, they look great :-) [20:49] <``Cube> heh [20:49] <``Cube> anything I could add/change, something that you don't like 100%? [20:50] The logo is meant to look like a traffic sign [20:50] <``Cube> ah [20:50] <``Cube> so, more metallic look? not so much glow? [20:50] could you remove the line between the head and the tail of the "road" on the sign? [20:51] <``Cube> oh, :P yes should be easy, I knew that wouldn't be correct [20:51] <``Cube> ill remove it, gonna take up to 5 minutes for all sizes [20:51] <``Cube> well, I intentionally created a 192x192 (for launchpad) and 144x149 for your size (bzr [21:28] can anyone do a bzr upgrade for me at bazaar.launchpad.net/%7Ebauble/bauble/trunk/ [21:28] bazaar.launchpad.net/~bauble/bauble/trunk/ [21:30] batoms: better ask in #launchpad [21:31] jelmer: i did but no response [21:37] batoms: I think they're all on their christmas break atm [21:39] jelmer: well maybe santa will bring me some patience for xmas [22:05] is it possible to merge two projects? e.g: use the theoretical r0 shared revision as a common ancestor [22:05] Sure, I do it all the time. [22:05] really? How (and why? :-) ? [22:05] All the files are different, of course. [22:05] Yeah, why do you happen to have to merge projects a lot? [22:06] Because I keep some commonly-used code in its own branches, then I can merge it into projects that use it. [22:06] and how do you merge? [22:06] bzr merge refuses [22:06] Try with "-r0..-1". [22:07] great, thanks. Why doesn't -r0 work? [22:08] what does 0..-1 mean? [22:08] Well, '-r0' means "merge from the common ancestor up to rev 0", which is kinda a double-meaningless. [22:08] 0..-1 means "from 0 through the head" [22:09] oh ok, thanks! [22:10] No problem :) [22:16] New bug: #178353 in bzr "Memory error on branch from launchpad" [Undecided,New] https://launchpad.net/bugs/178353 [22:27] there doesn't seem to be a "blame" for directories? [22:27] I want to know which revisions touch some directory or anything in it... [22:31] bzr log --line path/to/dir [22:32] Er. That doesn't do what you might hope it does... [22:32] Hrm.. oh yes.. :/ [22:32] OK... what about bzr log --line `find path/to/dir -type f` [22:33] Nor does that. [22:33] Hrm... [22:33] (off top of my head) find path/to/dir -type f | xargs -n1 bzr log --line | sort -r | uniq [22:33] log only takes one file. [22:34] Uff. Call me next week when THAT finishes running :p [22:34] Ah. That works for me :) [22:34] But then I just tried a tiny tree of 6 files and 7 revisions [22:35] Mmph. Not so comfortable with a few hundred files and thousand revisions... [22:35] Ya.. I imagine perhaps not so [22:35] thanks, I'll try that :) [22:36] Or for those of us who don't like --line ;) [22:36] it took about 2 seconds on my repo :-) Thanks! [22:47] hmm, I am trying to make a retroactive removal of files in my repo, by creating a new repo and merging selected revisions from the original one (ignoring the ones I don't want carefully) [22:47] And I caused bzr 0.90.0 to get an assertion error [22:48] assert len(history) == revno, '%d != %d' % (len(history), revno) [22:48] AssertionError: 47 != 1 [22:48] * fullermd blinks. [22:49] I basically used: bzr merge ../old-branch -r0..46 ; bzr commit [22:49] That's... intersting. [22:49] (on a new branch) [22:49] Oh. Hm. [22:49] (because I want to kill revision 47) [22:49] The surprising thing, I guess is that merge let you do it, not that commit failed. [22:49] Try branching rev 46, then working from there. [22:49] I plan to later merge 48..X then X+2..Y and so on [22:50] if I branch from 46 I will still need to merge the revision ranges after, will those work? [22:50] Well, those merges can't really be merges formally speaking, since you're missing a rev. [22:51] What you really want to do is sorta re-make those commits on top of the tree. There might be a plugin to help automate that... [22:52] hmm, can't I merge revision ranges from another branch to me, if those have a gap? [22:52] (a gap between my last and his first) [22:52] in other words, my technique for retro-active killing of revisions/files will not work? [22:52] Well, merge will bring over the changes. But it won't record it; sorta the equivalent of diff | patch (with some smarts on conflict avoidance) [22:53] won't it also record the diffs of the individual revisions in the range into my new history? [22:53] Depends on the definition of 'work'. But your new rev 47 (old 48) won't have any relation to your old 48. [22:54] No, because the individual revisions won't be pulled in. [22:54] I see, indeed I lose the history.. so what are my best options to do retro-active removal of files? [22:54] Well, what you want to do is replay each rev's changes on top of the tree, skipping certain revs/files. [22:55] I think there was at least part of a plugin that could do it. It's sorta the guts of rebase, with some filtering capabilities. [22:55] But I don't know of any existing automated way. [22:55] maybe I'll create one then, thanks [22:55] There used to be a 'graft' plugin, I think; that might be close. [22:56] Try digging that up, or corner jelmer about what could be done with rebase. [23:00] what is rebase? [23:01] but if I use graft or any other commit-based method, won't I lose all the merging/branches information? All I get a serial linear list of commits [23:02] Well, for any commits post the commit you're losing, that's kinda unavoidable (without a whole lot of smarts, anyway) [23:03] I could selectively delete revisions in the past.... [23:03] All the revs past that points are necessarily defunct, since they depend on something you're not gonna have. So they all have to be remade. It would be an interesting exercise to try and remake the full topology... [23:05] I guess there's no theoretical reason it would be impossible (at least, in the general case). Take a fair hunk of work, though. [23:05] Well, i guess for now i'll just lose the history (i'll have it in the old repo, anyhow)