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" <danielsh_at_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
>
Received on 2016-12-03 02:48:39 CET