Stefan, Thanks a lot for your time and your answer. I am sorry I could not read it sooner...
Now I understand well the issue of manual merges, but I don't understand the choices made regarding it. I have the feeling that --record-only has been first introduced for such manual merges. Then it has been used as a workaround to the missing functionality of purely blocking some merges, which is clearly quite different. This missing functionality was supported by svnmerge.py but it has been removed. The only solution here is to add another option to svn merge, --block, with another reserved property, just as svnmerge.py used to do. I have no idea of how deep the impacts on the svn merge code would be (from my external point of view, it is just merging two lists of changesets into one at the beginning of the merge process), but svn log -g would then work as expected with no additional developments. I hope we will have some feedback from the Subversion developers on this point. With regards to your advice of using tags in the logs, it does not apply easily to my research projects, where the decision of merging a changeset or not is made at merge time only. This would mean changing all logs at merge time, which can be quite a long task because of administration rights issues. Moreover we already use tags in logs for other kinds of segregation and it may overload the logs. Thanks again, Philippe Combes
