On Wed, Sep 14, 2016 at 10:51:54AM +0200, Philippe Combes wrote:
> 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.
There is no 1:1 correspondance between the svnmerge.py script dating
back to 2004, and the built-in merge-tracking feature as it was designed
during the release cycle of Subversion 1.5 in 2007/2008.
This goes both ways: merge-tracking has features which svnmerge.py
did not have. Obviously all this was decided many years ago and is
now water under the bridge.
It's possible that nobody at the time thought of your use case for
svn log --use-merge-history and how it would interact with the ability
to run --record-only merges. I think you've spotted a design flaw.
But I don't think making the current merge system even more complicated by
adding yet another special property is something we would want to do now.
The implications for any change in merge-tracking are huge. Such a change
needs very careful planning and a lot of testing. There are many edge cases
which could be affected by such a change. I doubt anyone would manage to
fully design and implement your idea in a releasable state without investing
several weeks, if not months, of serious full-time work.
> 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.
Perhaps your changelog generator could be taught to ignore revisions
which changed only svn:mergeinfo properties? Would that work around
the problem?
Received on 2016-09-14 11:23:55 CEST