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
Received on 2016-09-14 10:52:08 CEST