On Tue, May 10, 2011 at 6:21 PM, Julien Rioux <jri...@physics.utoronto.ca>wrote:
> On 10/05/2011 12:10 PM, Richard Heck wrote: > >> On 05/10/2011 11:37 AM, Stephan Witt wrote: >> >>> Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn: >>> >>>> There are >>>> plenty of cases where a bug gets fixed in trunk first, and then we wait >>>> to commit to branch until we see how that goes. >>>> >>>> In the development model I propose, we fix a bug in a topic branch. >>>> This branch will regularly be merged into a >>>> testing branch which is comparable to the current svn trunk. When a >>>> feature is cooked, tested, or if we have seen how it goes, the feature >>>> will be merged either into master (a sort of stable trunk) or it will be >>>> merged into BRANCH_2_0_X. All fixes that are merged into >>>> BRANCH_2_0_X will of course get merged into the stable trunk >>>> as well when BRANCH_2_0_X get merged into master. >>>> >>> So, if a bug is attacked in a branch and this lasts a while you need to >>> remerge >>> the BRANCH_2_0_X regularly into your bug fixing branch(es), right? >>> >>> Yes, or probably better: rebase against BRANCH_2_0_X. That merges and >> then records all your changes to branch as "most recent" commits. >> Merging alone makes the more recent commits to BRANCH_2_0_X look later >> than your changes. I.e., merging gives you a commit history like: >> BRANCH Tuesday --> bug fixing --> BRANCH Wednesday --> BRANCH >> Thursday >> whereas rebasing gives you: >> BRANCH Tuesday--> BRANCH Wednesday --> BRANCH Thursday --> bug >> fixing >> Getting used to that kind of difference is one of the things involved in >> getting used to git. >> >> Richard >> >> >> > That's the best explanation of it that I have read. Though I'm not convinced it is entirely correct. > So rebasing is similar to svn up in our case. No. > If you do it often enough I guess you could catch the potential for > merge conflicts early rather than late. Sort of... leaving your code unattended will lead to merge conflicts (of course). > Except that because we would be using feature branches, the change > from BRANCH Wednesday --> BRANCH Thursday might include a largish > marge from a feature branch which involves large merge conflicts. Not really. Developers should follow the development-trunk branch which is composed of trunk-stable(master) and all feature branches. You should regularly update the development-trunk branch. As long as your own unpublished feature merges nicely into this branch, there is no problem. If you have a published feature, it will already be in the development-trunk. If a merge conflict happens there, it will be the responsibility of the person of the newest feature to either base it on your feature, or fight over who did the right thing first. I guess I need so set up the system in practice soon to show how it will be working and to iron out the flaws. (Short on time now though). Vincent
