[Meta] Chiliproject- and Redmine-"associated revision"s mixed up (Bug #1022)

Mmh, this is an unintended side-effect of migrating chiliproject.org to a new host: we had to re-import the repository, and the import created those connections (they weren't there before because issue #998 didn't exist when the revision had first been imported).

Sadly, the import procedure has no way of differentiating #998 from Redmine times from #998 from the current ChiliProject times. If this is an annoyance to you I might be able to go through the DB and delete the unnecessary link, but that's nothing we can solve programmatically I fear.

That way, the problem would be resolved for but just the one issue. But as I understand, it will happen to all issues with

• numbers < number of highest redmine ticket referenced at migration date

so the associtated revision part is either to be read very carefully (one stumbles over "closes #xxx" and thinks its done)
or useless when a multitude of references from Redmine and Chiliproject exist.

Isn't it programmatically easily possible (not hardcoded into repository, maybe a plugin only for www.chiliproject.org itself)
to filter those references out whose date are from before the Chili-issues even existed?

Alim Özdemir wrote:

Isn't it programmatically easily possible (not hardcoded into repository, maybe a plugin only for www.chiliproject.org itself)
to filter those references out whose date are from before the Chili-issues even existed?

Probably, is it worth the effort though? I don't expect chiliproject.org to move again in the foreseeable future, and the reimport was also done to get rid of the "GitHub Merge Button" commits.

The "commit younger than fork date" is a good indicator to sift through the commit to issue connections though, I'll try to see if any more have been created. Regarding any issue having been closed by error by that: there are no closing keywords configured on this site, so a commit should never close an issue, and the activity doesn't show any either, so there shouldn't be any.

It should also be possible to skip over any of the problem issue IDs going forward. For instance:

ALTER TABLE users AUTO_INCREMENT = 7734;

However, if any redmine commits are merged in the future the problem would present itself again.

For the example above, I took the v1.1.0 tag's creation date (2011-02-27) and found the last redmine issue that was created on that day. I would have searched the commit history more thoroughly but I don't have a local clone of the repo on this machine; and again, this isn't 100% future proof.

• differentiate at the matching of revision to issue, according to "ignore if revision before issue". After the mentioned points of you obviously flawed for:
  • long time open issues at Redmine, reopened ones, ...
  • when Chiliproject current issue numbers reach Redmines
• use a plugin to suppress showing of associated revisions where the source is Redmine. Felix pointed out the source is not deductable after import.
• modify the issue-tags when importing from Redmine, like #998(Redmine) written together so the unmodified matcher wouldn't connect it to Chilis. I've no idea
  what import is used, whether it's modifiable, ...

I didn't want to fuss about it, since it's not an issue in my installation. I just thought it to be rather irritating.