If we merge a change to a path from that path's own natural history the merge tracking logic prevents the merge from being repeated. However, mergeinfo is recorded and this mergeinfo is redundant . This cause of this bug has existed for a long time, it is only with the recent change to make no-op merges set mergeinfo (see issue #2883) that it has (re?)surfaced. For example: >svn info src-trunk Path: src-trunk URL: http://svn.collab.net/repos/svn/trunk Repository Root: http://svn.collab.net/repos/svn Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a Revision: 30214 Node Kind: directory Schedule: normal Last Changed Author: cmpilato Last Changed Rev: 30212 Last Changed Date: 2008-04-03 09:43:47 -0400 (Thu, 03 Apr 2008) >svn pg svn:mergeinfo src-trunk /branches/svn-mergeinfo-enhancements:30122 >svn merge http://svn.collab.net/repos/svn/trunk src-trunk -c25549 >svn st -q src-trunk M src-trunk >svn diff src-trunk Property changes on: src-trunk ___________________________________________________________________ Modified: svn:mergeinfo Merged /trunk:r25549 >svn pg svn:mergeinfo src-trunk /branches/svn-mergeinfo-enhancements:30122 /trunk:25549 This self-referential mergeinfo isn't harmful as it's semantically correct. It is however potentially confusing to users as discussed in these threads: http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=134491 http://subversion.tigris.org/servlets/ReadMsg?listName=svn&msgNo=34322 As the second thread discusses, common cyclic merges could introduce self-referential mergeinfo, but that was fixed in r29085. This case is likely to be a lot less common however. It won't happen during merges where no revision range is specified, it will only happen if you specifically ask to merge a range from a paths own history. But a not-so-unusual use case is when re-mergeing a change from a path's own history that was previously reverse-merged.