0

We have a pretty big app we are moving from 7 to 8. The initial idea we had was to    Initial Gameplan: 1. make a branch on 7 (move_to_8_branch) 2. update the branch to 8 3. get it to a working state 4. update mainline to 8 5. merge (move_to_8_branch) into mainline.   However I have been testing proof of concepts in very simple apps where I essentially do the same thing and have been running into problems with those merges.   Example Proof of concept I did of the original plan: 1. Make an app on 7. 2. add a few modules 3. make the move_to_8_branch 4. updte to 8 in move_to_8_branch and only update modules. no other changes 5. update mainline to 8 6. merge mainline and move_to_8   Issues with it and why I am thinking it would be better to just update mainline.   duplicate modules java files with duplicate code from each version in the same file. atlas ui was updated in the branch and working, but even if I just accepted the branches module(atlas ui had duplicate modules after merge) I still had to redownload the same atlas_ui module to resolve the countless ui parameter errors. Even this fairly simple example has many issues with the merge. I used tortoise svn’s resolve conflict feature, but what I probably should have done was actually make sure each change was taking the branch’s change as the source of truth, and ideally removing the old stuff. I know how to do that with git easily, I’m sure there is an easy way in svn/tortoise as well.   So my main question is: Would it be better to just update mainline to 8, instead of first making a branch off of 7 and updating that to 8, and then updating mainline to 8 afterwards and trying to merge that in?   I feel like merges would be much simpler if we branched off of 8, not 7. Thoughts? Thanks in advance.

asked 2023-10-06

1 answers