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 <alfred_at_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 <eric_at_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 <alfred_at_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 <eric_at_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 <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 20:55:14 CET