I'm getting a error message when viewing the revision list for a project:
Fatal error: Call to undefined method SkinMonoBook::link() in /srv/www/htdocs/mediawiki-1.13.2/extensions/CodeReview/CodeRevisionListView.php on line 133
I'm using the latest revision, 43393. The author list works as expected, until I click on an author. The same error message appears, just with CodeRevisionAuthorView.php at line 31. Does somebody know a solution to this? --

As stated in the box at the right, this extension requires MediaWiki 1.14alpha. iAlex 18:35, 11 November 2008 (UTC)Reply[reply]
Damn it. Didn't saw that. Thanks for pointing it out ;-) --


Having done the initial import (using svnImport.php), will the extension automatically look for new revisions periodically or do you need to re-run the script to make the new revisions show up? --HappyDog 12:44, 24 February 2009 (UTC)Reply[reply]

I second HappyDog's question. Is the extension designed to automatically look for revisions, or is this the responsibility of the admin? I set up a cron job to run svnImport.php regularly, which works, but I'm wondering if that's the best solution. --Molson 00:13, 3 July 2009 (UTC)Reply[reply]
Excellent point, this wasn't documented! I've added a sample setup in Extension:CodeReview#Automating updates. --brion 21:47, 7 August 2009 (UTC)Reply[reply]

Perhaps an example?

This strikes me as rather useful, but it's still a bit obscure for the uninitiated. Perhaps an expanded explanation of what this extension allows (or even better, a detailed example) would help. --Gth-au 09:39, 22 July 2009 (UTC)Reply[reply]

git support - maybe?

It would be nice if this also supported git as an alternative. I doubt it would be that difficult to use git instead of svn, I realise the branch differences, but I suggest just using master. --Svippong 21:23, 7 August 2009 (UTC)Reply[reply]

Been pondering this myself... ;) At a minimum there's a couple things that would need to be taken into account:
  1. git uses 160-bit hex content hashes as commit identifiers; the cr_id field and friends would either need to be expanded to accept this, or support for a 'native ID' could be added for the git id, with a number used for internal table relations.
  2. Related to this, ordering is different; a SVN repo can be visualized either as a linear sequence of tree-wide commits (as we show it currently) but a git repo is much more of a branching tree structure. At a minimum we'd need to make sure things are sorted sanely if we keep the linear view, but we'd want to think about a view that's more tree-oriented. --brion 21:50, 7 August 2009 (UTC)Reply[reply]
I was thinking of storing the 160bit hex hashes in an addition rc_hash field (of course not used by svn), and use rc_id as a method of sorting them. Which brings me to your next point. Ultimately, isn't it possible to view git revisions as a linear tree? If you simply label by the date they were pushed rather than actually committed. --Svippong 00:22, 8 August 2009 (UTC)Reply[reply]
This would be really, really nice to have. Perhaps version control could be made more modular to allow other VCS in the future, too. Cmelbye 06:31, 8 August 2009 (UTC)Reply[reply]

Broken in 1.16alpha r58426

Hi, I'm using the above revision and your SQL has hit the MySQL UTF8 key limit:

ERROR 1071 (42000) at line 79: Specified key was too long; max key length is 1000 bytes

It appears to be the unique key in table code_authors. I'm running MySQL 5.051a-24.

See Bug 21407

I also get a database error when attempting to search on tags. Not all my tags are showing on the tags page, and when I click on a tab link I get an error like the following:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

SELECT cr_id,cr_id,cr_repo_id,cr_status,COUNT(DISTINCT cc_id) AS comments,cr_path,cr_message,cr_author,cr_timestamp FROM `code_rev`,`code_tags` LEFT JOIN 
`code_comment` ON ((cc_repo_id = cr_repo_id AND cc_rev_id = cr_id)) WHERE cr_repo_id = '1' AND (ct_repo_id) AND (ct_rev_id) AND ct_tag = '1-5-6' GROUP BY cr_id 

from within function "IndexPager::reallyDoQuery (SvnRevTagTablePager)". Database returned error "1054: Unknown column 'cr_repo_id' in 'on clause' (localhost)".

--Ewe2 22:03, 6 November 2009 (UTC)Reply[reply]

CodeReview Install Step: maintenance/update.php broken out of the box

Just downloaded the latest svn snapshot (revision 76358) and during the last step of running update.php, the following error occurs. Untoldpromise 00:47, 9 November 2010 (UTC)Reply[reply]

xxx@xxxx:/home/xxxxx/xxxxxx.com/wiki/extensions# php5 ../maintenance/update.php
MediaWiki 1.16.0 Updater

Going to run database updates for xxxxxx_wiki
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0
Warning: Missing argument 1 for efCodeReviewSchemaUpdates() in /home/xxxxx/xxxxxx.com/wiki/extensions/CodeReview/CodeReview.php on line 171
Fatal error: Call to a member function getDB() on a non-object in /home/xxxxx/xxxxxx.com/wiki/extensions/CodeReview/CodeReview.php on line 173
You should only use the latest svn version of extensions with the latest svn version of mediawiki (the thing you pasted says 1.16, which is quite far away from latest svn) unless the extension specifically claims it maintains backwards compatibility (and this extension makes no such claim). If you want to use mediawiki 1.16, use the version of this extension thats for 1.16. Bawolff 01:48, 9 November 2010 (UTC)Reply[reply]

usage with branches =

Hi, I would be interested in this extension however, my need would be to have a page for each branch releases and being able retrieve all under a category

Regards sancelot@free.fr

Return to "CodeReview/Archive 01" page.