Kristis,
The regex I was using didn't allow multiple bug #s. Here are a pair of
regular expressions using your style that work for my large commit messages
when using TortoiseSVN as the client.
log_bugid_regex => '^.*Issue:\s([\d\s,]+?)$',
log_body_regex => '^(.*)\s*Issue:\s[\d\s,]+?$',
Regards,
Mike
-----Original Message-----
From: Kristis Makris [mailto:[EMAIL PROTECTED]
Sent: Monday, January 21, 2008 2:29 PM
To: Brown, Mike
Cc: '[email protected]'
Subject: RE: [scmbug-users] very large commit comments break scmbug +
bugz illa
I was confused for a while after I read this.
On Mon, 2008-01-21 at 14:07 -0600, Brown, Mike wrote:
> I added a gettimeofday timer to prepare_activity as shown in the attached
> code snippet. Let me know if there are any problems with the way I did
this
> test.
Your implementation seems correct.
> For both small and large commit log messages the timing results are
> comparable between the regular expressions.
>
> For a one line commit log message, your regular expressions are about 2
> milliseconds slower (.084 vs .082 seconds). For the large svnmerge log
> message, your regular expression are 3 milliseconds slower (.473 vs. .470
> seconds).
I assumed my regexes would have been faster. I was wrong.
> From: Brown, Mike
> Yes, I tested with my large commit message. The regex I sent you works
for
> both the simple single line log message with a trailing bug # and the
300KB
> log message from svnmerge with a trailing bug #.
I was confused because I had assumed that the "^" character was what led
the integration to finish quickly before. I missed the fact that you
added a "$" at the end of your regexes. Using your regexes with the "$"
at the end obviates the need to also put a "^" in the front, hence are
faster. Your regexes work better than the ones I suggested. Thanks for
the clarification.
I'm still unsure of what would be an ideal, permanent fix to this, one
that does not conflict with parsing status resolution messages that are
inserted both before and after the log message. You reported:
"Setting the resolution flag on and using your regexes was a successful
test case."
While I had assumed that similar regex performance issues would arise
with status resolution. SCM.pm.in:prepare_final_log_message parses
status resolution messages first, and then the log message. It seems to
me that unless the status resolution regexes are also changed similar
performance issues would arise. Are you sure that with a status
resolution policy enabled, a long log message does not cause a hang ?
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
