Peter B. West wrote:
<snip/>
Simon, yes! That's what branching is there for. People seem to be afraid of it, but it is an enormously useful tool for just such situations. I think it's always a good idea to tag the tree immediately before a branch.
Hi Peter,
its not that I am afraid of branches, they have their uses, but I feel the project is at the wrong stage in its development for another branch right now. Branches invariably mean splitting development focus. Right now I want to focus on fixing the High priority issues with layout so we can do a release. If we flail around for another year or so then FOP may be dead in the water as other projects overtake it.
Let's sketch a procedure for things like this. Someone proposes such a large patch again. We look at and realize that it can have a significant impact, but is worthwhile considering. The time frame for sorting it out might be anything from a week to a month or two.
Tag the tree. Let's call it paragraph_patch. Tell the person proposing the patch - let's say Luca for illustration - to build his patch again based on the paragraph_patch. Luca checks out the tree using that tag. When he has it in a state to be examined, he submits the patch, noting that his work is based on paragraph_patch. Those interested in testing the patch create a branch, say paragraph_test, at the tag-point, paragraph_patch, checkout paragraph_test, and apply the patch. Is there any problem in applying the patch? No, because everyone is working with known and common versions of the files. Is there any impact on ongoing commits to HEAD? No. The committers (and Luca) still have valid HEAD trees on their machines, still track and contribute to the ongoing HEAD development.
Let's say that Andreas commits some changes which affect Luca's work. Luca wants to merge them in. He asks for a merge. Impact on HEAD? Ask Andreas if his changes have settled down. Announce that the tree will be tagged at time X. Tag the tree; paragraph_merge_pt_1. That's it.
Meanwhile, Luca requests that the paragraph_test tree be tagged (before_merge_pt_1). Disruption to HEAD - none. He locally merges from paragraph_merge_pt_1 into paragraph_test, and starts to sort out the conflicts. When he is done, he prepares a new patch against paragraph_test, which he submits.
Committers who are tracking his work apply the patch to their copies of the paragraph_test tree. Disruption to HEAD - none. Patch errors - none. When the patch is ready to be applied to HEAD, the process of merging in from HEAD is repeated, relative to the last merge tag in HEAD. Committers announce that a merge into HEAD is pending, ask that commits to HEAD be suspended until this is done, and tag the HEAD tree; before_paragraph_merge. Luca merges locally into HEAD, and prepares a patch against HEAD, which he submits. This is committed and the HEAD tree tagged after_paragraph_merge. The paragraph_test branch is now defunct.
Note that this description covers the whole development cycle of a major, potentially disruptive patch, through to integration into HEAD.
Compare that to the dramas we have just been through (and are still going through - there seem to be two versions of HEAD out there on two committers' machines.) The responsibility for developing the patch rests primarily on the author and secondarily on the committers who perform testing and feedback. Had a procedure like this been in place, would the progress of Luca's patch have been more, less or equally disruptive?
Obviously such a procedure is only *necessary* in unusual cases, but it makes sense to know how it is done, and it even makes sense to practise doing it on short cycle changes, so that things flow smoothly when the big issues come along.
Just a suggestion.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
