When creating a clone of a bug, I would like duplicate-of and has-duplicate to be options in the relationship drop-down. I assume that their omission from the drop-down is by design. Here is my use case for this change:

I have imported changes from a subversion repository into a mantis database. The subversion repository itself was imported from a somewhat immature cvs repository. The change logs in the svn repository are not reliable enough for all the bug summaries simply to be set to the log entry for the corresponding change. Thus my summaries are svn r(nnn) - r(nnnn + 1), e.g. svn r7-r8. When I imported the changes, I added a file to the mantis database that was a patch of the changes from one repository revision to the next.

I have hundreds of these changes that I am processing manually because I need to merge development and production branches in the repository, but unfortunately there previously was no tracking of what changes took place in development vs. production branches. Thus I have to process all these changes to ensure there are no regressions (in either branch) during the merge.

In doing this, I realized that it is really nice to have separate bugs for the repository changes and for the actual bugs because sometimes bugs are recurrent, e.g. simple validation oversights like making certain a variable is set before using it. It is true that I could simply list in the notes all the repository changes that occur to fix a recurring bug, but notes obviously do not store information on relationships. It is obviously convenient to have relationship information stored by mantis because then I can simply click from a particular repository change to the bug discussion and then click to any other repository change for the same bug.

I could simply select related-to, but has-duplicate is actually the best description of the relationship between a bug and the corresponding repository change related to its fix. Furthermore, it would be convenient to clone bugs as duplicates as their resolutions are committed to the svn repository to continue tracking the relationship between repository changes and bugfixes in the future. It of course will make sense to record the bug_id in the repository as bugs are resolved, but that is a one-way map from repository changes to bugs, whereas the appropriate place to store the complementary map is in mantis, so storing repository revision ids in mantis is appropriate anyway.

I will be making this change to my local copy of mantis-0.19.2 regardless of whether or not others want this. Unless a mantis developer adds notes explaining why this change should not take place, I will submit a patch for this change.