Ive recently begun working on a legacy codebase, in an environment where SVN 1.5.5 is used as the repository. The development team here has had enough difficulties with the mechanics of SVN branching that it has been abandoned. Id like to maintain the practice of branching when appropriate, and have run into some difficulties that I have never experienced using SVN before.
When merging trunk into a branch, we find many tens of files that have not been changed are listed as modified, and they tend to conflict heavily. SVN displays the conficts as portions of the file intermingled with itself. Since no one has actually edited these files, its easy to pick the correct version, and move on, but this still leaves developers with an insecure feeling about the process. Then, when merging the branch back into trunk, the same set of files that no one edited will conflict. This is in addition to other annoying conflicts that the svn merge algorithm is notorious for creating when files are legitimately edited in one or both branch or trunk.
We typically branch and merge back in as is done in this guide. However, there are 12-15 people on the development team which would interact directly with the repository, and I cant guarantee everyone follows "best practices" 100% of the time. There also have been many other developers on this project over the last 8+ years.
We also see a lot of conflicts on svn mergeinfo on files that no one has edited. Every time this happens, its a completely different set of files, but its guaranteed to happen anytime branching is involved. The longer the time has passed since the branch was created, the more mystery conflicts that result.
Sometimes these many conflicted but not edited files are predictable with the "--dry-run" option. Sometimes, using "--dry-run" wont display any unexpected conflicts, but then running the same merge command ends up conflicting around 45 files that had no changes.
If I run 'svn propget svn:mergeinfo' at the root of my trunk, I get a big list of branchnames and the revision numbers they cover, such as:
/branches/5###_active_feature:27629-27780
/branches/7###_auto_friend_feature:43686-43693
/branches/7###_mobile_navigation:45430-45690
/branches/8###_tracking:44442-44719
/branches/9###_video_module:45388-45418
/branches/9###_episode_guide:45233-45287
...
/branches/11###_redesign:28289-28395,46973-48171
54 lines like that, total. Is that an expected output of propget mergeinfo - just a list of branches?
Im at the point where I believe something is broken, and that this cant be an expected consequence of branching/merging in a seemingly default way. I used SVN For over a year from 2007-08, and never had problems of this magnitude. However, Im not so sure where to start looking for a resolution. Some colleagues and I have considered the following:
Our svn version (1.5.5) is bugged. We need to upgrade, which may require fighting some bureaucracy but shouldnt be too painful.
at some point int he history of the repository, svn mergeinfo was corrupted, or manually edited in some way. is there a way to check this? is there a way to resolve it if so?
at some point in the history of the repository, it became "corrupted" in some way. not sure how to proceed here.
Has anyone else experienced similar problems? How can this be fixed such that files that arent modified dont list as conflicted, and my team can continue using branches again without worrying about clobbering random things in the codebase?
(For the record, there is a long term project to switch over to git. Unfortunately, were stuck with SVN for the time being.)
/trunkis OK - they just merged a lot of branches during time