comparison tests/test-convert-svn-source.t @ 23583:a8edcb9c1199

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.
author Augie Fackler <raf@durin42.com>
date Fri, 12 Dec 2014 15:53:17 -0500
parents c63a09b6b337
children 4d2b9b304ad0
comparison
equal deleted inserted replaced
23582:7559dc8c4238 23583:a8edcb9c1199
237 scanning source... 237 scanning source...
238 sorting... 238 sorting...
239 converting... 239 converting...
240 1 init projA 240 1 init projA
241 0 adddir 241 0 adddir
242
243 Test that a too-new repository format is properly rejected:
244 $ mv svn-empty/format format
245 $ echo 999 > svn-empty/format
246 It's important that this command explicitly specify svn, otherwise it
247 can have surprising side effects (like falling back to a perforce
248 depot that can be seen from the test environment and slurping from that.)
249 $ hg convert --source-type svn svn-empty this-will-fail
250 initializing destination this-will-fail repository
251 file:/*/$TESTTMP/svn-empty does not look like a Subversion repository to libsvn version 1.*.* (glob)
252 abort: svn-empty: missing or unsupported repository
253 [255]
254 $ mv format svn-empty/format