Alex M
Alex M

Reputation: 511

Subversion: more files than expected when merging a branch to trunk

I have a branch than I want to merge to 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

Answers (1)

David W.
David W.

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

Related Questions