You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marc Pawlowsky <ma...@gmail.com> on 2016/12/02 16:50:14 UTC
Feature Request: svn upgrade [--check][--check-current]
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.
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.
Examples:
svn upgrade --check .
CURRENT: yes
UPGRADABLE: yes
VERSION: 20
exit code 0 to indicate upgradable, which should be a no-op
svn upgrade --check .
CURRENT: no
UPGRADABLE: yes
VERSION: 19
exit code 0 to indicate upgradable
svn upgrade --check .
CURRENT: no
UPGRADABLE: no
VERSION: unknown
exit code non-zero to indicate not upgradable
svn upgrade --check-current .
CURRENT: yes
UPGRADABLE: yes
VERSION: 20
exit code 0 to indicate no upgrade is needed
svn upgrade --check-current .
CURRENT: NO
UPGRADABLE: yes
VERSION: 19
exit code 1 to indicate upgrade is needed
svn upgrade --check-current .
CURRENT: NO
UPGRADABLE: no
VERSION: unknown
exit code 2 to indicate upgrade cannot be performed
Re: Feature Request: svn upgrade [--check][--check-current]
Posted by Daniel Shahaf <da...@apache.org>.
Marc Pawlowsky wrote on Fri, Dec 02, 2016 at 20:48:16 -0500:
> 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.
>
I don't recall it ever being asked before on this list.
That said, using the error codes should be forward compatible. The
other error code you should watch for is SVN_ERR_WC_UNSUPPORTED_FORMAT:
% svn co -q file://$PWD/r wc
% rm wc/.svn/wc.db
% echo 99 >wc/.svn/format
% echo 99 >wc/.svn/entries
% svn info wc
svn: E155021: This client is too old to work with the working copy at '/tmp/tmp.P4dTltFcw5/wc' (format 99).
> 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.
Using SVN_ERR_WC_UNSUPPORTED_FORMAT, SVN_ERR_WC_UPGRADE_REQUIRED, and
`svn --version -q`, you can implement your script without reliance on
any implementation details.
You should probably handle SVN_ERR_WC_CLEANUP_REQUIRED too:
% ./tools/dev/which-error.py list | grep CLEANUP
00155037 SVN_ERR_WC_CLEANUP_REQUIRED
Cheers,
Daniel
Re: Feature Request: svn upgrade [--check][--check-current]
Posted by Marc Pawlowsky <ma...@gmail.com>.
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" <da...@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
>
Re: Feature Request: svn upgrade [--check][--check-current]
Posted by Daniel Shahaf <da...@apache.org>.
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