On Tue, Mar 1, 2016 at 4:14 AM, Johan Corveleyn <jcor...@gmail.com> wrote:
> On Mon, Feb 29, 2016 at 4:56 PM, Alfred von Campe <alf...@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.
It can also be used to clean up from the last time someone edited the
logs, and got it wrong.
Some time back, I was involved an a CVS->Subversion migration in an
environment that used both. I found a spot in CVS commits years
previously that showed that someone had either tripped over a bug, or
had hand-edited the CVS logs but apparently had miscounted the number
of lines involved. CVS had tolerated it, but cvs2svn threw a fit
encountering the incorrect line count.
When I corrected the line count, the old sysadmin for the company
threw a wobbly because I had touched the "pristine" source control
system, which in fact was not "pristine", and even though I had
announced the change at scrum. Apparently this broke his parallel
CVS=>Subversion=>git=>check everything in git system, which had not
been mentioned in any design review or as a necessary step for
CVS=>Subversion migration, and which took several days to run on his
fastest borrowed system.
The results of these confusions were, well, unpleasant. There's an
XKCD cartoon about this problem.
https://xkcd.com/1172/
> 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.
It should be used only cautiously. Some folks consider this a big
danger, because it can be misused to hide provenance. It can
especially be used to change the history of copyright for original
commits, change the authorship or hide the evidence of breaking
commits, and modified after the fact to take credit for someone else's
work.
