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.
