Re: Feature Request: svn upgrade [--check][--check-current]

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-02 18:13:53 CET