Subversion: To edit or not to edit commit-comments

Question

Hello all,

I'm having a discussion with the management about Subversion practices. I've asked them to tell the administrator to configure our Subversion repository so it's possible to change the commit comments afterwards, in case I missed something even of the proof-reading :-).

My arguments are,

• Log messages which needs to be improved, such as more extensive comment or wrong spelling, can be changed.
• Mistakes are easily done when entering log messages, this way they can be reverted.
• Everyone deserves a second chance when a mistake has been made :-)
• If exporting the source code AND comments to a third party from the repository this would be valuable if an incorrect log message is found. If the comments can't be changed or only changed in the exported text file everything would become unsynchronized.

The cons are,

• The log message change itself would not be verisoned, thus the old message is obviously lost.

Our management rejected my change request because of "increased administrative costs" and "higher risks to be able to change afterwards". Obviously I've asked for a more extensive explanation.

Anyway do you guys got any comments on this? What do you think? Should it be OK to edit the log messages afterwards? Can you give me any more pro's to tell the management.

I think this limits the developers freedom, and as I developer I want maximum freedome to thrive :-)

Answer 1

We do this at work. If you can't get a non-trivial change reviewed before you commit, you add "r: username (pending)" to the log message. When the designated reviewer is finished, they edit the log message to remove the "(pending)". They may also add other comments in the log message.

Answer 2

Here is a use case. We have JIRA issue tracker. It has got a Subversion plugin which loads all subversion commit messages from our repository and associates them with corresponding issues in the JIRA system. The association is done automatically. All we have to do is to specify the issue number while making Subversion commits. The JIRA Subversion plugin parses log messages looks at issue numbers and associates them accordingly. Problem happens when a check-in message doesn't contain the issue number or it contains the wrong issue number. Such log messages need to be corrected so that Subversion commits reflected in JIRA are proper.

Answer 3

It all depends on how your comments are used. If your comments are essential documentation, you can consider to create a changelog og comments. When committing a new comment to the webserver, trigger that it makes a diff and appends that to a log. Then you have all the documentation that you need, in case somebody destroys vital comments, to restore them.

You can also simply make all editing of comments trigger e-mails, so that everybody knows when a comment has been edited. If somebody does something that is not ok, just change it back.

Answer 4

The answer should be based on how often the team use the log messages. if you are using them on a daily basis, and by that I mean, actually reading and processing the info contained in them then you should be able to change them. But if the comments in the log message are just there so that once and a while you can go back and look at them then why bother being able to change them.

I think there maybe a further issue that you are putting to much infomation into your log messages which would be better in a more accessable form like a bug tracker or wiki.

Answer 5

To avoid losing the history of your log messages and add some level of backup, you could implement a post-revprop-change hook script that write the old and new value of the log message property to a file (or send it via email, or create a sound file and have it spell the changes out loud for everyone to hear, or ...).

That way, it is always possible to check in the file that the post-revprop-change hook script writes and see what the original message(s) were.