On 7/27/2016 6:18 PM, Philippe Combes wrote:
Dear Subversion users,
The root cause of my question is the need to automatically process the
commit logs to generate a proper ChangeLog. In order to really list all
modifications done, I have got to use svn log --use-merge-history.
Since this command is based on the property svn:mergeinfo, it lists all
merged revisions, even those which were added by svn merge
--record-only. In other words, it lists some modifications which were
not actually done.
Looking for a solution to this issue, I discovered the existence of the
tool svnmerge.py. If I understand well how it used to work, two lists of
changesets were maintained in subversion properties, so that it kept
track of the changesets blocked. I have noticed that this tool has been
removed from subversion 1.8, yet svn merge appears not to be a
one-to-one replacement for it, since it looses track of the "recorded
only" changesets.
Am I missing something ? Is there any way to segregate the recorded only
changesets from the other with the svn commands ?
I know some of you may answer that using --record-only is bad practice,
but I am working on a project where it is used intensively, and it would
be very hard to rollback on these habits. By the way, my guess is that
as long as the option is provided, the other commands should be
consistent with its behaviour.
Has anyone already met this kind of issue ?
Thanks in advance for any piece of help or advice,
Philippe
Can't provide much help for your case, but the limitation of indicating
whether some revision was merged or blocked is not new.
Unfortunately, one can't simply say that everything which uses the
--record-only merge flag would correspond to indicating the revision was
blocked. It can also mean that the corresponding changes were already
manually merged (or no longer apply) to the target branch but still
should be seen/considered as merged. We use this concept quite regularly
and indicating in general that a --record-only merge would mean a
revision was not integrated in the target branch would be wrong for
these cases.
Hence the whole problem is a bit more complicated than it seems to be.
We don't run into this issue, because we do not use the mergeinfo to
indicate a revision was blocked. In this case we simply don't merge it
and skip it. For some automated tools we use a specific flag in the
commit log of revisions which are not meant to be merged into some other
branch(es). The tools check for these flags in the log and simply skip
these revisions. Maybe this approach might be usable for you as well?
--
Regards,
Stefan Hett
