subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: Modifying svn:log property: good or bad?
Date Sat, 27 Feb 2016 09:10:20 GMT
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.

View raw message