I wouldn't use this feature myself but as long as it has an option to disable it I'm happy.

A commit is called a Changeset in Redmine and the code that looks for issue ids in the commit message in scan_comment_for_issue_ids in http://www.redmine.org/repositories/entry/redmine/trunk/app/models/changeset.rb

I think we could do without a disable option, if the syntax is strict enough.

Anyways, is there a settings api or "the" way to add settings?

Thanks for your quick reply. I will look into it next week.

Jonas von Andrian wrote:

I think we could do without a disable option, if the syntax is strict enough.

Maybe. I like how the repository settings ones allow someone to enter the syntax.

Anyways, is there a settings api or "the" way to add settings?

No, you will have to just add the fields to the settings page. That parts easy to do.

Sorry, but this isn't working on my server.
I will have to look into it further

I finally had some time to apply this to recent trunk (r1900) and test it to see if it's usable for me. Here a few comments/notes:

At first I must say that IMHO this patch realyl rocks. After using Redmine together with SVN for awhile now I found it un-handy to log time on an issue which had been auto-closed (in my workflow resolved) by an SCM-commit. This patch provides me an option to include the spent-time immediately on the commit-message.

I will later test this on my private vendor-branch with the start-/end-time tracking patch applied to see if it can exist (not work!) together without conflicting eatchother.

1. this patch expects the order of the parts of the commit-message to be:

   refs #1
   time 3,4
   ratio 40
   
   comment for this ticket

   #2 #if you specified * as the ref keyword
   time 30 m
   ratio 30%
   
   comment for second ticket

   to fully work with the patch (especially the timelog-comment).
   p.
   Because of the fact that I'm trying to keep the revision-log as tight and readable as possible I definately want to start (at least the first line) the commit-message with the same line which should be used as the timelog-comment. Then (optional) a more detailed description of the commit, followed by a block of keywords+values.
   It would be great if the commit-message can be made-up like:

   comment for this ticket
   
   refs #1
   time 3,4
   ratio 40
   

   comment for second ticket
   
   #2 #if you specified * as the ref keyword
   time 30 m
   ratio 30%
   

   without screwing-up the timelog-comment (i've tested the alternative order already and it came out not-working).
2. when only time is logged using the commit-message without changing the done-ratio no journal-message should be added to the issue. Currently the patch writes a blank journal only displaying the resolved :text_status_changed_by_changeset (Applied in changeset rxxx).
   IMHO a journal-message should be added only when the done-ratio is changed.

Oh, I forgot a third (more important) sidenote:

When multiple issues are referenced, the keyword:value-changes are only applied to the latest referenced issue. They are completely ignored on the first referenced issue (when referencing two issues in total).

• time should be equally distributed (thus with two referenced issues "time 1" in commit-message should be distributed into 0.5 per issue)
• done-ratio should be applied according to the keyword-value for all referenced issues the same (thus with two referenced issues "ratio 30%" in commit-message should set done-ratio to 30% on both issues

And a little addition on my first sidenote:

This could be solved by adding a new keyword log like you've proposed in the initial issue description. Then the whole block can be appended to the commit-message instead of requireing it to be prepended.
I'll look into this in the upcoming weeks. If I have 'something' I'll post it here...

Now... I again, forgot one point:

It would be a good thing to add a setting for the timelog activity-type so it becomes configurable which activity-type is used for timelogs added through a commit-message.

This could be implemented by modifying the activity_id-method in ../app/models/changeset.rb. I'll look into it and post any results... ;)

I'm really interested in this patch - will try to apply it tomorrow for some testing! However, Mischa The Evil's comments show it's not quite 'there' ... (still great work!)

Perhaps the time, ratio and (later) activity type values in the commit log could be tokenised somehow, in much the same way that 'references' and 'closes' links are currently implemented. This way, the values could be entered anywhere in the text and still be understood by the parser. Perhaps the issue references could be 'piggy-backed' which would ensure time, ratio and activity values are associated with the correct issue when > 1 issues are referenced.

For example,

- Fixes nasty crash in background thread - fixes #121 {1.30:50%:Bugfixing}
- Looked at how enhancement #544 {0.30:10%:Planning} should be implemented

... or something similar. Of course, the timelog block {...} would not be included in the log's text. The parser's logic would be something like:

• Have I found an issue reference? Yes.
• Is there a {...} block after it? Yes.
• Look at the content inside the {...} block and attempt to split it into parts by the : delimiter
• Look at each part - can I parse it as a time (e.g. 1.30 or 1,30 or 1.5) or can I parse it as an integer between 0 and 100 or is it a text string?
• Apply found attributes to the timelog.

Of course, there's much to consider regarding the choice of attribute delimiter (a colon in my examples) and the block delimiter (curly-braces in my example). Straight away, it's clear that some cultures/users would want to use : as the HH:MM delimiter. Then there's the fact that mainland Europe tends to use , as the decimal separator, whilst the UK and USA use a full-stop (period). Finally, I'm sure some C programmers would take issue with using { and } :)

Perhaps this could be a configuration setting in the same way that the issue reference/closes tokens are set?

Oh, and one last thing - I'm unsure how the times are expressed in these examples. Am I right in thinking the ',' is being used as a decimal separator (I'm in the UK). In that case, what's the convention for how the second part of the figure is used? For example, is 1,5 1 and a half hours, or is it 1 hour, 50 minutes? Might I suggest that whilst 1.5 = 1hr 30mins might be fine for us, less technical users might want to express time in the 'natural' style of 1.30 or 1:30 -- or even 1h30.

Regards,
Chris

Heh - spot the deliberate mistake :) The first example shows a bug being closed, yet it also specified 50% as the progress. In reality, the 'fixes' marker might, depending on the Redmine configuration automatically set the issue to 100%. So, the example should read something like:

- Fixes nasty crash in background thread - fixes #121 {1.30:Bugfixing}

The parser would see that no percentage has been specified, but still picks up the time and activity type. :)

Chris Platts wrote:

Perhaps the time, ratio and (later) activity type values in the commit log could be tokenised somehow

This looks a good option to me. Though I guess it will require more changes in the code.

For now I've modified the patch to solve my issues. See above... :-)

For example, is 1,5 1 and a half hours, or is it 1 hour, 50 minutes?

1.5 equals 1 and a half hours. This is default Redmine behaviour. See here: http://www.redmine.org/wiki/redmine/Time_tracking
Note though that the time-formats accepted by this patch are limited to All except 12 hours and 30 min(utes).

Thank you Mischa for your great Input and your extended Patch. Especially your work on the journal seems useful.

In about a week I will have time to work on it again and look at your changes in detail. It looks like you finished what I started out to do. 2 months in India and voila, my work is finished.

I'm not sure I like the tokenising Idea though. Seems a bit too condensed for my taste.

Hi, Mischa.

Can you update your patches for 0.8rc1 or recent trunk version?
Thanks a lot.

Thank you for your quick response.
I think new patch have to include any changes after last patches was out.

I've tested it.
It works well.
All my company developers will use this features after my announcement.
Next week, I will post a more detailed result.

Jean-Philippe: Would it be possible to schedule this feature for the 0.9-release? I'd really like to see this is the Core and since it can be turned-off (which is actually the default state) in the current implementation I don't see much obstacles for it...
I don't see how a feature like this can be implemented useing a plugin to keep it out of the core but that could be my innocence and inexperienceness...

What's your expert-opinion on this?

This is a requested feature that could be added in 0.9 indeed.
But this patch seems to do more than allowing time log via commit message.
It breaks a few tests too.

Jean-Philippe: at first my apologies for my slow response to your comment... It's been tough to keep up with the quick development of Redmine... :)

Jean-Philippe Lang wrote:

But this patch seems to do more than allowing time log via commit message.

Indeed, additionally to the timelog creation via the use of the timelog-keyword in a commit message it also provides a way to change a issues done-ratio using a dedicated done-ratio keyword.

• added default timelog-comment setting if time is added in commit-message but timelog-comment is missing (blank [default] or changeset-ID)
• added default timelog activity-type setting
• changed issue-journal creation behaviour in commit-message processing; now a journal is only created when:

  [core] an issue is fixed using fixing-keywords (thus status (AND possibly done-ratio) is changed)
      OR
  [ext]  advanced commit parsing is active AND
             issue is not fixed using core fixing-keywords AND
             issue-ratio is changed explicitally in commit-message using ratio-keyword (this requires ref-keyword to be configured explicitally)
      OR
  [ext]  advanced commit parsing is active AND
             issue is not fixed using core fixing-keywords AND
             * is configured as reference-keyword AND
             issue-ratio is changed explicitally in commit-message using ratio-keyword

• changed used issue-journal content when only an issue's done-ratio is changed using ratio-keyword in commit-message;
  • when only an issue's done-ratio is changed: "Partially applied in rxxx"
  • when an issue is fixed using fixing-keywords: "Applied in rxxx"

Jean-Philippe Lang wrote:

It breaks a few tests too.

Indeed, you can see my initial notes about them here which I've explained further in this issue-journal.
Jonas? Can you maybe take a look at them too?

HTH...

+1

patching fails on the repositories.rb against the 0.8.4 stable, anyone able to give me a hand on it, I've just finished writing a tortoisesvn plugin so I can feed back hours during the commit with a nice ui, now I just need to get this bit working, I had it wworking with a source build of remine from a few months ago but other things in that build made it unusable.

by the way if anyone is interested in the tortoisesvn plugin then I'll upload the source somewhere for you all.

Ken Sands wrote:

patching fails on the repositories.rb against the 0.8.4 stable

The last version of the patch (logtime_changeratio_via_commit-message_extended-r2118-Alpha.diff) should be compatible with Redmine 0.8.x (including release 0.8.4). I haven't patched the file repositories.rb neither. Are you sure this isn't a typo and were you actually meaning the file _repositories.rhtml (the view-template)?

Please let me know since I want to maintain this patch for 0.8.x at least (untill I have ported it to current trunk also).

Ken Sands wrote:

by the way if anyone is interested in the tortoisesvn plugin then I'll upload the source somewhere for you all.

Is that something like the one already mentioned at ThirdPartyTools?

Kind regards,

Mischa.

The last version of the patch (logtime_changeratio_via_commit-message_extended-r2118-Alpha.diff) should be compatible with Redmine 0.8.x (including release 0.8.4).

I'll try it again, I was probably making a mistake

Is that something like the one already mentioned at ThirdPartyTools?

yes, pretty much, but I've included a box for entering the time spent and a dropdown for percentage complete, plus it filters the possible issues down to those associated with the repository you are commiting to. I'll tidy up the code and put it up as another entry on that page, could be helpful for some.

The last version of the patch (logtime_changeratio_via_commit-message_extended-r2118-Alpha.diff) should be compatible with Redmine 0.8.x (including release 0.8.4). I haven't patched the file repositories.rb neither. Are you sure this isn't a typo and were you actually meaning the file _repositories.rhtml (the view-template)?

the following is in that diff, it's where it failed for me, but I'll do some testing and make sure it's not becuase I had other patches there already.

Index: app/models/repository.rb ===================================================================
--- app/models/repository.rb (revision 2118)
+++ app/models/repository.rb (working copy)
@ -92,10 +92,6 @
@latest_changeset ||= changesets.find(:first)
end

- def scan_changesets_for_issue_ids
- self.changesets.each(&:scan_comment_for_issue_ids)
- end
- # Returns an array of committers usernames and associated user_id
def committers
committers ||= Changeset.connection.select_rows("SELECT DISTINCT committer, user_id FROM #{Changeset.table_name} WHERE repository_id = #{id}")
@ -142,11 +138,6 @@
find(:all).each(&:fetch_changesets)
end

- # scan changeset comments to find related and fixed issues for all repositories
- def self.scan_changesets_for_issue_ids
- find(:all).each(&:scan_changesets_for_issue_ids)
- end
-
def self.scm_name
'Abstract'
end

People interested in this feature should have a look at #4155.
I'll wait for some feedback before choosing one of the syntax for time logging via commit message.

Jean-Philippe Lang wrote:

People interested in this feature should have a look at #4155.
I'll wait for some feedback before choosing one of the syntax for time logging via commit message.

I definitely prefer the syntax of #4155. It's clearer and doesn't try to do too much (at least for my purposes - of course others will disagree!).

Unfortunately, I can't get either this patch or #4155 to apply cleanly to the latest trunk revision I'm running, so it's all a bit hypothetical at the moment :)

• Issue: http://retrospectiva.org/tickets/86
• SCM-URL: http://retrospectiva.googlecode.com/svn/extensions/1-1/scm_ticket_update

Mischa The Evil wrote:

Just to temporarily drop the thing I came around which might be interesting in this perspective. It shows how related issues are partially solved in Retrospectiva.

• Issue: http://retrospectiva.org/tickets/86
• SCM-URL: http://retrospectiva.googlecode.com/svn/extensions/1-1/scm_ticket_update

Is there any way to make it works in latest Redmine (1.2.1)? I think it's extremely useful feature.

Chris Platts wrote:

Jean-Philippe Lang wrote:

People interested in this feature should have a look at #4155.
I'll wait for some feedback before choosing one of the syntax for time logging via commit message.

I definitely prefer the syntax of #4155. It's clearer and doesn't try to do too much (at least for my purposes - of course others will disagree!).

Unfortunately, I can't get either this patch or #4155 to apply cleanly to the latest trunk revision I'm running, so it's all a bit hypothetical at the moment :)

Is there any way to make it works in latest Redmine (1.2.1)? I think it's extremely useful feature.

Ps. I've quoted wrong post :P