(Possible) bug in the way we track the mergeinfo property

Hi all,

I am in the process of writing a script which would check for the
mergeinfo of a path and see if the path is present through all the
revisions mentioned in the mergeinfo property. If the path was not found
for any revision range then the script would suggest(as of now) a better
way to propget the mergeinfo property or even propset the correct
mergeinfo property (not yet decided on this though).

In the process of testing the script against our "trunk" source I could
see some bogus mergeinfo properties when there is a break in the history.

Here is an example:

The mergeinfo for
http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
868291-873154
but if I do location_segments for this range of revision for the above
path, I get
r868291 - r872329: subversion/branches/tree-conflicts
r872330 - r872524: null
r872525 - r873154: subversion/branches/tree-conflicts

After looking at log -v, it was clear that the
"subversion/branches/tree-conflicts" was deleted and copied (i.e replaced).
Logically the branch "tree-conflicts" was not present at all at the
revision range r872330-872524.
This brings a breakage of history. But the mergeinfo is not clear enough
to show this change.

I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
(possible) bug is seen in all the three cases.

I have not yet filed any bug so far. Please share your thoughts.

--
Prabhu