Typo in versioncontrol.pages.inc

This must be my most embarrassing moment in personal release history *ever*. The only possible excuse is that I don't have any time right now that I can spend on Version Control API, and I'm really sorry that you need to write reports for stuff that I should have promptly noticed in the first place. I released one more tarball (beta3) which should now really be testable. Fixes your mentioned issue and one more stupid bug, plus I ensured that at least the basic registration workflow is functioning correctly. Hope it works out this time, and a big thanks for being active in the issue queue :)

No problem at all:) thanks:)
Sorry for posting here - but is the second stupid bug is related to the problem I get, that deals with duplicating svn repository revisions?

I've got now ~4600 revisions + 4600 same revisions under different IDs :( For example 'id=1' is 'rev=1' and 'id=4586' is 'rev=1' :(

Nope, shouldn't be related. (The second bug dealt with a PHP error on the user account page.)
Is the revision incorrect in the database as well (table versioncontrol_item_revisions, column revision), or is it just displayed incorrectly by Commit Log?

It is incorrect in the database either. I thing this could somehow be dealt with cron runs during initial revisions database import (Initial import took ~40 minutes and my cron runs every 15). Will try to import again with disabled cron

Nah, I guess I messed up something in the SVN backend. Whether the update is run by cron or manually should not make any difference. I'll try it for myself once I find time. (Saturday?)

Also, in case you got any new findings on this bug, let's continue this in a new issue :)

There is (at least) one issue causing it to run _much_ more slowly than it would otherwise; there are some problems in svnlib, in particular the static cache function, which is causing it to do far more rebuilding of the svn info than it otherwise would, and also chewing up a huge amount of energy spitting out error messages. It's the primary reason why I've undertaken a rewrite of the svnlib.

The good news: I finally had a look if something is obviously wrong.
The bad news: Didn't find something that is blatantly wrong, and my 275-revision test repository imported with correct revision numbers.

In case your repository doesn't contain sensitive data then perhaps I can figure something out if you send me a repository dump, but probably it's really a race condition caused by concurrent cron runs. We should consider introducing some lock (if only a simple one with variable_set()/variable_get()) to prevent such concurrent runs. Apart from that, it seems that waiting for Sam's new shiny svnlib is the most promising hope for the SVN backend's log parser.

Automatically closed -- issue fixed for 2 weeks with no activity.