[00:03] Hi igc [00:04] hi jelmer, GaryvdM [03:31] * igc lunch [08:53] ronny: create_branch_convenience returns the branch as a result [08:53] LarstiQ: then something is weird, i got none, let me check again what i did break [08:55] ok, pdb sucks [08:55] LarstiQ: i guess you're not here at uds? [08:56] mwhudson: correctly guessed. [08:56] boo [08:56] mwhudson: I will be at EuroPython fwiw. [08:56] mwhudson: yeah :/ [08:56] i won't, but oh well [08:56] mwhudson: what would be the next intersection point? [08:57] LarstiQ: ok , pretty much found the issue - pdb wont print bzr branches when typing them in, wraping str/repr around kinda fixes it [08:57] * LarstiQ blinks at ronny [08:57] ronny: the print fine in ipython, I wonder what pdb is doing? [08:58] LarstiQ: coming to lca? :) [08:58] no idea, defered finding the issue [08:58] mwhudson: eh, I'll take it into consideration, will have to look for travel sponsorship I guess :) [08:58] yeah, that's the problem [08:58] * igc dinner [08:59] igc: eet smakelijk [08:59] i guess there will be other bzr sprints [08:59] LarstiQ: ok, pdb itself is pretty much broken, and nothing to easy fix [09:01] mwhudson: yeah [09:01] ronny: does ipdb fare any better? [09:03] LarstiQ: no idea, afair thats not in py.test [09:05] ronny: something like --enter-pdb-on-error? [09:05] yes [09:05] right, probably not then [09:20] you guys are working on versioned properties aka editable commit messages? [09:47] hsn_, I'm not aware of anybody actively working on it, but there are some vague plans for it [09:53] jelmer: could mrevell and i get you to write a little paragraph on why bzr-get kernel imports don't work yet? [09:53] (for the launchpad blog) [09:56] mwhudson: sure [09:56] jelmer: thanks [09:56] jelmer: email it to me? === Kissaki^0ff is now known as Kissaki [09:59] igc, hi [10:01] mwhudson, I hope evolution cooperates long enough for that to be possible :-) [10:01] jelmer: heh [10:01] jelmer: you can sms it to me if that doesn't work? :) [11:09] hi jelmer [11:09] hi mwhudson [11:09] hi ig [11:09] c [11:10] igc: Thanks for the send review; I think I might've read more into your original review after seeing bzrlib.version_info [11:11] jelmer: yeah - sorry for the multiple round trips [11:12] jelmer: btw, is there an easy way for me to benchmark your bencode revision stuff? [11:12] I could fastimport OOo again but I was wondering if there was a quicker script for just converting the revisions? [11:15] igc, No worries [11:21] igc: to microbenchmark the revisions, use the serializer interface directly [11:22] beuno: [11:31] jelmer: Would a fastimport that produces a bzr-svn compatible branch be feasible [11:31] hi lifeless, sure [11:31] jelmer: The bzr-svn behaviour of holding a whole revision in memory requires some heavy iron for some repositories [11:32] hello [11:32] awilkins: in theory, yes [11:32] it's doesn't yet though [11:33] awilkins: I'm pretty sure the fast-import code is designed though so that the rev-ids could be bzr-svn compatible (if we added some way of enabling that) [11:33] hi poolie [11:33] * igc bbl - time to get the kids to bed :-) [11:34] awilkins, It shouldn't actually keep the contents of the revision in history === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:55] night all [14:01] night igc [14:44] hi [14:44] is there any simple way to get the workingtree of a branch in case them sharing the same path? [14:44] they share a container [14:44] You can use something like b.bzrdir.open_workingtree() [14:45] jelmer: oh, intresting, that should do [14:45] ronny, it'll raise bzrlib.errors.NoWorkingTree if there's no working tree present [14:47] jelmer: the vast differences in terms of separation betwen repo/branches/workdirs and the different sets of syncronisation are still making headaches for me [14:50] i end up with the issue of lacking a coherent way to create light/heavy checkouts from local/remote locations for all of the vcs's [15:14] ronny: If it's any help, I'm using the following ; a .repo folder with the repository in, a `list` file, and then I can synch to the svn stuff by doing ; for B in `cat list` ; bzr pull -d $B/trunk svn+http://server.com/svn/$B/trunk ; done [15:15] ronny: Then I branch each trunk so it has a sibling, local [15:15] And take lightweight checkouts of those local branches [15:15] awilkins: what do you think the context is? [15:15] Context? [15:16] ronny: Your comment above at 1450 [15:17] awilkins: but im not talking about bzr/bzr-svn [15:17] ronny: Fair enough [15:29] hey jelmer, were you able to look at that paragraph for the Launchpad blog post? [15:30] mwhudson, ping [15:30] mrevell, Sorry, I forgot about it. Michael just reminded me about it and I'm working on it now [15:30] ah thanks :) [15:36] jelmer: hi [15:36] Hi bialix [15:36] may I ask about some strange bzr-svn behavior? [15:36] bialix: sure, np [15:37] I've tried to catch you yesterday [15:37] I've branched svn repo from http://projects.serverzen.com/pm/p/cluemapper/browser/ClueBzrServer/trunk [15:37] I can see the log of the branch [15:37] but when I'm trying to see diff I've got: NoSuchRevision: KnitPackRepository('file:///C:/Temp/ClueBzrServer/trunk/.bzr/repository/') has no revision rocky@serverzen.com-20090226184017-m3cemyrz487uxhg3 [15:37] this svn repo contains bzr branches inside [15:38] or used bzr-svn to interact with [15:38] I see many ghost merges [15:38] does I branch trunk in wrong way? [15:39] I'm using bzr 1.14 (for Windows) with bzr-svn 0.5.4 [15:39] jelmer: ^ [15:40] bialix, That URL doesn't actually work for me, are you sure it contains a Subversion repository? [15:41] I've used this command: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk [15:41] the first URL is Trac site URL [15:43] bialix, I think this may be a bug that's fixed in 0.6.1 [15:43] entire svn repo root at https://dev.serverzen.com/svn/cluemapper/ [15:43] bialix, At least, branching that URL works fine here [15:44] branching is OK [15:44] try to run bzr diff -c8 [15:44] in your copy [15:44] of that branch [15:44] does it work for you? [15:44] bialix, that breaks here as well and is a bug in Bazaar dealing with diffing ghosts [15:45] there's an open bug report about it I think [15:45] bialix: does branching the bzr branch work? [15:45] bialix: and or running `bzr reconcile`? [15:45] but... it seems this ghost revisions were created with bzr and then pushed back to svn repo [15:45] LarstiQ: hi [15:46] bialix: if they bork, I think I know which bug it is [15:46] a rather elusive one :/ [15:46] LarstiQ: what do you mean by: "does branching the bzr branch work?" [15:46] bialix: 'bzr branch svn:/// foo; bzr branch foo test' [15:46] yes, this works [15:46] bah :) [15:47] * LarstiQ hoped to have found a way to reproduce a bug of his [15:47] try yourself. there is only 15 revisions [15:47] LarstiQ, it's a known bug, where bzr diff tries to get the file mtime of a ghost text [15:47] LarstiQ, different from the one you and Ted Gould have been hitting [15:47] jelmer: but why there is ghost? [15:47] jelmer: k [15:49] jelmer: run bzr log --show-ids [15:49] bialix, There are ghosts because there have been pushes into svn with just the mainline, not the merged revisions. [15:50] it looks like these revisions have pushed using bzr-svn [15:50] bialix, Sure [15:50] lifeless: are you home now? [15:51] perhaps I don;t understand how bzr-svn push works [15:54] bialix: So, if you use "bzr push" from bzr-svn and have "push_merged_revisions = False" it only pushes the revisions on the mainline into the branch you're pushing into [15:54] jelmer: branching entire project with command: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer [15:54] bialix, so the right hand side revisions end up as ghosts if you later try to get them out again [15:54] this one does not have ghosts [15:54] bialix: This is all expected behaviour [15:54] bialix, except that Bazaar doesn't handle the ghost case very well in diff [15:54] but that would also happen in other situations in which we end up with ghosts [15:55] it's nothing to do with bzr-svn [15:55] jelmer: I think there is something strange [15:55] these revisions ARE in the svn repo [15:56] I've just get entire project with trunk-branches-tags and now I don't have this error [15:56] it looks for me that when I get only trunk bzr-svn does not try to get corresponding merged revisions from branches/ [15:57] looks like bzr-svn round-trip breaks somewhere in the middle [15:57] bialix, in that case there's two bugs here, one in bzr and one in bzr-svn [15:58] bzr-svn missing revisions during fetch [15:58] maybe [15:58] you're the master of bzr-svn, not me [15:59] I hope you understand what's going on better than me [16:00] maybe it's another use case for colocated branches [16:01] How are colocated branches related to this? [16:03] pull all related branches from svn repo at once, maybe [16:04] GaryvdM around? [16:04] Hi bialix [16:04] hi Gary [16:04] I found that qlog does not show ghost merged revisions in revision properties. Is it right? [16:05] Done the log -> diff changes. Just doing some testing before I push. [16:05] bialix, pull is already supposed to pull in all merged revisions [16:06] bialix: I have never found a way to create a branch with ghosts, so I've never been able to test how it behaves. [16:07] GaryvdM: try this: bzr get https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk [16:07] and then compare output of bzr log --show-ids and qlog [16:07] * GaryvdM installs bzr-svn [16:07] jelmer: so it's a bug in bzr-svn then [16:08] bialix: Is cluemapper a SNOMED-CT product? [16:08] GaryvdM: I can push to lp [16:08] awilkins: I don't know, saw the link from Gary yesterday [16:08] don't worry - allready branching. [16:09] http://projects.serverzen.com/pm/p/cluemapper [16:09] awilkins: ^ [16:09] * awilkins looks [16:09] Ok then, no it isn't [16:09] Sorry, we have this thing called CLUE [16:10] And mapping is a logical thing to do with the stuff it manages [16:10] bialix, trying to verify that now [16:31] * bialix waves [16:34] GaryvdM, bzr revert -rtag:bzr-svn-0.5.4 [16:40] james_w: jml is looking for you [16:40] mwhudson: room 12 [16:40] jml has now run away, damn him [16:40] damn him indeed [17:14] estella damm [17:14] pygi: http://sourceforge.net/project/showfiles.php?group_id=121075&package_id=132255 [17:17] poolie: ah, found the barcelona beers? :) [17:18] poolie: the icons are working :p [17:22] what command is used for setting parent branch? [17:24] pygi: yay [17:32] hsn_: `bzr pull --remember parent/url` [17:35] LarstiQ: thanks [18:09] Hi folks :) [18:11] is there any speed improvements planned for the "bzr log -v" command??? currently it takes 7 minutes on a branch from lp:drizzle on my 2.4ghz quad core box (with 4gb ram)... [18:13] trondn: it should be much faster in the development-rich-root format [18:13] poolie: can I convert my repository to this format? [18:14] the reason I ask is because I need it for OpenGrok (see http://src.opensolaris.org/source if you want to see it in action)... I need to get the complete list of files in each revision along with the commit message... [18:15] trondn: yes, but there are two caveats: this format is still in beta for a 2.0 release later, so there will be bugs [18:15] and the conversion takes some time [18:15] like hours, for a large branch [18:15] also, there are some log improvements coming up soon [18:15] even for other formats, so just using 1.15 may help [18:15] poolie: I'm running 1.15 already :) [18:16] great to know! [18:16] Right now this is the biggest problem I have with bazaar :-) [18:17] trondn: so this is just a readonly mirror? [18:17] then i'd definitely recommend upgrading [18:17] you can still pull from lp:maria [18:17] i mean lp:drizzle [18:17] and we'd like to hear your feedback [18:17] poolie: Yeah, the browsing will be from a readonly mirror :-) [18:19] poolie: I am currently using it (opengrok) to index mercurial repositories with over 76 gb disk footprint on src.opensolaris.org. I would like to have the same search options on the source I am working on from launchpad (btw. I love the complete integration of everything on lp!! nice work :) ) [18:20] thanks! [18:58] how do i get diff (preferably colorized somehow) output in vim when i'm writing a commit message? [18:58] Well, the colorizing would be vim's turf. [18:59] But try ci --show-diff [18:59] fullermd: cool thanks, anyway to make --show-diff the default behavior of ci? [19:00] I have it aliased. [19:00] seems setting filetype=diff or filetype= in vim pretties it up a bit, wonder how to make that automatic [19:01] au BufEnter bzr_log.* [19:01] fullermd: i owe you a beer ;-) [19:02] thanks [19:02] * fullermd has his uses 8-} [19:34] Hi all. [19:34] What is the equivalent of svn export for http://bzr.savannah.gnu.org/r/gnash/trunk ? [19:34] I want a snapshot of the sources. Don't care about the history. [19:37] rindolf: bzr export dest http://bzr.savannah.gnu.org/r/gnash/trunk [19:38] schmichael: thanks! === BasicPRO is now known as BasicOSX [20:05] schmichael: is bzr export like that faster than doing bzr branch? [20:08] rindolf: I haven't looked at it, but I can imagine a worst case in which it's slower than bzr branch [20:08] rindolf: so, I wouldn't place faith in statements about it's speed without backing it up with some evidence [20:09] LarstiQ: ah. [20:10] rindolf: exporting a revision tree is not a usecase the storage is optimized for [20:10] rindolf: yeah, bzr repos are compressed so they might actually be signficantly smaller than the working copy if the project has little history and easily compressed files (i think ;) ) [20:10] rindolf: test it I say! :) [20:11] LarstiQ: I'm trying to download a gnash snapshot. [20:11] I gave up on bzr branch because it took so long. [20:11] But bzr export downloaded 167408KB so far [20:12] damn! [20:25] beuno, ping! [20:25] beuno, http://wiki.services.openoffice.org/wiki/Renaissance/Design_Proposals_for_%E2%80%9CAccessing_Functionality%E2%80%9D <--- usability testing for OOo === jelmer is now known as Guest85613 === Guest85613 is now known as jelmer === jelmer is now known as Guest78963 === Guest78963 is now known as jelmer [22:09] mwhudson or beuno: ping [22:09] Peng_: hi, about to go to sleep; send email [22:10] mwhudson: D'oh. One quick question? :D [22:10] mwhudson: Anyway, good night. :) [22:10] Peng_: ok [22:11] mwhudson: The "bzr serve" registry landed in bzr.dev. Do you want to keep the code to override cmd_serve for a few months? [22:11] Or can we break compatibility now? [22:12] hmm [22:12] don't konw [22:12] ask beuno :) [22:12] * mwhudson zzzz [22:13] mwhudson: Okay. :) [22:14] Peng_: delete it; label the release as requiring a minimum bzr [22:15] lifeless: Sure, but backwards compatibility is nice, and no extra effort. [22:15] Peng_: you did ask :) [22:17] imo, I'd raise the minimum bzr version after there is another release of bzr [22:17] lifeless: :P [22:17] LarstiQ: sure, I have no strong opinion [22:18] * LarstiQ nods [22:19] lifeless: my condolences btw [22:20] LarstiQ: thanks [22:28] Oh, that's right. My condolences as well, lifeless. [22:35] Peng_: thanks [22:46] how do I enable the bazaar nautilus integration? I have bzr-gtk installed. [23:25] hey guys... my coworker is getting an OOPS for any "bzr branch lp:(anything)" [23:26] and i do too... is launchpad down or something? [23:26] robey: It's read-only for maintanence right now. [23:26] yeah the website says that, but even "branch" fails [23:27] I guess the XML-RPC server didn't take it well. [23:27] i'm hoping there's something simple we're missing cuz this is his first impression of bzr after i've been promoting it for months, and he has the rage [23:27] it looks completely broken :( [23:27] Launchpad looks completely broken, not bzr. [23:28] i doubt he cares about that distinction... oh well. :( thanks [23:28] robey: too bad for your friend. Have any local branches he can branch? [23:28] so give him a non-launchpad url [23:28] Looks like bazaar.lp is down as well. [23:29] it's something hosted on launchpad, and launchpad only seems to advertise the lp: names these days... i couldn't find any page that divulged the real url [23:30] robey: but maybe you could use `bzr serve` and he branch from your copy. [23:30] Like I said, bazaar.lp is down anyway. [23:30] i've never fetched that project [23:30] ah [23:31] nevermind, i think the damage is done. thanks for helping tho. [23:35] Oh, good, lp: URLs work again. Though bzr+ssh://bazaar.lp.net doesn't. [23:36] ...Which makes sense if it's read-only, I guess... [23:36] too bad robey is gone [23:39] robey's friend isn't very patient [23:39] :( === jelmer is now known as Guest97317