Re: Modifying svn:log property: good or bad?

On Feb 26, 2016, at 9:40 AM, Alfred von Campe wrote:
>
> Is modifying the unversioned svn:log property considered bad practice? We’re about to upgrade to a new Subversion server at work, and the central group that manages that server will no longer allow modifications to unversioned properties. Their main reason is so that third party tools like Jira and Crucible, that have daemons that scan check-in comments for keywords and index the results, don’t have to be re-run again to re-index updated commits. They are recommending creating a property on all the files that were affected in a commit (the name/value of the property is not important), and then committing that change with the “correct” check-in comment. I can see their point, but sometimes you just want to correct a minor typo in a commit log.
>
> I’m just wondering what collective wisdom of this group is in regards to updating the svn:log property (or other unversioned properties)?

We allow modifying svn:log in our open source project. We often use this to correct typos or add missing information. We use the Trac repository browser, and use both a post-commit hook script to import each revision into Trac initially and a post-revprop-change hook to update a log message after it was changed. This works fine. Both hook scripts also send emails to our public changes mailing list with a diff of what was changed.

Git discourages changing commit messages, because the commit message is part of the data that is hashed to generate the commit id; changing the commit message would change the id of the commit and all subsequent commits, which is undesirable. If you have or want to have a git mirror of your Subversion repository, that would be a reason to prevent changing your Subversion log messages.
Received on 2016-02-27 10:10:36 CET