convert: on svn failure, note libsvn version (issue4043)
We have our own fast-path logic to see if something passes a sniff
test for being a Subversion repository, but it's possible for a user
to svnsync a repo using svn 1.8 and then use svn 1.7 bindings (as in
the bug) to try and convert the repo. If we at least tell the user the
version of libsvn that we used, they might get enough of a hint to
check on their own for format incompatibilities between their
svn{admin,sync} and the libsvn used by hg.
--- a/hgext/convert/subversion.py Mon Dec 15 13:32:34 2014 -0800
+++ b/hgext/convert/subversion.py Fri Dec 12 15:53:17 2014 -0500
@@ -318,8 +318,12 @@
self.uuid = svn.ra.get_uuid(self.ra)
except SubversionException:
ui.traceback()
- raise NoRepo(_("%s does not look like a Subversion repository")
- % self.url)
+ svnversion = '%d.%d.%d' % (svn.core.SVN_VER_MAJOR,
+ svn.core.SVN_VER_MINOR,
+ svn.core.SVN_VER_MICRO)
+ raise NoRepo(_("%s does not look like a Subversion repository "
+ "to libsvn version %s")
+ % (self.url, svnversion))
if rev:
try:
--- a/tests/test-convert-svn-source.t Mon Dec 15 13:32:34 2014 -0800
+++ b/tests/test-convert-svn-source.t Fri Dec 12 15:53:17 2014 -0500
@@ -239,3 +239,16 @@
converting...
1 init projA
0 adddir
+
+Test that a too-new repository format is properly rejected:
+ $ mv svn-empty/format format
+ $ echo 999 > svn-empty/format
+It's important that this command explicitly specify svn, otherwise it
+can have surprising side effects (like falling back to a perforce
+depot that can be seen from the test environment and slurping from that.)
+ $ hg convert --source-type svn svn-empty this-will-fail
+ initializing destination this-will-fail repository
+ file:/*/$TESTTMP/svn-empty does not look like a Subversion repository to libsvn version 1.*.* (glob)
+ abort: svn-empty: missing or unsupported repository
+ [255]
+ $ mv format svn-empty/format