I had found some of the magic formulas before, which was how I was aware of looking into the .svn directory. Thank you for the detailed responses which I can wrap into local commands, and should be sufficient for my needs.
However I believe a supported, documented, and forward compatible way is preferable; given the volume of questions that come up when googling it seems to be a popular item. The problem I am working on is to have a bash script exit early with a clear error message if: - the script was checked out in a svn workspace version that is not expected, older or newer. - the script is executed on a host that has an old version of svn that cannot work with the workspace. - the script is executed on a host that has a newer version of svn, such that the workspace would have to be upgraded. It is an issue when there are manual operations in a distributed environment with a shared file system. It is a common error to accidentally perform manual operations on a host that has the wrong svn version. Especially since the old versions have to be retained on some workstations. Thanks for the quick response Marc On Dec 2, 2016 12:13 PM, "Daniel Shahaf" <danie...@apache.org> wrote: > Marc Pawlowsky wrote on Fri, Dec 02, 2016 at 11:50:14 -0500: > > There is a lot of effort and hacks on determining what SVN database > > version is being used on the working copy. Usually resorting to > > examining the internal contents of a .svn/* file. > > The incantation is: > > format_number=`head -n1 .svn/format` > if [ "$format_number" -eq 12 ]; then > format_number=`sqlite3 .svn/wc.db 'pragma user_version;'` > fi > > This inspects .svn directly, and as such is *not* guaranteed to be > forward compatible. (We don't anticipate breaking it, but we may.) > > See SVN_WC__VERSION (in wc.h) for the format-number-to-minor-version map. > > > For future releases it would be nice if there was a command to display > > if the current working copy is at the same level as the svn version > > being used, and if not if it is upgradable. > > > > The use case is to be able to detect early on in a build process if > > the wrong version of SVN was used. > > > > Couldn't you run, say, 'svn info >/dev/null' and see whether it gives > error E155036 or not? > > % ./tools/dev/which-error.py E155036 > 00155036 SVN_ERR_WC_UPGRADE_REQUIRED > > Going through your scenarios: > > > svn upgrade --check-current . > > CURRENT: yes > > UPGRADABLE: yes > > VERSION: 20 > > exit code 0 to indicate no upgrade is needed > > 'svn info' will exit 0. > > > svn upgrade --check-current . > > CURRENT: NO > > UPGRADABLE: yes > > VERSION: 19 > > exit code 1 to indicate upgrade is needed > > 'svn info' will report E155036 (and 'svn upgrade' will succeed). > > > svn upgrade --check-current . > > CURRENT: NO > > UPGRADABLE: no > > VERSION: unknown > > exit code 2 to indicate upgrade cannot be performed > > Only happens in corner cases (e.g., > <https://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade>). > 'svn info' will report E155036 and 'svn upgrade' will error out. > > I'm not sure whether we have today a way to distinguish "non-current, > non-upgradeable" from "non-current, upgradeable", without actually > running 'svn upgrade'. Perhaps others can speak to that. > > > > > To be clear, I'm not opposed to adding such functionality; I'm simply > trying to understand why the use-case can't be addressed with existing > features. > > Cheers, > > Daniel >
