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