Here's a basic sh script syntax.
# Check forbidden mergeinfo paths
TXN_PATHS=$($SVNLOOK changed -t "$TXN" "$REPOS")
# Grep for paths *not* in merge-allowed levels: /trunk,
/branches/release/*,...
TXN_PATHS=$(echo "$TXN_PATHS" | grep -Ev "^....trunk/?$" | grep -Ev
"^....branches/release/\w+/?$" | grep -Ev "^....branches/feature/\w+/?$")
for TXN_PATH in "$TXN_PATHS"
do
ELEM_PATH=$(echo "$TXN_PATH" | cut -c 5-)
MERGEINFO=$($SVNLOOK propget "$REPOS" svn:mergeinfo -t "$TXN" "$ELEM_PATH"
2>/dev/null)
if [ ! "$MERGEINFO" = "" ]; then fail_forbidden_mergeinfo_path;fi
done
---- Brent
From: Alfred von Campe <alf...@von-campe.com>
To: Eric Johnson <e...@tibco.com>
Cc: Subversion Users <users@subversion.apache.org>
Sent: Friday, February 26, 2016 2:22 PM
Subject: Re: Modifying svn:log property: good or bad?
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
