Re: svn merge --record-only and svn log -g

[Philippe Combes <Ph...@enseeiht.fr>]

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

Re: svn merge --record-only and svn log -g

[Stefan Sperling <st...@stsp.name>]

On Wed, Sep 21, 2016 at 12:49:46PM +0200, Philippe Combes wrote:
> 
> > Perhaps your changelog generator could be taught to ignore revisions
> > which changed only svn:mergeinfo properties? Would that work around
> > the problem?
> 
> Stefan,
> 
> Thanks again for your time.
> As you point it out, it would only be a workaround, but it sounds a good
> lead. I plan to use svn2cl as the base of my changelog generator.
> Unfortunately, it relies on a language which I have no skill for: xslt.
> So I need to keep things quite simple, if I intend to customize the
> tool. Have you got any clue on a simple (based on subversion commands)
> and reliable way of identifying revisions which changed only
> svn:mergeinfo ?

svn log -v will show the list of changed paths and with --xml the output
can be parsed as XML. svn proplist lists the properties for a path, and
also has an --xml switch.

With this you should have all the information you need to find out
what changed in any revision. You might need to iterate over many
paths in large commits but I'm not sure how to optimize for that.
Perhaps somebody else has an idea.

If XML doesn't suite you, consider writing a script which uses one of
the language bindings (Python, Perl, Ruby, Java). Unfortunately the
documentation for bindings is relatively sparse, so it might take some
time to figure out how things work.

Re: svn merge --record-only and svn log -g

[Philippe Combes <Ph...@enseeiht.fr>]

> Perhaps your changelog generator could be taught to ignore revisions
> which changed only svn:mergeinfo properties? Would that work around
> the problem?

Stefan,

Thanks again for your time.
As you point it out, it would only be a workaround, but it sounds a good
lead. I plan to use svn2cl as the base of my changelog generator.
Unfortunately, it relies on a language which I have no skill for: xslt.
So I need to keep things quite simple, if I intend to customize the
tool. Have you got any clue on a simple (based on subversion commands)
and reliable way of identifying revisions which changed only
svn:mergeinfo ?

Regards,
Philippe

Re: svn merge --record-only and svn log -g

[Stefan Sperling <st...@elego.de>]

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?