| lifeless | jelmer: ping | 00:17 |
|---|---|---|
| lifeless | jelmer: whats a good, small, example of using tdb from C? | 00:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| * dash makes a copy of his branch to make sure he didn't misunderstand :) | 00:29 | |
| 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:33 |
| lifeless | dash: another way to reject is | 00:39 |
| 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:40 |
| 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:42 |
| 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 | 00:43 |
| 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:03 |
| dash | yeah well, i should just know better than to check stuff in and revert it like that. :) | 01:04 |
| 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:36 |
| GPHemsley | jelmer: Are you around? | 04:38 |
| === `6og is now known as kgoetz | ||
| 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:37 |
| 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:39 |
| wgrant | johnf: Ah, there is indeed a prehistoric python-support in dapper universe that isn't used for anything. Oops. | 08:42 |
| johnf | and I've royally mucked up the version numbers. I should have been changing ~bazaar not the rc :( | 08:44 |
| 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:45 |
| wgrant | ~bazaar[23] would be correct, but what you did isn't world-burning. | 08:46 |
| 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:57 |
| johnf | wgrant: so when would you up -[23]? That is something I've never been quite clear on | 08:59 |
| 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:00 |
| 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:01 |
| wgrant | So upgrades will work when -1 is synced into Ubuntu. | 09:02 |
| johnf | ok new packages should be syncing shortly | 09:02 |
| wgrant | Have you test-built the Dapper on locally? | 09:03 |
| wgrant | s/on/one/ | 09:03 |
| wgrant | You can reasonably drop Dapper packages in a couple of weeks, too (Dapper loses desktop support RSN) | 09:04 |
| LarstiQ | wgrant: ah, I've been looking forward to that | 09:06 |
| fullermd | Mmm. These DeprecationWarning's on py2.6 are gonna get real old real fast... | 09:27 |
| === Kissaki^0ff is now known as Kissaki | ||
| wgrant | fullermd: In bzr, or in general? | 09:35 |
| fullermd | Well, from pycrypto technically, but since I see it running bzr... | 09:35 |
| 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:36 |
| fullermd | Neither of which is much help to people who run neither Jaunty, Karmic, Ubuntu, or Linux ;) | 09:37 |
| wgrant | http://launchpadlibrarian.net/23631444/python-crypto-2.6-337073.diff is useful, in those strange cases. | 09:38 |
| fullermd | Inneresting. | 09:39 |
| visik7 | ok I'm in a strange situation: | 11:06 |
| visik7 | I've my working tree out of date | 11:06 |
| visik7 | how could I know at which version is it ? | 11:07 |
| 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:28 |
| lifeless | or just run bzr update | 11:29 |
| fullermd | Well, that doesn't make it known. Just moot :p | 11:30 |
| lifeless | sureit does. | 11:31 |
| lifeless | it would be -1 | 11:31 |
| === cprov is now known as cprov-afk | ||
| jelmer | GPHemsley: hi | 13:46 |
| 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:28 |
| fcorrea | btw it also happens when doing bzr co | 17:29 |
| jelmer | fcorrea: newer versions of bzr-svn should be a bit better in that regard | 17:30 |
| fcorrea | jelmer: will try | 17:30 |
| 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:33 |
| 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:34 |
| jelmer | fcorrea: also, how slow is slow? | 17:49 |
| Mez | Out of curiosity, any of the bzr people heading to EuroPython? | 18:30 |
| Mez | other than you, lifeless | 18:32 |
| Mez | (wait, 2 talks? someone with dedication!) | 18:35 |
| visik7 | I've my working tree out of date | 19:31 |
| visik7 | how could I know at which version is it ? | 19:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!