vazexqi
commented
13 years ago It appears that these two participants might use a different locale from us. Apparently this might affect which day is the start of the week. So when Eclipse tries to convert the timestamps to a matching date (using our locale) to look up the corresponding refactoring descriptors and retrieve the data using RefactoringHistoryManager
/** The calendar instance */
private static final Calendar fgCalendar= Calendar.getInstance(TimeZone.getTimeZone("GMT+00:00")); //$NON-NLS-1$
/**
* Returns a path representing the history part for the specified time stamp.
*
* @param stamp the time stamp
* @return A path representing the folder of the history part
*/
public static IPath stampToPath(final long stamp) {
fgCalendar.setTimeInMillis(stamp);
final StringBuffer buffer= new StringBuffer(256);
buffer.append(fgCalendar.get(Calendar.YEAR));
buffer.append(IPath.SEPARATOR);
buffer.append(fgCalendar.get(Calendar.MONTH) + 1);
buffer.append(IPath.SEPARATOR);
buffer.append(fgCalendar.get(Calendar.WEEK_OF_YEAR));
return new Path(buffer.toString());
}However, it seems that a solution exists. RefactoringDescriptorProxy objects are created using a somewhat different mechanism -- perhaps by recursively traversing all directories and locating a refactoring.index file. We could use this mechanism to our benefit. Each time we locate a refactoring.index, we remember its path, construct RefactoringDescriptorProxy and store that additional information in it. That way when we try to reconstruct a RefactoringDescriptor from its proxy, we can use the exact path without resorting to the stampToPath method shown above.
reprogrammer
Some of the refactorings captured by CodingSpectator are missing from the final spreadsheets. For example, the final spreadsheets do not report any performed refactorings for two participants cs-505 and cs-506 even though CodingSpectator has captured several performed refactorings for these two participants.