Community
Participate
Working Groups
I've been looking into setting things up to auto-populate CVS commit messages based upon ChangeLog entries but I'm sort of banging my head against the wall. At the time of the commit dialog being brought up, do we know what files have been changed? If so, we can stub out a ChangeLog entry as the commit message, right? Ideally we would re-work the ChangeLog plugin [1] to auto-populate itself based upon what files have changed and use the resulting entry as the proposed commit message (this could probably be toggle-able if people don't like that as the default - it is in lots of open source projects). I know there are issues when you don't use ChangeLogs, but those are easy to work around. There's also the question of integration with other source control systems so is the team synchronization stuff where this should actually be filed? I guess I'm just looking for direction here if anyone has any to give :) [1] http://sourceware.org/eclipse/#eclipse-changelog
First of all, we must keep in mind that some servers specify a commit template that is to be used. This could potentially conflict with any commit comment generated by the ChangeLog plugin. Now, if we were to address this properly, what we would need is an extension point in CVS where 3rd parties (i.e. the ChangeLog plugin) could register a commit comment generator. Ideally the user could identify which comment generator to use on a project by project basis (thus dealing with the presence or absence of the ChangeLog plugin or any other plugin that generated comments). The default generator would use the template from the server or the comment from an outgoing change set if one is defined for the files being committed. I would suggest that the extension point class look something like this public abstract class CommitCommentGenerator { public abstract String generateComment(SyncInfoSet set); } The SyncInfoSet would contain all the files that are being committed. The main stumbling block here is that the CVS plugin has no official API. We would need to decide whether this should be offical API or something that is internal that clients use anyway (like everything else in the CVS plugins).
We do not plan on addressing this issue but we will consider patches.
