Item9643: Tasks system: extend Checkins field to also indicate which branch(es) checkins were made

Priority:	CurrentState:	AppliesTo:	Component:	WaitingFor:
Enhancement	Closed	Web Site	Tasks

Probably with a new formfield, perhaps CheckinsOnBranches? .

The goal is to avoid a task like Item9591 ending up in the release notes for the wrong release.

It would enable a report that could show inconsistent TargetRelease field, Ie.:

• Current "patch" branch is (now) Release01x10, was Release01x00
• "minor/major" branch is (probably) usually trunk

When we prepare for a release, we could find all tasks that are CurrentState='WaitingForRelease' AND (TargetRelease='patch' AND NOT CheckinsOnBranches? ~'*Release01x10*')

-- PaulHarvey - 08 Sep 2010

I've got a change ready to go for this task - waiting for some feedback first,

Adds a META entry to the ItemTemplate - CheckinsOnBranches. It gets the branch info from the commit message using `svnlook  dirs-changed -r $commit` and parses it as

• ^trunk or
• ^branches/(.*?)/

when first adding the information, it goes back in history for each commit logged to the item and adds the branches. So Item10188 for example would end up with ...CheckinsOnBranches" value="Release01x01 scratch trunk"}%

It does not record which commits are in which branch - which would also be nice to know somehow. -- GeorgeClark - 02 Nov 2011

I wanted to implement this, and I must have some code in some git branch somewhere on my disk... it wasn't exactly the same purpose, my idea was more to show in the Checkins list which branch they belonged to. I gave up as it was a mess to implement.

If you have some way to do it, I'd say: go for it

-- OlivierRaginel - 02 Nov 2011

yes, trying to list checkins by branch is more difficult. If we could have the field name in the Metadata be release name, that might be relatively easy to implement. TrunkCheckins? Release01x01Checkins? . And when we branch we add a new field. Other than populating the Checkins field for our reference, is there any other use where we would still need a common Checkins field? Or the post-commit could remove Checkins field and replace it with a field for each branch found in the commits.

Actually that would be very easy. I already have the code to find the branch for each commit in Checkins. Easy enough to return a list of Branch: (Checkins list) and create the new metadata.

-- GeorgeClark - 03 Nov 2011

I have a new version - not implemented, in my home account on foswiki.org. It maintains Checkins, but also adds 2 (or more) fields to Meta: Here is what is generated for Item11209

% META:FIELD{name="CheckinsOnBranches" attributes="" title="CheckinsOnBranches" value="Release01x01 trunk"}%
% META:FIELD{name="Release01x01Checkins" attributes="" title="Release01x01 Checkins" value="Foswikirev:12900 Foswikirev:12904 Foswikirev:12905 Foswikirev:12915 Foswikirev:12998"}%
% META:FIELD{name="trunkCheckins" attributes="" title="trunk Checkins" value="Foswikirev:12901 Foswikirev:12902 Foswikirev:12906 Foswikirev:12997"}%

The new fields won't be visible unless they are added to the ItemTemplate topic.

-- GeorgeClark - 04 Nov 2011

Looks great!

-- OlivierRaginel - 04 Nov 2011

The exit is installed, and I've added trunkCheckins and Release01x01Checkins? fields to the ItemTemplate. I did not add the CheckinsOnBranches? field. The meta field gets created, but is also the trigger as to whether or not the exit should update all the old commits. So I didn't want it being added as an empty field on new tasks. Need to think about that logic a bit.

-- GeorgeClark - 04 Nov 2011