Project

General

Profile

Problem when parsing the changeset in Mercurial

Added by Vianney Lecroart over 13 years ago

I don't understand why, but with a specific changeset on mercurial, redmine has a problem.

The changeset is:
http://ryzom.hg.sourceforge.net/hgweb/ryzom/ryzom/rev/7eab6ad7c6c3

and in "def fetch_changesets", the "changeset" is:

#<Changeset id: nil, repository_id: 6, revision: "647", committer: "kervala", committed_on: "2010-08-20 13:30:00", comments: "Changed: Added more filters to .hgignore", commit_date: "2010-08-20 13:30:00", scmid: "7eab6ad7c6c3", user_id: nil>

As you can see the "id" is nil, so it cannot create the changeset and then it generates a db error:

/usr/local/lib/ruby/gems/1.8/gems/rails-2.3.5/lib/commands/runner.rb:48: /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract_adapter.rb:219:in `log': Mysql::Error: Column 'changeset_id' cannot be null: INSERT INTO `changes` (`changeset_id`, `action`, `branch`, `path`, `revision`, `from_path`, `from_revision`) VALUES(NULL, 'M', NULL, '/.hgignore', NULL, NULL, NULL) (ActiveRecord::StatementInvalid)

Sinec i don't find where in the code the "id" is setted, I don't really know what's happen.

just for information, it's the first time in 3 months that we have this issue, we had 600 commit before without any problem with redmine.


Replies (7)

RE: Problem when parsing the changeset in Mercurial - Added by Felix Schäfer over 13 years ago

The problem is with changes.changeset_id, not changeset.id, that's a big difference :-) The id attribute in the changeset table is autoincremented by the DB, i.e. it gets set when committed to the DB. That id should then make its way to the Changes object rails tries to commit so that changes.changeset_id is populated, which obviously doesn't happen. Can you see if your DB holds a Changeset with an scmid of 7eab6ad7c6c3 or a revision of 647?

Have you done anything with either the redmine or the DB before this changeset should have been loaded?

RE: Problem when parsing the changeset in Mercurial - Added by Vianney Lecroart over 13 years ago

Indeed, there's already an entry in changesets database with revision 647 and scmid 7eab6ad7c6c3 and is exactly the same as the one redmine try to fill.

Should I remove the entry in the database?

RE: Problem when parsing the changeset in Mercurial - Added by Felix Schäfer over 13 years ago

Are the other attributes the exact same as what you have posted above (minus the id)? If yes, there was a glitch and you should be able to delete it, if not, there is something wrong with the hg adapter recognizing two different commits as one.

RE: Problem when parsing the changeset in Mercurial - Added by Vianney Lecroart over 13 years ago

It's the same value except the user_id. In the database, the user_id is 5 and in the redmine, it's nil.

RE: Problem when parsing the changeset in Mercurial - Added by Felix Schäfer over 13 years ago

Mmmh… To be honest, I don't know that portion of code good enough to give you a definitive answer. You can try on at your own risk to remove said database entry and to run the import again. The worst thing that I can imagine could happen is corruption in that part of the DB, but as it is "just" a cache of "metadata" about your repo, you could still delete the repository config in the project and import in again.

RE: Problem when parsing the changeset in Mercurial - Added by Vianney Lecroart over 13 years ago

I removed the entry in the db, restart the process and now it works prefectly!

Thank you Felix for your help!

RE: Problem when parsing the changeset in Mercurial - Added by Felix Schäfer over 13 years ago

Well, glad it worked out well, though that still seems like a glitch, I don't have the time to investigate it more sadly.

    (1-7/7)