Within a pre-commit script, is it possible (and if so, how) to identify commits stemming from an svn merge?
svnlook changed ... shows files that have changed, but does not differentiate between merges and manual edits.
Ideally, I would also like to differentiate between a standard merge and a merge --reintegrate.
I'm exploring the possibility of using pre-commit hooks to enforce SVN usage policies for our project.
One of the policies state that some directories (such as /trunk) should not be modified directly, and changed only through the reintegration of feature branches. The pre-commit script would therefore reject all changes made to these directories apart from branch reintegrations.
Any ideas?
I've explored the svnlook command, and the closest I've got is to detect and parse changes to the svn:mergeinfo property of the directory. This approach has some drawback:
svnlook can flag up a change in properties, but not which property was changed. (a diff with the proplist of the previous revision is required)svn:mergeinfo, it is possible to detect that svn merge was run. However, there is no way to determine if the commits are purely a result of the merge. Changes manually made after the merge will go undetected. (related post: Diff transaction tree against another path/revision)I've eventually resorted to a non-ideal solution, i.e. detecting changes in the svn:mergeinfo property in the top directory of the changes tree (implemented in SVNTransaction.is_merge_operation()).
We cannot differentiate between merge-only commits and commits that also include additional changes. This means all changes that occur under that tree will go undetected if committed along with a merge. A possible solution might be to diff the transaction tree against the merge source but I have not figured out how to achieve that yet (this will also need to take into account changes as a result of conflict resolutions).
It also cannot differentiate between a merge and a merge --reintegrate.
Other limitations include the reliance on svn:mergeinfo which is user-modifiable and not used in older version of subversion.
The commit scripts in question is meant as a gentle reminder to flag commits that go against project guidelines rather than an access control mechanism, so the limitations listed above is not a show-stopper. However, I'm still on a lookout for improvements. Comments and further suggestions welcome.