We looked at this problem, and decided that typos were not sufficient reason to tamper with history.
However, committers sometimes forget critical information, such as the bug # associated with a commit, or other information critical to a useful audit trail. To avoid losing history, and yet allow for such critical information, our work-around is to allow changes to the svn:log property, but *only* allow appending to existing contents. Once we put that in, people stopped complaining. We don't allow users to change any other revprops. Eric. On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe <alf...@von-campe.com> 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)? > > Thanks, > Alfred > >
