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.
Bug
Minor