Two imports used when printing tracebacks were missing. They were
easily missed as this code isn't exercised unless an exception happens
to be raised during the execution of one of the `svn' subcommands.
Importing `SubversionException' directly from `svn.core' is a layering
violation: Anything within the Subversion bindings should only be
accessed via svnwrap.
The advantages to doing this are twofold: we only need to intercept
missing bindings in one place, and we have the option of supporting
alternate bindings. As an added bonus, the recently-added support for
intercepting missing Subversion bindings actually works.
Two error messages are tweaked to remove `It appears...' from one
error message (just blaming Subversion instead) and make both errors
include the URL in the suggested command line.
Instead of aborting with a generic message when Subversion bindings
are missing, provide a helpful message. Also, the version check is
refactored to make it easier to bump our requirements in the
future. Finally, error messages are shorten so they fit in 80 columns
along with the standard `abort: ' prefix.
Previously, the parsed URL - with credentials removed - was used for
instantiating a new svnremoterepo instance. One option for fixing this
is using the unparsed URL for this instantiation. An even better
option, however, is to simply reuse the instance passed to the
function as `source'.
The previous calculation was wrong and could lead to negative totals;
it substracted a revision number from totals, from which the start
revision has already been subtracted.
editor: move dependancy on Subversion bindings to svnwrap package.
In the editor, this involves importing the superclass of `HgEditor' as
`svnwrap.Editor'. Additionally, the `delta.svn_txdelta_apply()'
function has been abstracted away into a simpler interface, stored in
`svnwrap.apply_txdelta()'.
This uses the first converted revision as an offset, and then uses
(r.revnum - offset) as the current item index and (HEAD - offset) as
the total so that we always show a "real" progress number for the case
where we're cloning only part of the svn repository.
getcopies() assumed that copies where happening withing the current branch.
This is wrong when a branch replaces another, and used to generate wrong copy
records when copy sources existed in parent revision but were coming from an
unrelated revision.
Known failures:
- comprehensive/test_verify on replace_branch_with_branch: replaced files
content is incorrect
- comprehensive/test_stupid_pull on replace_branch_with_branch: very stupid
mode does not handle replacements correctly.