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.

Ref# directly in source

Added by Lars P at 2011-03-14 06:51 am

I experience quite often that it is forgotten to write the reference in the comment. (refs# XXX) when checking in the source. Maybe because we do not check-in our sources every day.
I was wondering about a feature where you could add the issue reference directly in the header of the source file. This way you have this fresh in mind when starting to code on an issue and thus create a new source file.

Good idea or bad idea?

/Lars


Replies (2)

RE: Ref# directly in source - Added by Lars P at 2011-03-17 05:51 am

I forgot to state the purpose.
This feature would mean that in issues we would be able to see the related sources, like this:
https://www.chiliproject.org/issues/267

So when we create a new C++ file, at that moment we know which issue this relates to

RE: Ref# directly in source - Added by Andy Bolstridge at 2011-04-11 03:24 pm

I doubt its possible in Red.. ChiliProject itself as the repository integration only fetches commit messages. So, to make something like this work, you'd be best off handling it in the SCM. (the alternative would be for CP to read every file you checkin)

You would have to parse the entire contents of every file that is checked in, finding the refs#xx text and then passing some information back to CP, probably via adding it to the commit message, or calling an API method in CP to add them to its DB.

I like the idea of putting the bug reference in the code, and parsing it out automatically. Is there an API to do this - add comments to issues from an external source? If so, and can be called from cURL, then a perl pre-commit hook would be very easy to implement (in Subversion at least).

(1-2/2)