Extension talk:CodeReview/LQT Archive 1

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? --80.129.186.50
 * As stated in the box at the right, this extension requires MediaWiki 1.14alpha. i Alex  18:35, 11 November 2008 (UTC)
 * Damn it. Didn't saw that. Thanks for pointing it out ;-) --80.129.186.212

Updates
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)


 * 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)


 * Excellent point, this wasn't documented! I've added a sample setup in Extension:CodeReview. --brion 21:47, 7 August 2009 (UTC)

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)

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)


 * Been pondering this myself... ;) At a minimum there's a couple things that would need to be taken into account:
 * 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.
 * 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)
 * 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)
 * 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)