By setting the `HGSUBVERSION_BINDINGS environment variable to either
`SWIG' or `Subvertpy', the choice of bindings can be forced at
runtime. (For ease of use, the comparison is case-insensitive.)
Examples:
% HGSUBVERSION_BINDINGS=swig hg version --svn
Mercurial Distributed SCM (version 1.6+172-b25e1ced9861)
...
hgsubversion: 1.1.2+43-276742da2d85
Subversion: 1.6.12
bindings: SWIG
% HGSUBVERSION_BINDINGS=subvertpy hg version --svn
Mercurial Distributed SCM (version 1.6+172-b25e1ced9861)
...
hgsubversion: 1.1.2+43-276742da2d85
Subversion: 1.6.12
bindings: Subvertpy 0.7.4
% HGSUBVERSION_BINDINGS=none hg version --svn
Mercurial Distributed SCM (version 1.6+172-b25e1ced9861)
...
abort: cannot use hgsubversion; bindings disabled using HGSUBVERSION_BINDINGS!
Subvertpy is, in many ways, a better interface to Subversion than the
SWIG bindings. It's faster, leaks less and offers a cleaner API. The
added wrapper is able to coexist with the SWIG wrapper, and not
enabled by default. In order to allow this, the wrapper adapts the
output from Subvertpy so that it is similar to the output from the
SWIG bindings. An example of this can be seen in the modules that work
with editors: the nested editors offered by Subvertpy had to be
flattened to work with our editor code.
This change does not activate the Subvertpy wrapper, yet, and thus
does not affect any functionality.
The docstring for SubversionRepo was technically inaccurate; not only
do we require Subversion 1.5, but the reference to a required
parameter is inaccurate, as the parameter has a default value. (To be
fair, relying on the default value is unlikely to work...)
Part of a comment in SubversionRepo.revisions() was redundant, and
could be removed.
No functionality change.
The original reason not to use property syntax was that it didn't work
with Python 2.3. Mercurial dropped support for it more than a year
ago...
No functionality change.
The Subvertpy wrapper will not need this decorator, and moving the
decorator into svnwrap will allow the wrapper to provide a no-op
replacement.
No functionality change.
The new `common' module holds code not specific to the SWIG
wrapper. Factoring it out makes providing multiple wrappers easier.
No functionality change, although imports in one test were updated.
The underscore prefix suggests that the chunk_size is a private
variable. There's no reason for this, so we remove it in preparation
for a refactoring.
No functionality change.
A recent change made core.SubversionException a member of
svnwrap. Referencing it directly makes the code ever so slightly
cleaner.
No functionality change.
Some member functions of SubversionRepo were unused, and removing them
frees other wrappers from adding possibly incorrect implementations of
them.
Two methods, `tags_at_rev' and `_get_copy_source' were completely
unused and could easily be removed. Another two methods, `branches'
and `tags' had explicit tests for them but weren't used in the code
proper; they were removed too. The START property was unnecessary and
could be removed with a tiny refactoring.
No functionality change.
The wrapper was never anywhere near functional, and with the upcoming
subvertpy wrapper, the need for it has diminished. If the
implementation is ever completed, the code can be recovered from the
history of the repository.
No functionality change.
In addition, the version output has been rejiggered a bit to mention
the version of hgsubversion first.
While at it, `svn' is changed to `Subversion', as this is its the
proper name.
Before:
% hg version --svn
...
svn bindings: 1.6.12
hgsubversion: 1.1.2+45-123ac53a6343
After:
% hg version --svn
...
hgsubversion: 1.1.2+45-123ac53a6343
Subversion: 1.6.12
bindings: SWIG
The new file contains three sections: The first one is based on the
README and contains instructions on how to use hgsubversion. The
second one mentions the most notable shortcomings of hgsubversion. The
third and final section documents how to customise hgsubversion.
Previously, using `hg clone --startrev HEAD` when the actual HEAD
revision didn't touch the prefix, would cause it to report that no
changes were found. Using last_changed_rev instead of HEAD fixes
this. In order to better test this scenario, we now clone the trunk
subdirectory of all the fixtures.
The code in fetch_branchrev() could fail under relatively obscure
circumstances: it combined two strings (path & child) by concatenating
them with '/' inserted in the middle. However, convert_rev() contains
an assertion that no touched file paths start with '/'. Combined,
these two amounted to an incorrect assumption that no files where
touched within an empty branchpath.
The entire revision is fetched using the just-added get_revision()
wrapper.
Essentially, this allows us to begin a conversion with a non-zero
start revision. As an extra safety feature, this mode is *always* used
for the very first revision, even if no start revision is
specified. For most repositories, this shouldn't matter; the entire
revision will be fetched regardless. However, there are repositories
that currently `confuse' us, such as bzr-svn conversions, and where
this is an improvement.
Calling ctx.children() for revision R visits all revisions greater than
R. If I remember my algorithmics right, that's O(n^2). Performing an
extra traversal, however, is O(n).
A quick benchmark on a repository ~20k revisions:
before: 445.27s user 1.10s system
after: 7.25s user 0.25s system
The resulting `svn' directories are exactly the same, and the tests
continue to pass.
Previously, both convert_rev() functions used parentctx.extra() to
determine the branch to pass to meta.movetag(). This assumed that the
branch name stored in the changeset matches the internal branch. The
introduction of branch maps made this assumption unsafe, however: Now,
the Mercurial branch can be completely unrelated to the origin of the
changeset.
It turns out, however, that movetag() already has sufficient knowledge
to determine the branch. Given the hash of the new changeset to be
tagged, we walk its ancestors until we find an open changeset, which
we then know to be the originating branch. This assumes that there
were `few' commits made to the tag; an assumption I would consider
reasonable.
I noticed these in the traceback filed as issue2261 in the Mercurial
bug tracker. We should always fail in cases where the Subversion
server gives us invalid data, so using assertions is wrong.
Letting a KeyError propagate when the supplied revision has no
conversion record on file isn't terribly helpful. At least not when
this KeyError merely states that the key missing is
'convert_revision'. It's much better to preemptively check for it,
detect that it's missing, and then raise an exception with a
descriptive message.
Mercurial 1.6 introduces two new methods for repo subclasses -- pushkey and
listkeys -- to support pushing/pulling bookmarks between hg repositories.
(See mpm's blog post http://www.selenic.com/blog/?p=644 for details.)
Unfortunately, these are only defined in the subclasses, and not in the repo
base class. Perhaps the bookmarks extension should also be checking the repo
for pushkeys capability by calling repo.capable('pushkey') to check.
It doesn't.
In the meantime, we can implement these ourselves.
svnrepo should declare these methods since it is derived directly from repo.
They do nothing -- listkeys merely returns an empty dictionary; pushkey
returns False; this is the behaviour of httprepo or sshrepo when the remote
end is running an earlier version of Mercurial.
svnlocalrepo should not declare these methods since it derives from a
subclass of localrepo, which already will have them, unless some other badly
behaved extensions are doing something intensely weird.
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.
