Reputation: 511
I have a branch than I want to merge to trunk.
First of all I merge trunk into the branch, to have it updated.
After that I update trunk (locally) also to have it with the last changes.
Next step is to merge branch into trunk.
When I see files that have changed in my local trunk (before commit) I see that I have files from my project but also files that are not from my project.
Probably those files come from a bad merge from trunk to the branch.
What is the best option right now? Merge all files from the first revision of trunk to the branch(when the branch was created) ? I think I will get a lot of conflicts this way. Create a new branch from trunk and put in this branch files from my project? This means doing again testing.
Any ideas?
thanks for your time
Edit: only commit files of my project could be the best/fastest solution ?? (90 files to commit only 45 files are from my project)
Upvotes: 2
Views: 295
Reputation: 107090
Those files that have been changed, are the content of the files modified, or is their property values modified?
Whenever I hear of someone telling me that a merge changed too many files, I find the problem is usually with the svn:mergeinfo
property. Subversion tracks merges by setting this property. If you always do merging at the root of the project, only the root directory will have this property set, and all files will share it. If you do individual file merges, all of these files will have a svn:mergeinfo
property set, and every time you do a merge, each of those files will be modified since the svn:mergeinfo
file on all of these files also must be modified.
Whatever you do, don't revert those files in order to eliminate the merge. That simply makes things worse. The svn:mergeinfo
will show those files haven't been merged for those revisions, and the next time you do a merge, Subversion will redo the merge, and update the svn:mergeinfo
once again.
Upvotes: 2