[00:17] jelmer: ping [00:17] jelmer: whats a good, small, example of using tdb from C? [00:18] Hmm [00:18] mmmm [00:18] bacon! [00:18] So dash, whats your bacon number? [00:18] I just merged from trunk into my feature branch and now it wants to undo all the changes I made [00:18] maybe not all, but enough for me to feel like I did something wrong [00:19] should I remerge? should I merge from my feature branch into a copy of the mainline? [00:19] dash: the merge command undid your changes? [00:19] 1.) What command did you run? 2.) You're not using anything weird like bzr-svn, are you? [00:19] yes, bzr-svn =/ [00:19] oh, you know what [00:19] Peng_: I bet its a backout merge from trunk; but we should track it down [00:20] yeah this is probably my fault [00:20] dash: was it the merge command that undid your changes? [00:20] so I did "bzr merge http://svn-server/..../" [00:20] lifeless: I think tdbdump might be a good example [00:21] jelmer: point me at the src? [00:21] 'bzr diff' now shows a diff that will remove a bunch of my changes [00:21] dash: ok. [00:21] lifeless: apt-get source tdb && $VISUAL tdb-*/tools/tdbdump.c [00:21] dash: next question. Had you on trunk, *or on a branch merged into trunk* undone those same changes [00:22] yes [00:22] dash: then bzr is correctly propogating those undoes. [00:22] lifeless: and tdbtool for an example of writes [00:22] yeah, i figured [00:22] hence saying it was my fault :) [00:22] dash: :) [00:22] dash: just being sure [00:23] dash: you should just reject the undo here. [00:23] i checked this code into svn, then later reverted it [00:23] lifeless: right [00:23] I loves it when tools DTRT [00:23] i love it when they don't surprise me :) [00:23] i guess i should do the merge in 2 stages then [00:23] one to reject the rollback done earlier [00:24] and one to pull in the rest of the changes [00:24] dash: no, you should merge, reject, commit [00:24] one step [00:24] dash: that will mean that the next merge from this branch to trunk will reinstate these changes [00:24] hm! ok [00:24] and [correctly] show that you wanted them present on this branch at every point. [00:29] * dash makes a copy of his branch to make sure he didn't misunderstand :) [00:33] lifeless: the difficulty is that the mainline contains changes I _do_ want [00:33] dash: thats fine [00:33] dash: the way you reject could be to use 'bzr shelve' [00:33] true. [00:39] dash: another way to reject is [00:40] bzr merge -r [revert-in-trunk]..[revert-in-trunk-1] $trunk [00:40] oh [00:40] bzr merge -r [revert-in-trunk]..[revert-in-trunk-1] $trunk --force [00:40] (because you already have a merge in your tree) [00:42] that's what i meant by doing it in two steps [00:42] dash: with only one commit [00:42] ? [00:42] oh, didn't know you could do multiple merges with a single commit. [00:42] so [00:42] specifically [00:42] 1) merge trunk [00:42] 2) merge -r X..X-1 trunk --force [00:43] 3) commit [00:43] so 2) == reject [00:43] hah. [00:43] even nicer than what i was trying to do. [00:43] that makes more sense too [01:03] okay! other than having to resolve the same conflicts twice, that seems to have done the job [01:03] lifeless: thanks for the help. [01:03] dash: odd that you had to resolve any conflicts [01:03] dash: but I'm glad you are happy [01:04] yeah well, i should just know better than to check stuff in and revert it like that. :) [04:36] could someone please try out 1.16rc1 packages I just buit in the bzr-beta-ppa. I've split out the docs into a -doc package. Need someone to make sure that the upgrade is smooth [04:38] jelmer: Are you around? === `6og is now known as kgoetz [08:37] johnf: It seems you accidentally clobbered the Jaunty 1.16rc1 in bzr-beta-ppa with the third Dapper attempt. You also don't have the luxury of python-support or python-central on Dapper, so I wouldn't even try backporting bzr to it... [08:39] wgrant: there were already dapper packages but they don't seem to want to build after I split out bzr-doc. I think I'll just revert all the changes for it and it can just have one package [08:42] johnf: Ah, there is indeed a prehistoric python-support in dapper universe that isn't used for anything. Oops. [08:44] and I've royally mucked up the version numbers. I should have been changing ~bazaar not the rc :( [08:45] johnf: You didn't do too badly - you just incremented the Debian revision, not the RC number. [08:45] ahh I did do the right thing. Well close enough anyway [08:46] ~bazaar[23] would be correct, but what you did isn't world-burning. [08:57] johnf: och, you didn't muck up like me introducing a wrong version (-bazaar instead of ~bazaar) that ranks higher than all debian versions we'd want to use [08:59] wgrant: so when would you up -[23]? That is something I've never been quite clear on [09:00] johnf: The first number after the last - is the Debian version. [09:00] As in Debian the distribution, not Debian the package format. [09:00] Debian's first 1.16 version would be 1.16-1. [09:00] If they make a change, 1.16-2. [09:01] When Ubuntu makes a change to a package, we append 'ubuntu1'. The 1 there is the ubuntu version - we'll increment that as we make subsequent changes. [09:01] what about in the case where it is say a native ubuntu package do you still always leave at -1 in case it makes it intu debian? [09:01] We'll use -0ubuntu1 [09:01] ahh ok makes sense [09:01] That way when it makes it into Debian, it'll be -1, and -1 > -0ubuntu1 [09:02] So upgrades will work when -1 is synced into Ubuntu. [09:02] ok new packages should be syncing shortly [09:03] Have you test-built the Dapper on locally? [09:03] s/on/one/ [09:04] You can reasonably drop Dapper packages in a couple of weeks, too (Dapper loses desktop support RSN) [09:06] wgrant: ah, I've been looking forward to that [09:27] Mmm. These DeprecationWarning's on py2.6 are gonna get real old real fast... === Kissaki^0ff is now known as Kissaki [09:35] fullermd: In bzr, or in general? [09:35] Well, from pycrypto technically, but since I see it running bzr... [09:36] is there a way to merge one project into another? I have two python projects, and now I want them to be the same without loosing history [09:36] fullermd: That's fixed in Jaunty and Karmic, at least. [09:37] Neither of which is much help to people who run neither Jaunty, Karmic, Ubuntu, or Linux ;) [09:38] http://launchpadlibrarian.net/23631444/python-crypto-2.6-337073.diff is useful, in those strange cases. [09:39] Inneresting. [11:06] ok I'm in a strange situation: [11:06] I've my working tree out of date [11:07] how could I know at which version is it ? [11:28] Well, you can poke around manually in .bzr/. At one time, info gave you something you could do some math on. [11:28] Or you could use revno/revision-info --tree, but you have to do that in the future. [11:29] or just run bzr update [11:30] Well, that doesn't make it known. Just moot :p [11:31] sureit does. [11:31] it would be -1 === cprov is now known as cprov-afk [13:46] GPHemsley: hi [17:28] hello there. Aw...using bzr 1.13.1 here and working against subversion on the server. Does anyone know why it takes forever to push changes to back to svn? I looked up and found that it used to happen with bzr 0.5- [17:29] btw it also happens when doing bzr co [17:30] fcorrea: newer versions of bzr-svn should be a bit better in that regard [17:30] jelmer: will try [17:33] fcorrea: also, the first time you do a push/pull it'll be a fair bit slower because it has to analyse the repository, after that it should be significantly faster [17:34] jelmer: yeah, but it also happens when pushing it back to svn, so I assume all the analysis were already done, but I may be wrong [17:49] fcorrea: also, how slow is slow? [18:30] Out of curiosity, any of the bzr people heading to EuroPython? [18:32] other than you, lifeless [18:35] (wait, 2 talks? someone with dedication!) [19:31] I've my working tree out of date [19:31] how could I know at which version is it ?