Last modified: 2013-10-31 11:44:30 UTC
Right now updating either needs to happen through shell with svnImport.php, or if one knows the current HEAD via an API POST request. I created a gadget that uses the latter but the problem with it is that it's currently not very usable. What it does is this: * Adds an "update" tab to #contentSub * Scraps html for reponame (#contentSub a:first .text()) * action=query&list=coderevisions limit=1 to get last checked out rev id * display dropdown menu with [1,5,10,25,50,100]. * When submitting the form add the chosen number to lastRevId and make a post request to action=codeupdate&repo=reponame&rev=calculatedrevid * Problem: If the rev is too high it fails and does nothing so we end up updating 1 rev at a time untill it throws an error... A way to do action=codeupdate&rev=HEAD (or something like that) would be much appreciated. svnImport.php does pull it off, so perhaps that system can be re-used, copied or invoked.
shell: svn info http://pathtorepo/svnroot | grep Revision pecl: svn_ls( 'http://pathtorepo/svnroot' ); highestRev = 0; foreach rootfolder in result get max of rootfolder['created_rev'] and highestrev proxy might be doable, or just not implement... And then fallback to the current way
svnImport.php is mainly intended to be run for initial setup, and grabs batches of $wgCodeReviewImportBatchSize (default 400) revisions starting from #1. If you ask for too many, the entire fetch request fails and it backs off (400 => 100 => 25 => 6 => 1) until it finds a small enough number to complete the last batches. This is probably not super efficient for the case where usually there will be 0 or a handful of new commits. Need to either add some kind of logic to request the current HEAD revision from the repository, or consider ways to have it ramp _up_ from one or two commits at a time to larger chunks if it turns out we're way behind (if we have 10000 revs to catch up on, we don't want to do 10k server round-trips in series!)
To clarify, my use of this extension at the time made it not feasible to get push notifications on-commit (like we do at Wikimedia, the codereview-proxy automatically calls the codeupdate API from a post-commit hook), do I needed a way to have it pull or poll. Anyway, afaik this could easily run from cron, not just why I didn't just do that.
