[Svnmerge] Slow generation of commit file

[Giovanni Bajo]

[sorry, i hit "send" for some reason too early...]


Blair Zajac <blair at orcaware.com> wrote:

> 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.

Doh! You're right! For some reason, I had convinced myself that '-' was only
used as a shortcut for stdin, and never for stdout. So, now I accept suggestion
on alternative command line for this.

> If we get faster logging using the new method,
> then maybe we don't need to turn it off.

In the best case, you still need to call "svn log" once. I don't think people
should pay this penalty if they are not interested in the log message at all.
Especially if just becasue we're being lazy with the command line interface...

>> 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.

I thought "-"*80 was a rather clear separator for log messages, isn't it? I
have no problems with XML, though.

Giovanni Bajo