I don't have experience in such big merges but... wouldn't be easier to do a diff between the original trunk revision which originated the branch and the branch, and then apply the diff to a new branch? Or it would generate too many rejects?
2010/8/1 Jason Wilkins <[email protected]>: > I had this problem earlier in the summer. > > What we did first was create a giant diff between the trunk and my branch. > > What I did then was go through with a copy of trunk and a copy of my branch > file by file. If I knew for sure I had not modified a file I copied the > exact file from trunk over the outdated one hanging around in my branch. > > If it was a file that I had modified then I carefully looked at it to make > sure that the only changes were my changes. In that case I could simply > keep my file, otherwise I had to update my file so that the parts I did not > change myself matched the trunk. > > Finally, I did another diff between the newly committed branch and the same > version of the trunk I started with (this will take long enough its bound to > be updated while you are fixing this, so make a note). > This new diff should only contain your changes and if so, you are done. > > In other words, I fixed it manually. It was time consuming but now I'm much > more careful about making sure my merges are correct :) > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
