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