Opened 15 years ago
Closed 15 years ago
#9003 closed defect (wontfix)
Can't init project from the existing SVN (IntegrityError: (1062, "Duplicate entry '%s' for key 1"))
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 0.11.6 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
Hi, I'm trying to migrate existing SVN projects to trac. I'm getting the following error:
Indexing repository Initenv for '/forge/trac/shape' failed. (1062, "Duplicate entry '%s' for key 1") Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/admin/console.py", line 604, in do_initenv repos.sync(self._resync_feedback) File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/versioncontrol/cache.py", line 214, in sync (str(next_youngest), File "/usr/lib/python2.3/site-packages/Trac-0.11.6-py2.3.egg/trac/db/util.py", line 64, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line 163, in execute self.errorhandler(self, exc, value) File "/usr/lib/python2.3/site-packages/MySQLdb/connections.py", line 35, in defaulterrorhandler raise errorclass, errorvalue IntegrityError: (1062, "Duplicate entry '%s' for key 1")
Attachments (0)
Change History (10)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
comment:2 by , 15 years ago
I checked the resolution and it seems that mysql_backend.py contains all patches. The difference between their issues and mine is that in my case %s wasn't translated at all.
comment:3 by , 15 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
I checked the resolution and it seems that mysql_backend.py contains all patches. The difference between their issues and mine is that in my case %s wasn't translated at all.
I forgot to reopen it
comment:4 by , 15 years ago
This is not a question of patches or not, this is a matter of properly creating your MySQL database according to the instructions given in MySqlDb page.
Please show us the output of:
mysql> show create database trac;
(replace trac in the above by whatever name you used for the Trac database)
The output should be something like:
+----------+--------------------------------------------------------------------------------+ | Database | Create Database | +----------+--------------------------------------------------------------------------------+ | trac | CREATE DATABASE `trac` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */ | +----------+--------------------------------------------------------------------------------+ 1 row in set (0.00 sec)
If not (most likely you have ... COLLATE utf8_ci
), then you have to fix the collation (see MySqlDb#Collationfromwhatevertoutf8_bin).
If you have utf8_bin
(which I doubt as you may have figured by now), then it's an actual bug and the easiest step forward would be to send us a dump of the actual repository, or if not possible, of a smaller test repository which shows the same issue (i.e. has the same kind of paths differing only by case).
follow-up: 6 comment:5 by , 15 years ago
Hi, By having latin1 or utf8 CS w/out collate option - the initproject crashes on commit number #329. By adding collate option with utf8, trac was unable to sync with SVN at all.
Other project passed well the initenv procedure.
I can't send you repository due to IP, but maybe debug trace will be sufficient. Just let me know how i can activate the required trace level for initenv.
TIA, Boris Mikhailovski
comment:6 by , 15 years ago
Replying to b.mikhailovski@…:
Hi, By having latin1 or utf8 CS w/out collate option - the initproject crashes on commit number #329. By adding collate option with utf8, trac was unable to sync with SVN at all.
utf8_ci
or utf8_bin
? This makes the whole difference.
utf8
itself is an alias for utf8_general_ci
, therefore the wrong one.
comment:7 by , 15 years ago
hi, I tried the following ones:
| Database | Create Database | +------------+---------------------------------------------------------------------+ | trac_shape | CREATE DATABASE `trac_shape` /*!40100 DEFAULT CHARACTER SET utf8 */ | +------------+---------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> create database trac_shape DEFAULT CHARACTER SET utf8 -> COLLATE utf8_bin -> ; Query OK, 1 row affected (0.00 sec) mysql> show create database trac_shape -> ; +------------+--------------------------------------------------------------------------------------+ | Database | Create Database | +------------+--------------------------------------------------------------------------------------+ | trac_shape | CREATE DATABASE `trac_shape` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */ | +------------+--------------------------------------------------------------------------------------+
The first one w/out collate succeeded to parse ¾ of total commits. The second one with collate failed.
comment:8 by , 15 years ago
Which MySQL version and which version of the MySQL bindings for Python are you using?
comment:9 by , 15 years ago
MySQL-python-1.2.1_p2-1.el4.1 mysql-4.1.20-2.RHEL4.1.0.1 mysql-server-4.1.20-2.RHEL4.1.0.1 binding: mysql://xxxxx:yyyy@localhost:3306/trac_$1
comment:10 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
From the MySqlDb page:
- The recommended versions of MySQL are those from 5.0.x series. It might work with 4.1.x or 6.0.x, but no guarantees. …
- The recommended version is MySQL-python 1.2.2, which must be compiled in thread-safe client mode. Earlier versions are known to be problematic. … (MySqlDb#MySQLdb)
This is an InstallationIssue.
Must be a duplicate of #4378.
When using MySQL, please follow carefully and to the letter the instructions in MySqlDb page, about how to create the database and select the proper encodings, and which engine to use.