convert_logs.py failing on line 82 if last log line is ------...

[GoogleCodeExporter]

convert_logs.py failing on line 82 if last log line is ------...

[GoogleCodeExporter]

Another bug appears in the condition (around line 80)

                if rev_line is '':
                        break;

and can be fixed by changing to:

                if rev_line is '' or len(rev_line)<2:
                        break;

Original comment by [email protected] on 23 Jun 2008 at 3:07

[GoogleCodeExporter]

OK, sorry but the results of that script are completely wrong with a log from 
"svn
log -v > my.log".
When generating the PNGs, the date is set to 14 jan 1970 and the names of all
contributors appear at the same time.
Can't do much to fix that right now, as I don't know the expected export format 
very
well (just have the examples provided with the SVN).

I can provide the SVN logs export (almost 6MB) for tests if it helps.

Original comment by [email protected] on 23 Jun 2008 at 3:31

[GoogleCodeExporter]

The problem seems to be on the timestamp format. The processing code parse it 
as a
milliseconds epoch time whereas the conversion python script outputs it as a 
seconds
epoch time. Correcting the output or the new Date() statement by adding * 1000
corrects the problem.

The question is what's the real spec ? Millis or sec. ?

Original comment by [email protected] on 23 Jun 2008 at 1:55

[GoogleCodeExporter]

I agree that multiplying by 1000 seems to solve the problem. I have done that in
convert_logs.py line 86:

 date = int(time.mktime(date.timetuple()))*1000

Thanks, garphy.

Original comment by [email protected] on 23 Jun 2008 at 3:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hey guys,

I apologize with your troubles with using the log conversion script.  It is 
still a
WIP and I should have noted it as such.

ywarnier:  You mentioned having problems associated with the last line of the 
log. 
I'm interested to see what the last line of your log file is, because on 
windows I
never experienced the error you got, but I wouldn't be surprised by a platform
inconsistency :)  In any case, I will make the appropriate change.

As far as the time goes, I guess I hadn't been looking too closely at the 
timestamps
as they rolled on.  Your solution makes sense though and I will make the 
appropriate
change.

Let me know once you have tested it with the updated changes and if it is 
successful
I will close the ticket.

Original comment by [email protected] on 23 Jun 2008 at 7:47

[GoogleCodeExporter]

Have you gotten a chance to see if the original error mentioned in this ticket 
still
occurs for you after the recent changes?  Please let me know asap once you have 
tried
it out :)

Original comment by [email protected] on 24 Jun 2008 at 5:33

[GoogleCodeExporter]

Original comment by [email protected] on 24 Jun 2008 at 1:01

[GoogleCodeExporter]

I think most of the Subversion log-parsing issues with this program stem from 
the
fact that it completely ignores the most important piece of parser-helping
information present in the log output stream -- the count of log lines.  I'm
attaching a patch which seems to remedy this.  (At least, it makes conversion 
of the
Subversion project's own history work completely instead of silently croaking 
after
only a couple of thousand revisions.)

Original comment by cmpilato on 27 Jun 2008 at 6:13

Attachments:

• convert_logs_notes_num_lines.patch

[GoogleCodeExporter]

Didn't have time to try it out and time is very sparse these days, but the 
final line
of my SVN log was just an empty line (after a -------- line).

Original comment by [email protected] on 27 Jun 2008 at 5:20

[GoogleCodeExporter]

I can no longer reproduce this error since the check for when the end of a file 
is
reached is no longer based on an empty string.

Original comment by [email protected] on 7 Jul 2008 at 5:36

• Changed state: Fixed

[GoogleCodeExporter]

I hit this same error as I had an SVN commit message containing something like 
this:

--------------------------------------------------------------------------------
-------------------------------------------
Container [ FAULTS ]
--------------------------------------------------------------------------------
-------------------------------------------
Action/URI                   Min T    Avg T    Max T   Last T  Calls   Good   
Warn 
Error    XFreq Busiest  Running     JMS

The work-around I added is this:
Index: convert_logs.py
===================================================================
--- convert_logs.py (revision 201)
+++ convert_logs.py (working copy)
@@ -88,7 +88,7 @@
             line = file_handle.readline()
             while len(line) > 0:
                 # The svn_sep indicates a new revision history to parse.
-                if line.startswith(svn_sep):
+                if line.strip() == svn_sep:
                     # Extract author and date from revision line.  Here is a sample
revision line:
                     # r9 | michael.ogawa | 2008-06-19 10:23:25 -0500 (Thu, 19 Jun
2008) | 3 lines.
                     rev_line = file_handle.readline()

Original comment by [email protected] on 22 Jul 2008 at 12:50

[GoogleCodeExporter]

Received this error using trunk@270:

Traceback (most recent call last):
  File "convert_logs/convert_logs.py", line 408, in <module>
    main()
  File "convert_logs/convert_logs.py", line 113, in main
    author = rev_parts[1]
IndexError: list index out of range

Original comment by [email protected] on 14 Apr 2009 at 3:12

[GoogleCodeExporter]

Received also the following error with an subversion log:

Traceback (most recent call last):
  File "convert_logs.py", line 409, in <module>
    main()
  File "convert_logs.py", line 114, in main
    author = rev_parts[1]
IndexError: list index out of range

For me a comment to a revision contained a line full of dashes (i.e. like the 
"normal" revision separator), which 
was however longer than the separator.  Removing this line fixed the problem.  
The line comes from the 
original comment.

Original comment by [email protected] on 3 Oct 2009 at 10:43

[GoogleCodeExporter]

It seems like Windows SVN (collabnet) clients may give an extra ^M on a blank 
line (basically DOS line-endings are 2 characters instead of 1). This makes the 
converter cough up wrong entries (and the XML parser barf because it's trying 
to look for file paths not comments).

You can dos2unix your log files first, or if that's not available you can try 
this:


*** ../convert_logs/convert_logs_orig.py        2009-05-14 23:48:56.000000000 
-0700
--- ../convert_logs/convert_logs.py     2011-03-21 16:30:10.365016000 -0700
***************
*** 119,125 ****
                      # Skip the 'Changed paths:' line and start reading in the changed filenames.
                      file_handle.readline()
                      path = file_handle.readline()
!                     while len(path) > 1:
                          ch_path = None
                          if opts.svn_log:
                              ch_path = path[5:].split(" (from")[0].replace("\n", "")
--- 119,125 ----
                      # Skip the 'Changed paths:' line and start reading in the changed filenames.
                      file_handle.readline()
                      path = file_handle.readline()
!                     while len(path) > 2:
                          ch_path = None
                          if opts.svn_log:
                              ch_path = path[5:].split(" (from")[0].replace("\n", "")

(It should work in Linux systems as well, since all non-blank lines I've seen 
from svn logs always have more than 1 character.)

Original comment by [email protected] on 21 Mar 2011 at 11:34