=== Odd_Bloke is now known as vuliev === vuliev is now known as Odd_Bloke === Odd_Bloke is now known as MrWilson === MrWilson is now known as Odd_Bloke === Odd_Bloke is now known as FauxFauxFaux === FauxFauxFaux is now known as spoonspoons === spoonspoons is now known as MrWilson === MrWilson is now known as Muz [09:23] hi [09:23] is bzr join --reference documented anywhere? [09:30] its not supported yet [09:30] lifeless, thanks, my eager friend found this command and managed to get some trees joined by reference but he could not push to a remote server so I started looking [09:31] lifeless, what's the recommended tool to create a workspace out of multiple branches today? [09:31] probably bzr-scmproj [09:32] lifeless, thanks [15:37] Hi. What's the difference between bzr and bazaar on LP? [15:56] XTF: Between https://launchpad.net/bazaar and https://launchpad.net/bzr ? [15:57] XTF, bazaar is the super-project, which includes all its plugins and such, and bzr is just the client [17:50] Is there something like rebase that will help me get two sequential commits that are independent fixes to be both on top of another branch? [17:50] I'm a git user. I apologize in advance for any misused terminology. [17:51] replay? [17:51] merge? [17:51] not quite a merge [17:51] I have A-B-C. I want A-B and A-C. [17:52] Ah.. that's slightly awkward. [17:52] bzr: ERROR: unknown command "replay" [17:52] You can arrive at A-B and A-C', where C' is a new commit containing the same change as C [17:52] Sure, that works. [17:53] C is going to contain some changes of B. [17:53] But it has its own different identity for 'missing' purposes [17:53] Because they may have similar fixes. [17:53] OK. So how do I do that? [17:53] bzr branch -r[revno of A] newBranch; cd newBranch; bzr replay -r[revno of C] ../pathToOldBranch [17:54] where do I get bzr replay? [17:55] It is part of the bzr-rewrite plugin [17:55] Er.. hrmmm. A fun and curious question [17:55] I don't see it in my list [17:55] OK. [17:55] It is a hidden comman, because jelmer says it needs a bit more polish before it goes fully public [17:55] Thanks maxb and LeoNerd. [17:55] * comand [17:55] * command ! [17:55] Ahhhh [17:56] bzr: ERROR: Not a branch: "/home/jstpierre/Source/loggerhead/loggerhead-b/". [17:56] LeoNerd: oh, seeing you here reminds me - were you thinking of going to any of the May bzr sprint? [17:56] do I have to mkdir first? [17:57] aha, bzr branch . -r432 loggerhead-b worked [17:57] maxb: Wasn't planning on, no.. what is it? [17:58] I'm not entirely sure - was going to send an email asking for a bit more detail [17:59] is there a command that will show the changes in the current revision? [17:59] But given it's not far from Pimlico tube, it seemed worth considering :-) [17:59] magcius: diff? [18:00] is there a quick command for it? [18:00] bzr diff -r-1... or something [18:00] bzr diff -c-1 [18:00] aha [18:00] is the same as -r-2..-1 [18:01] so [18:01] uh [18:01] replay didn't work, it just blindly made changes [18:01] can I amend that commit to fix it up? [18:01] some changes that I made in B that are required aren't in C [18:02] Sounds to me like you should 'bzr merge -c whatever' the changes into a new branch [18:02] huh? [18:03] Something like [18:03] cd ../loggerhead-b [18:03] bzr merge -c 434 $OLDPWD [18:03] sure [18:04] see, there's no merge conflict or anything [18:04] there's just two independent features [18:04] they both have some shared changes [18:04] I'd like to have both revisions share those changes, so I can put up a branch quickly and easily [18:05] erm, put up two branches [18:05] one for each feature [18:06] This is where I would use git rebase or git commit --amend. [18:06] and feature branches [18:07] rebase == yuck [18:07] It's useful to have a clean history. [18:07] magcius: What i generally do in cases like that is to create two copies of that branch with the two features [18:07] No, it's useful to have a forged history :-p :-) [18:07] then in both I uncommit the changes, shelve the ones I don't need and commit in each branch [18:07] git commit --amend == bzr uncommit; bzr commit [18:08] that sounds painful [18:08] magcius: it's basically the same thing as what you're doing [18:11] uh [18:11] so I'm using bzr shelve [18:12] how can I make the current change smaller? [18:12] There's two independent changes in there. I want to shelve one of them. It's asking me about the whole thing. [18:13] unfortunately there's no way to split chunks atm [18:13] ... [18:13] all this is doing is getting in my way [18:14] so, what's the workaround here? [18:19] So... anybody got any more suggestions for me to fumble around and fail again with? [18:20] It's not a particularly hard problem: I want 'fix for bug A' and 'fix for bug B' in two separate branches. [18:20] I'm at "HEAD, fix for bug A, fix for bug B" right now. [18:21] So, that's really simple then [18:21] OK. [18:21] Lay it on me. [18:21] bzr branch lp:loggerhead fix-for-b [18:22] cd fix-for-b [18:22] bzr merge -c revno-of-b-fix:../existingbranch [18:22] maxb: : ? [18:23] no? [18:23] bzr: ERROR: Requested revision: 'before:434:../' does not exist in branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/loggerhead/ [18:24] oh, right [18:24] bzr merge -c revno-of-b-fix:../existingbranch ../existingbranch [18:24] maxb: Is the :../existingbranch bit really necessary? [18:25] jelmer: um, possibly not. I'm a bit fuzzy about what branch revspecs resolve themselves against. Sometimes it seems to be the operative branch, sometimes the current directory [18:26] maxb: Which ones /don't/ use the operative branch? [18:26] Something which bit me at some point in the past :-) [18:28] So, dh_python2.... I'm currently leaning toward packaging up some sort of shim that enables the unmodified sid packagings to build unmodified on older distros [18:28] If you're worried about trying to backport to lucid, you could probably come up with a backport of python-defaults that would be safe. [18:29] yeah, lucid would probably be easy [18:29] But currently we go all the way back to hardy [18:29] I don't think hardy would be much harder. [18:30] As long as you only backport stuff that affects buildilng with dh_ptyhon2 it should be safe and dh_python2 works with python2.5. [18:30] It does sound doable [18:31] Though we'd also have to sort out a problem with python-central that only seems to show up on hardy - it tends to fail to remove its symlinks when a package is being upgraded away from using python-central [19:35] re