Detecting branch reintegration or merge in pre-commit script

Question

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.

Background:

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?

---

Update:

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:

1. 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)
2. By inspecting changes in 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)

Carpic

Do you need to distinguish between reintegration and regular merges? – Grondin

@ÁlvaroG.Vicario Ideally, yes. But I'd settle for simply detecting merges of any kind. – Carpic

I don't think that parsing svn:mergeinfo is fragile: that property is the mechanism used by Subversion to track changes. However, I'm not sure that the --reintegration option has any direct effect in revision properties. Sorry I can't be of more help. – Grondin

@ÁlvaroG.Vicario good point. I'll look further into that. – Carpic

Unfortunately, looking at svn:mergeinfo alone is not enough. See updates above. – Carpic

Are you using SVN 1.6 or 1.7 client/server? The merge is done differently somewhat in 1.7 and perhaps it is easier to handle. I'm curious about the same question, but a big problem with 1.6 is that people get so irritated by the mergeinfo property "spuriously" committing that they (or I!) remove the mergeinfo. Conversely, committers can unwittingly commit a changed mergeinfo on 1.6 working projects and would be horrified if I bounced the commit back. So maybe a big part is what is your procedure? I would love to hear what you think works best. – Biometrics

Answer 1

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.

Carpic

Answer 2

unfortunately subversion does not enforce merge only commits

if i have access to a branch, i can do whatever after merge and before commit

also subversion merge happens on client side

lot of code repository tools will merge on server. i.e. enforce that you are only moving patches from one stream to another

Defroster