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 🙂
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.