Sorry, but it looks like our pre-revprop-change script is just a little to specific to my company, and I don't see a quick way to extract out a quick working version.
Eric. On Fri, Feb 26, 2016 at 11:22 AM, Alfred von Campe <alf...@von-campe.com> wrote: > Eric: > > Would you mind sharing your (redacted if necessary) commit hook that > enforces the policies you mentioned? > > Alfred > > On Feb 26, 2016, at 14:01, Eric Johnson <e...@tibco.com> wrote: > > We definitely enforce restrictions. We also log all revprop changes. > > Keep in mind that this information is key to establishing a historical > record of what happened with your source code. If you're lawyers haven't > advised you already, you might want to consider what happens if you ever > get hauled into court, and need to testify about the quality of the > historical information in your Subversion repositories. You want to keep > the list of people that can change the revprops (and the revisions > themselves) to an absolute minimum. > > Eric. > > > On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe <alf...@von-campe.com> > wrote: > >> 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> >> 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 >>> >>> >> >> > >
