On Mon, Feb 29, 2016 at 4:56 PM, Alfred von Campe <alfred_at_von-campe.com> wrote:
> Thanks to all who have shared their respective policies. I’d be very interested to hear from the Subversion contributors themselves as to what the policy is for the Subversion repo.
I'm a Subversion committer, but my $dayjob is at a large university
hospital which uses Subversion. We simply allow changes to the svn:log
revprop, by any committer to any revision (in the beginning we only
allowed changes to your own commits (checking $AUTHOR), but that
turned out to be too strict -- sometimes you simply want to correct a
typo in a commit message from some employee that's no longer there).
This is mostly used to correct typos and to add / correct metadata
tags (such as JIRA issue numbers or helpdesk tickets).
We keep a logfile on the server of any revprop changes (simply some
echoing to a file from within the pre-revprop-change hook), and also
automatic mails to people from the post-revprop-change hook. We trust
people to use this feature wisely, and we always have a trace in case
something goes wrong.
For propagating these changes to other indexes, such as the one
maintained by Atlassian FishEye / Crucible (also linked to our JIRA
instance), I've planned to add some call to the post-revprop-change
hook, but so far haven't gotten around to it (so sometimes I simply
rerun the indexing from inside the Crucible maintenance pages for the
last 1000 revisions or so). This is firmly on my todo list, and
shouldn't be too difficult, but you know ... other priorities.
We fully support this policy, we even consider it a great extra
feature of subversion, that people can correct mistakes in log
messages (compared to other version control systems). A good
description of history (which is what those log messages represent) is
a very valuable asset. We also get regular IT audits, but have no
problem in defending this policy, since we have all the necessary
traces.
--
Johan
Received on 2016-03-01 10:14:46 CET