Eric: Thanks for the feedback. Do you enforce just appending to the svn:log property or is that just the policy and everyone follows it? Same question for modifying the other recprops: do you enforce it or is it just policy?
Alfred > On Feb 26, 2016, at 12:42, Eric Johnson <e...@tibco.com> wrote: > > 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 > <mailto: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 > >
