Apache Allura™

Originally by: *anonymous

Why not just initialize the new numbering with N+1, N being the last of the old system ?
You would have had perfect continuity, without any redirects nor concern about their lifetime, zero hassle.

Originally by: ferrieux

Apologies for posting anonymously. That was me.

In the new system, we decided it would be best to have individual unique numbers per tracker instance, not sitewide. Then most projects have small numbers since they start at 1, rather than very big numbers like 3484452

• labels: support, p3 --> support, p3, 42cc
• Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,7 @@
+**Implementation:** We should index ticket's `import_id` in solr (put it in the `index()` method) so it is searchable.  Also make URLs like /myproject/tickets/N when a regular ticket isn't found then fall back to check import_id.  If a ticket is found by import_id, do a permanent redirect to the real url for that ticket.
+
+----
+
 [forge:site-support:#623]

 >Issue numbers from the sourceforge bug tracking system prior to migration did not migrate in project upgrade, and description of upgrade consequences did not warn of this.

• milestone: limbo --> forge-backlog

Created #172: [#4968] Fall back to check ticket import_id when a ticket isn't found by it's regular id (1cp)

• status: open --> in-progress

Originally by: ferrieux

Yes, that's what you decided. But you may have overlooked the fact that old projects with a long history will suffer from this. As a mitigation, what about allowing each project to choose among the two scheme (reset or continuity) ? Note that in case of continuity, it means less work for you (no mapping/redirect to keep track of).

Closed #172. Branch 42cc_4968.

• status: in-progress --> code-review

Hrm, we currently store an import_id of "tracker/1/420" for example, when migrating from our classic system. This doesn't work out quite as well and will take some additional thinking

Originally by: jamesbassett

I'm stumped as to what to use for the bugtraq:url property in subversion now.

Before the upgrade I used http://sourceforge.net/support/tracker.php?aid=%BUGID%. This will still work for old commits (with the redirects in place) but not for any new commits.

If I update it to https://sourceforge.net/p/supercsv/bugs/%BUGID% that restricts me to only using it for bugs (not feature requests) as each tracker has it's own unique ids now.

And as soon as I change it to a new format, it will no longer work for old commits.

Originally by: thompsonbry

I'd like to vote on this as a critical issue. We also heavily use the revision number in tickets to link back into the source code. Is there a ticket for that?

• qa: Dave Brondsema

James, I will have to think about what to suggest for the issue of bugs being separate from feature-requests.

However, our current work on this ticket will mean that https://sourceforge.net/p/supercsv/bugs/%BUGID% will work for old ids. Hopefully that will be of some help when its live.

Bryan, that works already. Just put the revision number in brackets like [r123] for SVN or [139b73] for hg/git revs, and it'll be a link from the ticket/wiki/forum/wherever over to that revision.

• qa: Dave Brondsema --> Cory Johns

I already reviewed the initial commits. Please review forge-classic:db/4968 and the top commit on allura:db/4968

• size: --> 1

Originally by: ferrieux

Any hope to address the fundamentally wrong move for projects of long history ?
Again, allowing projects to migrate while restaring at their old max-bugid+1 instead of 1, would mean life instead of death to them. The alternative is to migrate out of SF for good.

Alexandre, I think there may be another alternative. Actually what we are working on implementing currently is making URLs with old ticket ids still work. E.g. /someproject/bugs/354325 would redirect to e.g. /someproject/bugs/17 Also searches with the old ticket id would find a match. Would that be sufficient to make the new numbering system workable for you and your projects? If not, what else would need to happen for converted ticket numbers to work well?

• summary: Project upgrade silently changes issue numbers [ss623] [ss637] --> Project upgrade silently changes issue numbers [ss623] [ss637] NEEDS INI

Forgot to mention for QA on this, need to add tickets.import_id_converter = sfx to production.ini

There are some older upgraded projects with import_id values of a different pattern; they can be updated with the following mongo (on project-data):

db.ticket.find({import_id: /func=detail/}, {import_id: 1}).forEach(function(t) {
    var import_id = t.import_id.replace(/.*group_id=([^&]*)&atid=(.*)/, 'tracker/$1/$2');
    db.ticket.update({_id: t._id}, {$set: {import_id: import_id}});
})

• status: code-review --> closed
• milestone: forge-backlog --> forge-oct-05