[00:47] Hi, if I use bzr revert in a tree to test a previous revision how do I undo that revert to carry on from the latest revision? === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2b4 has gone gold, build those installers [00:54] Meths: 'bzr revert' [00:54] no args [00:54] or 'bzr revert -r -1' [00:56] Ah, thanks. [01:11] I merged from branch1, committed. Made some checkins. Reverted back to a prior checkin before the merge form branch1 (deploy failed and committed the revert. Made changes in branch1 to fix issues, and now I need to merge branch1 again. However, only one file is actually merging over vs the intial 20+ files. What's happening ? [01:11] If it's clear what I want form that description (otherwise ask me to expand) how can I get it to do "what I want" ? [01:23] Revert doesn't undo the commit [merge]. So you only have one more change (that one file) to merge, so that's all merge does. [01:26] so how can I do what I want? [01:27] Well, you have to manually redo all the changes. [01:27] FSVO 'manually', which includes automated manualiness like 'revert'. [01:27] bzr uncommit perhaps [01:27] ? [01:28] I can do bzr uncommit on the main branch [01:28] Well, that would work too, backing up to before you did the revert, if you can throw away all those later revs. [01:28] yeah, that's fine to do [01:28] in this case [01:28] but what if that wasn't the case. I'd have to do it all manually? [01:29] Depends on how much things have changed. If not at all (in context), you could bzr diff | patch -R to undo the revert and restore all the changes. You can use 'merge' against yourself to do the same sorta thing a bit smarter-like. [01:31] ok, I'm on revno 1198. I wish to go back to 1193 [01:31] and then remerge with the branch [01:31] And throw away 1194..1198? [01:31] 1194 was the merge with the branch [01:31] Probably simplest to just use pull; somethine like `bzr pull --overwrite -r1193 .` [01:31] so I could go back there, check that in, and then merge the new changes to the branch [01:31] that may actually be the best [01:33] so if I issue the pull command, will I be able to remerge with the branch again? [01:35] Yeah, since at that point you'd never meged that branch. [01:35] yeah, that worked well, thanks [01:36] in this case it was ok to throw away the changes after, but what if it wasn't ok? What if I needed 1998 ? [01:36] I appriciate your help btw :) [01:36] Fiddling with merge against yourself or diff | patch to redo the changes. [01:37] so fairly painful, in other words [01:37] Depending on how things got arranged, there are other possibilities involving really disgusting merge tricks. [01:38] i was hoping it would be fairly easy to roll back a change that failed badly in production [01:38] Well, yes, with uncommit or pull to pop stuff off the top. [01:38] But revert just makes WT changes, it doesn't "undo" anything. [01:38] yeah [01:38] so maybe I should uncommit even this time? [01:39] what's the cleanest, since uncommit is available? [01:39] You did the same thing with pull. [01:40] ok, so it accomplished exactly the same thing, except made several "uncommits" easier [01:40] The difference is in what happens with the WT. [01:40] the WT? [01:40] With uncommit, the WT and state is left untouched. So after you 'uncommit', you're exactly where you were before you ran 'commit'. Pending file changes, add's, mv's, etc. [01:41] If you used pull instead to back up to that previous rev, you'd be at the "clean" state for that rev. [01:41] (well, not exactly, since pull would try and merge any uncommitted changes you had sitting around, but for simplicity...) [01:41] I'm guessing WT=working tree? [01:41] Da [01:42] so if I had no pending commits, doing the pull and several uncommits would result in the same state? [01:44] A pull to the previous rev is roughly equivalent to "pull ; revert". [01:45] What would you do in my place? [01:46] bear in mind, there are several checkouts of trunk too [01:46] I'm always in favor of running naked, screaming, and covered in blood through the streets. It's cathartic. [01:46] not sure how I'm to deal with the checkouts yet [01:46] lol [01:46] i may try that before i'm through with this [01:46] good excuse to get rid of the cat anyway [01:47] They'll probably require some work to back the checkouts up. [01:51] What about doing a diff of your changes against the starting revision, then patching those diffs against trunk? [01:52] I'v ebeen screwing around with it [01:52] and I think I've got a solution [01:53] ok. yeah, looks good [01:54] I just did [01:54] bzr pull --overwrite -r 1193 . [01:54] and in the checkouts: bzr up && bzr revert [01:56] hm, maybe not so easy [03:45] the NEWS on trunk doesn't seem to have a date for 2.2b4. also there is no tag for 2.2b4 on trunk. is it branched? [03:46] oh. ok. my bad. 2.2 is in its own branch. [06:22] I am getting an error when I try to push to Launchpad: different rich-root support [06:23] I have searched for a solution to this problem and have tried 'bzr upgrade --rich-root-pack' to no avail. [06:26] What can I do to make the two repositories compatible? Is there a method I can use to make all subsequent local bzr repositories compatible with Launchpad by default? [10:42] http://webchat.freenode.net/ === Meths_ is now known as Meths [17:06] hi [17:07] is there a command to import all revs / heads from a shared repo? [22:10] has anyone successfully installed bzr on a bluehost server? [22:13] I'm interested in writing up an install guide, but I might need some help with the install