Changes between Version 6 and Version 7 of BranchingPolicy

Timestamp:

08/26/10 15:07:47 (4 years ago)

Author:

dread

Comment:

--

BranchingPolicy

@@ -30 +30 @@
  * Bug fixes should be merged UP the waterfall: `default` <- `metastable` ( <- `stable` <- `ultrastable` )
 
-(One future problem with this system might arises when you want a change on a branch which you don't want merged up the waterfall and wouldn't cause a conflict. We've not thought of a use case like this, so we will deal with not being able to merge upwards, it if it arises.)
+It is good to merge all branch changes up the waterfall to the top, so that you don't forget to apply a bugfix to a higher branch. In the process  of doing this, you close the branch heads on the way. So when you push new changesets onto a branch (aside from `default`), you should expect to be reminded to create a new head (`hg push -f`).
 
-It is good to merge all branch changes up the waterfall to the top, so that you don't forget to apply a bugfix to a higher branch. In the process  of doing this, you close the branch heads on the way. So when you push new changesets onto a branch (aside from `default`), you should expect to be reminded to create a new head (`hg push -f`).
+(We've not thought of a use case that needs this, but there is a possibility that you want to make a change to a branch, which you don't want merged up the waterfall and wouldn't cause a conflict. If this should arise you can still merge upwards, but manually revert the change before committing it. But this would be against the grain of this waterfall model and if this becomes frequent, this policy should be reconsidered.)
 
 If you merge bug fixes the wrong way (i.e. down the waterfall), you may well end up with unstable changesets merged as well as the bugfix! If you find you have fixed a bug on a higher branch than necessary and want to have the bugfix on a lower branch, then you need to 'transplant' the changeset, rather than 'merge'.