Including Original Changeset CreateDate in comment for migrated changesets

Question

The original VSS to TFS migration tool resulted in all migrated changeset having comments in the form:

{<Changeset Date>} <Changeset Comment> (<Migration Tool Comment>)

Since the migrated changeset itself can not have the actual original date (it has to have the current date/time), we found this extremely helpful when looking back at historical changesets to help us determine when something was actually changed.

The TFS to TFS Migration project that proceeded the current TFS Intergration Platform did not include the original changeset date/time in the comment so I grabbed the source code from the site and modified the code to include these this information in the comment - in GetChngeComment(ChangeGroup group) function I changed:

return group.Comment + " " + migrationComment;

to:

Regex tsfinder = new Regex(@"^\{\d{1,2}/\d{1,2}/\d{4} \d{1,2}:\d{2}:\d{2} [AP]M\}");


// We only want to modify the comment if it already doesn't start with a date/time in curly braces
// as this indicates that the changeset was originally migrated from a previous TFS/VSS server and
// we don't want to include the date of the migration nor a second copy of any migration comment.
if (group.Comment != null && group.Comment.Length > 0 && tsfinder.IsMatch(group.Comment))
{
  return group.Comment;
}

string timestamp = "{" + group.ChangeTimeUtc.ToLocalTime().ToString() + "} ";
return timestamp + group.Comment + " " + migrationComment;

While the new TFS Integration Platform has changed a lot, I thought that had found enough similarities in the code to incorporate those same changes into the current source code (in TfsVCMigrationProvider.cs). This worked very well in the previous tool however when I actually ran a test migration using the integration platform, I found that the code was injecting some other time and not the original changeset's!

So I traced through the code in the debugger and it appears that the code is creating the actual migration change groups from the data stored in the SQL Server database instance (which didn't apparently store the original changegroup's date/time) and then setting the SqlChangeGroup.ChangeTimeUtc with the value of the RTChangeGroup.StartTime (which by the way it is not converting to UTC first!).

Obviously the missed conversion from local time to UTC is a bug but I'm wondering why the code isn't preserving the original change group's date/time information? Is this behavior by design? Or just an oversight that was missed because the variable wasn't being used in the migration process until I added my changes?

Any recommendations for capturing the original change group's date/time information?

Answer 1

CMWoods,

Thank you for reporting the ChangeTimeUtc to RTChangeGroup.StartTime bug. We'll log it and try to fix it in the next release.

Regarding your question to catch the preserve the original changeset time, we are in the process to generalize the procedure to allow user to store more meta data of the original changeset during migration. 

In your situation, for now, I suggest to get the changeset time and persist it in changegroup comment at the first place. (when delta table entry is created) - It is inside the method populateChangeGroupMetaData() of file TfsVCAnalysisProvider.cs. Change the comment there to add a changeset time.  

 

Thanks,

Pei

 

Answer 2

Pei,

Thanks for the bug confirmation and additional information.

I had in fact already decided and implemented the workaround you have just suggested - actually I modified both populateChangeGroupMetaData() and GetChangeComment(). In the former, if the comment doesn't start with a date/time in curly braces I insert it at the start and then add a trailing character that is highly unlikely to appear in any typed comment (in my case I chose '\x255'). Then in the latter function if the comment ends with the marker character I remove the marker and append the migration comment; otherwise I return the comment unmodified.

This was much easier workaround for me than to try and mess with the RTChangeGroup, the database schema, and the entity framework code.