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 <alfred_at_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
>
>
Received on 2016-02-26 18:43:24 CET