Last modified: 2012-03-16 10:56:41 UTC
I am not sure if this is a problem with my local CR or SVN configuration, or whether it is a general issue. I don't recall experiencing it before (I've had about a 6 month break from using CR) so it may be a regression, or it may be due to a server move. Here is the output that I get when I run svnImport.php for my sandbox repo: $ php svnImport.php sandbox Using SubversionShell adaptor IMPORT FROM REPO: sandbox Last stored revision: 118 Syncing from r119 to HEAD... svn: No such revision 119 svn: No such revision 119 svn: No such revision 119 svn: No such revision 119 svn: No such revision 119 Pre-caching skipped. Done! The latest revision of the repo is 118, which is also the latest revision in MW (i.e. it is fully up-to-date). The reason we are getting the error repeatedly, is that svnImport uses a large block-size on its first attempt, which is then reduced repeatedly until it fails with a block-size of 1. If I add some code to print the command-line that is actually executed in svn_log(), I get the following: Using SubversionShell adaptor IMPORT FROM REPO: sandbox Last stored revision: 118 Syncing from r119 to HEAD... LC_ALL=en_US.utf-8 svn log -v -r'119':'518' --non-interactive 'URL' svn: No such revision 119 LC_ALL=en_US.utf-8 svn log -v -r'119':'218' --non-interactive 'URL' svn: No such revision 119 LC_ALL=en_US.utf-8 svn log -v -r'119':'143' --non-interactive 'URL' svn: No such revision 119 LC_ALL=en_US.utf-8 svn log -v -r'119':'124' --non-interactive 'URL' svn: No such revision 119 LC_ALL=en_US.utf-8 svn log -v -r'119':'119' --non-interactive 'URL' svn: No such revision 119 Pre-caching skipped. Done! Running the svn log command from the command-line, gives the same 'No such revision' response. I have tested this with svn 1.3.2 and svn 1.6.6 and get the same results for both. Basically, the error is harmless - it is correct, there is no revision 119 - however it should not be output. Note that you also get a similar error when there are new revisions, in amongst the successful log imports. As far as I can see, there are no functional problems caused by this.
I believe this is normal; since you didn't specify what version to run up to it just keeps going from its last point until something runs out. svnImport.php is optimized for doing initial bulk import, with the expectation that small cumulative updates will be done by having your SVN repo's post-commit scripts call the API: https://www.mediawiki.org/wiki/Extension:CodeReview#Automating_updates It would probably not be too hard to make it check the latest revision at the start of the import and only go up to there (but of course if you then get more commits during... :)
I think the difference between 'old' behaviour and 'new' behaviour that I have experienced is due to the fact that the old server was WAMP-based and the new one is LAMP. I've re-run the svnImport.php script, using the same MW and CR versions as my Windows box, for the same repo, and I just get the following, which is what I would consider the 'expected result': Using SubversionShell adaptor IMPORT FROM REPO: sandbox Last stored revision: 118 Syncing from r119 to HEAD... Pre-caching skipped. Done! Interestingly, I tried running the same svn log directly from the command-line on the Windows machine: > svn log -v -r119:518 --non-interactive URL svn: No such revision 518 Therefore the error is generated in all cases, but in the Windows environment it is not appearing on the screen for some reason. From that, and a bit of sleuthing inside wfShellExec(), it looks like, on Windows, anything sent to stderr is discarded by the passthru() function, whilst on Linux stderr always gets sent to the output stream, somehow bypassing any output-buffering that has been set up, such as we use in wfShellExec(). I suspect the answer to this fix is to add " 2>&1" to the end of the $cmd variable in wfShellExec() when not running on Windows, prior to executing the command, so all output is caught. Sound reasonable? Or are there some ramifications there I've not considered?
(In reply to comment #1) > I believe this is normal; since you didn't specify what version to run up to it > just keeps going from its last point until something runs out. btw, as far as I can see there is no way of specifying which version to run up to using svnImport.php. We just have the --start argument which allows you to specify a starting revision, but it will always go up to HEAD. On the surface it seems like the API behaves differently, and allows you to specify a single revision to fetch. Perhaps svnImport should be updated to behave likewise, as it seems a bit of an odd choice to opt for the overhead (and additional point of failure) of a web request when the CLI script is sitting there on the same server. However, either way, that is not really relevant to the issue logged in this bug.
