Redmine

Hi Ed, because of current architecture it's almost impossible. Whole system is build around unique issue numbers, so this can't be implementented in easy way. Anyway, I believe this architecture has much more better behaviour than other systems, where you can have independent issue numbering. For example, now you can very easily change issue to bug, move issues between trackers and event projects, link to issues, create global reports not connected to one project etc. The main gole is, that issue number is unique and remains still same, which can act as primary key...

I hope I explained a bit some reasons why not to do it as you like ;)

It's a common request I've heard from anyone tracking different things.
but just thing of the following scenario: You use a tool for tracking your actions and an other one for your issues. After a long time, you've closed many of them, but not in a consecutive manner (just look at the open issues for Redmine, the numbers are not consecutive). My point is that after some use, you'll stay with a list of open issues and open actions where the numbers are not consecutive, so why is it so important to start specific numbering for each kind of item you want to track ? I was earlier on the same position than you, but I think it is not that critical to have a shared numbering, whatever the issue kind.

cheers
gabriel

Another point of view...

• project manager: "Hey dude, you f****d it completely up! Fix #2163 just now, and SMS be back!"
• developer: "uh, soory,I'll fix it..."

• project manager: "Hey dude, you f****d it completely up! Fix #116 just now, and SMS be back!"
• developer: "It makes no sense, #116 is already fixed for two months!"
• project manager: "Are you looking into project XYZ?"*
• developer: "Ssry, I'm in OPQ..., now I got it. But again, it's not exactly what you talking about..."
• project manager: "Are you looking in Bugs or Issues tracker?"
• developer: "Bugs..."
• project manager: "Huh, doesn't make sense to me... Arrrrgh, I got it, it was #116 in Issues tracker, but we moved it into Bufs tracker, so now it's #216"
  ...

IMHO, the first screnario looks better to me ;)

And you can move issues from 'bug' to 'feature' trackers. What happens to the number then as there will probably be a collision at some point. Does it get a new number assigned?

You'd also loose the ability to just enter '#1' in the search box and jump to issue one, because you'd need to know the tracker trype and then enter 'feature:#1' or something which isn't as usable. And as a project manager and/or developer. I'd rather have a system that is easier to navigate which I think we have at the moment.

Cheers

Russell

Good points all! The way you have it set up makes a lot of sense.
Thanks for the help!
-Ed

I just remembered, part of the reason I wanted to do this was that I'm migrating from another system, where each project had bug numbers starting at #1, and I really want to preserve the old bug numbers into the new system. I've posted a question to the help forum, on how to set up one database per project, since that looks like the only way to do this. I'd prefer not to run multiple redmines to have multiple databases, but will if I have to. Is it possible to have one redmine with multiple projects, each using its own database?
Thanks again,
Ed

Is it possible to have one redmine with multiple projects, each using its own database?

Not that I know of. It would be extremely hard and would be a massive code change, if it was possible at all. Redmine (and Rails) are built around the assumption of having one database.

I would suggest just letting Redmine number your bugs and have a custom data field to store the old bug numbers.

Eric