© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I did add a bit of discussion to:
http://
Since I didn't know of a better place to put it.
I also realized something else, though. Which is that you can do:
cd mainline
bzr merge ../feature
bzr commit -m "merging feature" # revno 10
<hack hack, commit commit>
<oops, we don't want 'feature'>
bzr merge -r 10..9
bzr commit -m "removing feature" # revno 15
cd ../feature
bzr merge ../mainline -r 14
bzr commit -m "Getting into sync with mainline"
bzr merge ../mainline
bzr revert . # Remove the 'remove feature' changes
bzr commit -m "Override the feature removal"
This is a bit... difficult, but it records what you want.
The mainline still considers that it has reverted the feature, but the feature branch now has a revision which restores everything. It should even do the right thing for annotations (leaving them at the line that originally modified them, not the new merge/revert revision).
It is certainly possible that we could write a plugin to help automate this, as it is all pretty systematic. You could even do something like:
bzr unmerge ../feature
And have it do all the steps to both '.' and to '../feature', having it detect where in '.' feature was merged, revert those changes, etc.
The biggest problem is probably that you have to do the "bzr merge ../mainline -r 14". And bring the feature branch to the tip of mainline. Which could be problematic.
The other alternative was to rebase, which would look something like:
cd project
mv mainline old_mainline
bzr branch old_mainline mainline -r 9
bzr rebase ../mainline -r 10..-1
This creates new commits in mainline, which means that if someone is mirroring your branch, they need to "pull --overwrite" as the history has now diverged. This is a bit "cleaner" overall, but it does mean going back and hiding history, rather than annotating it to indicate that you want to do something different.