ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

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


Added by Alim Özdemir at 2012-05-29 02:14 pm. Updated at 2012-05-30 10:43 am.


Status:Open Start date:2012-05-29
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Remote issue URL: Affected version:

Description

In the tickets here at https://www.chiliproject.org the displayed "associated revision" seems to equally
take Redmine and Chiliproject into account.
I can see the motivation behind this, but the references are recognized by used issue no., which leads to
misconnecting redmine-revisions with chili-issues and vice versa.

Example: #998 and associated revision


History

Updated by Felix Schäfer at 2012-05-29 03:50 pm

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.

Updated by Alim Özdemir at 2012-05-29 04:28 pm

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?

Updated by Felix Schäfer at 2012-05-30 12:05 am

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.

Updated by Justin Geibel at 2012-05-30 04:19 am

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.

Updated by Alim Özdemir at 2012-05-30 10:43 am

In my naive way I'd thought, either:
  • 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.

Also available in: Atom PDF