[Svnmerge] Slow generation of commit file

[Blair Zajac]

Giovanni Bajo wrote:
> Hello,
> 
> Daniel Berlin complained that generating the commit file might take even longer
> than doing the merge. He is actually right: construct_merged_log_message
> invokes a distinct "svn log" for each and every revision! That's something I
> had totally missed. When I said "you can disable commit file generation by
> using /dev/null" I was wrong: disabling commit file also saves (possible
> multiple) svn invokations, so there ought to be a way to do it.
> 
> I have committed (in my repository) a version which adds "-f-" as a way to shut
> off commit file generation. I'll be porting it to the SVN repository soon (and
> I'll be dropping my repository soon as well, when everything is merged over).
> BTW, in my repository I also implemented a real test framework for svnmerge,
> for which I have constructed real testcases for basic commands. That's great
> for development!

Hi Giovanni,

Well, when I see -f - or -f-, I see the second - as a symbol for standard 
output, as that's the common meaning for a file named '-' from tar and other 
programs.  But I don't have a good idea on how to turn off logging.  If we get 
faster logging using the new method, then maybe we don't need to turn it off.

That's great that we have a larger test suite to work with.

> I believe we should tweak construct_merged_log_message so to invoke "svn log"
> only once, including the whole range of revisions we need a log for. Some past
> experiments have shown me that "svn log" has slow setup and fast execution, so
> it's much better to ask more data, rather than calling it with more resolution.
> Especially for normal cases, I don't expect wild ranges in revisions being
> merged, so it looks like the best solution and the easiest to implement.
> Comments?

Sounds like a good idea.  If we were using the Python swig bindings, then this 
would be a very safe operation, as the bindings would distinctly separate the 
log messages.  With this method, I think we should switch to using the --xml 
option to svn log, otherwise we get into a revision separator parsing game, 
which I would rather avoid.

Regards,
Blair