Trac Migration ticket numbers vs. global Issue numbers
During the migration of multiple trac projects i have observed the following problem. After migrated the first trac project (e.g. with ticket numbers from 1..20) everything is ok, but with the second trac project (with ticket numbers from 1..20 as well) the ticket numbers from the second trac project will be incremented by the number of tickets of the first migrated project. This is based on the global issue numbers in Redmine.
The problem with this is if the revision Log messages will used to make a reference to a particular ticket number like this...
- Fixed #12 - ....
The Ticket #12 relates to a particular revision of the second migrated project. So if you use now the repository browser you will be navigated to the first project instead to the second project....In the repository browser of the second project you will be navigated to the first project as well.
The solution can be a very complex task.
- Add a new supplemental field during the migration and store the original ticket number into it, but this will make the referencing feature from the repository browser unusable.
- Create a script which fixes the log message, but this will work only in Subversion and is not a simple job.
- Use an issue counter on a project based instead of a global base (This might have many other issues).
Updated by Mathias Kühn over 14 years ago
The only thing that i could think would work here is to have some sort of a 'namespace' prefix used when importing an old project. Like "Project A" having tickets #1 to #5 it would create projecta-1 to projecta-5 on the redmine side. I'm not sure if redmine could handle that.
In addition that would mean that the whole interpretation of commit messages would need to be refactored to be directing to the right (new) ticket.
We'll be facing the same problem if we're moving to redmine. Currently we're evaluating the system and import from trac is also a big bullet on our list.