Edgewall Software
Modify

Opened 6 years ago

Closed 4 years ago

#11285 closed defect (duplicate)

trac-admin repository sync fails with very long svn commit message

Reported by: magnus.dahlberg@… Owned by:
Priority: normal Milestone:
Component: version control Version: 1.0
Severity: normal Keywords: svn mysql
Cc: Branch:
Release Notes:
API Changes:

Description

I've added a svn repo to our trac project. When I do 'repository resync' it fails on a specific revision. A quick glance into the log reveals;

2013-08-28 16:06:43,088 Trac[cache] INFO: repos rev [11849] != cached rev [6654]
2013-08-28 16:06:43,101 Trac[cache] INFO: Trying to sync revision [6655]
2013-08-28 16:06:43,131 Trac[cache] WARNING: Revision 6655 already cached: DataError(1406, "Data too long for column 'message' at row 1")

When I look into the svn log history at the failing revision, rev 6655, it appears that that specific commit was a merge. And the commit message is the whole merge history…

The commit message is 1200 lines long… And the error message suggests that it is too long for the database. Perhaps it could be shortened automatically when added?

OS: Windows 2008 server Python2.7 svn 1.8.1 mySQL 5.5.8

Attachments (0)

Change History (6)

comment:1 by Jun Omae, 6 years ago

Keywords: mysql added
Milestone: next-major-releases
Summary: defect: trac-admin repository sync fails with very long svn commit messagetrac-admin repository sync fails with very long svn commit message

The similar issue is #11032. Max length of TEXT type is 65535 characters. See comment:7:ticket:11032. Currently, Trac doesn't truncate the commit messages with the max length.

in reply to:  1 comment:2 by Ryan J Ollos, 6 years ago

Replying to jomae:

Currently, Trac doesn't truncate the commit messages with the max length.

Do you have a suggestion on the best way to determine the length at which the message should be truncated? It appears PostgreSQL doesn't have this text length limitation, only MySQL. I haven't looked at SQLite yet, but given the differences between MySQL and PostgreSQL, I can think of a few ways to handle this.

  1. Have the database wrapper (e.g. tags/trac-1.0.1/trac/db/mysql_backend.py) store the max text length, or see if it is possible to get it directly from the database API.
  2. Just truncate all commit messages to the minimum max text length of all the databases that we support.

comment:3 by Jun Omae, 4 years ago

Trac 1.1.4+ uses MEDIUMTEXT for revision.message column in [13767] (#8396).

comment:4 by Ryan J Ollos, 4 years ago

It looks like MEDIUMTEXT would also be used for wiki.text addressing #11032. Should we go ahead and close this ticket then? Since we are fairly close to a 1.2 release, I can't see going through the effort to implement a workaround on 1.0-stable.

Last edited 4 years ago by Ryan J Ollos (previous) (diff)

comment:5 by Jun Omae, 4 years ago

Okay. I suggest to close this ticket as a duplicate of #8396.

Workaround for Trac 1.0.x or early:

ALTER TABLE `revision` CHANGE `message` `message` MEDIUMTEXT;

comment:6 by Ryan J Ollos, 4 years ago

Milestone: next-major-releases
Resolution: duplicate
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.