Previously, property changes to links caused 'link ' to be prepended
to the link destination. Removing a line that prepended it in
Revision::set() appears to fix it. In these cases, the "file marked as
link, but contains data" warning might be triggered. This should be
safe, so it's lowered to a note and the language made less conclusive.
In order to test this, extra revisions are added to the
'symlinks.svndump' fixture. As one of the new revisions add a link
that points to 'link to this', a check that asserted that link
destinations must not start with 'link ' was removed. This change is
safe, as the test later on asserts exact equality with the contents of
the 'links' dictionary.
This uses a separate map, since the purpose is very different from the purpose
of the TagMap that we currently have. It seemed to me that unifying both will
only serve to make the implementation more complicated. The name TagRenames
is not that elegant, but I didn't have any better idea. Feel free to change.
Calling subvertpy.wc.api_version() will raise an AttributeError with
versions of Subvertpy prior to 0.7.4. This AttributeError completely
breaks hgsubversion, as our infrastructure assumes that only
ImportErrors are raised during imports.
Delaying the call to api_version() until after the Subvertpy version
check should make things work again.
The way hgsubversion handles URLs that may or may not be quoted is
somewhat fragile. As part of fixing issue 132 in 06d89c2063a2, the
path component of URLs was always quoted. The URL has been attempted
encoded since the initial check-in.
The fix from 06d89c2063a2 was incomplete; reverting it allows us to
clone a URL with a '~' in it.[1] Encoding the URL as UTF-8 seldom
works as expected, as the default string encoding is ASCII, causing
Python to be unable to decode any URL containing an 8-bit
character.
The core problem here is that we don't know whether the URL specified
by the user is quoted or not. Rather than trying to deal with this
ourselves, we pass the problem on to Subversion. Then, we obtain the
URL from the RA instance, where it is always quoted. (It's worth
noting that the editor interface, on the other hand, always deals with
unquoted paths...)
Thus, the following invariants should apply to SubversionRepo
attributes:
- svn_url and root will always be quoted.
- subdir will always be unquoted.
Tests are added that verify that it won't affect the conversion
whether a URL is specified in quoted or unquoted form. Furthermore, a
test fixture for this is added *twice*, so that we can thoroughly test
both quoted and unquoted URLs. I'm not adding a test dedicated to
tildes in URLs; it doesn't seem necessary.
[1] Such as <https://svn.kenai.com/svn/winsw~subversion>.
First, use of :hg:`...` is replaced with ``hg ...``. The former syntax
isn't useful outside core Mercurial. Second, a few instances of `...`
are replaced with ``...``. The minirst parser doesn't distinguish
between the two, but using docutils, the former results italics and
the latter in fixed width text. Finally, a few extra ``...`` are added.
With these changes, we could process the help topic with rst2html and
put it somewhere appropriate on the internet.
This is a regression that was brought to my attention in #mercurial:
hgsubversion breaks the --update flag. The cause is that we call
hg.clone() directly rather than the original wrapped function. A
comment in 'wrapper.py' noted that the call to hg.clone() should be
kept in sync with 'mercurial/commands.py'. That didn't happen.
The original reason for calling hg.clone() directly was that we needed
its return values. Another wrapper is added (and cleared) within
clone() to get them anyway.
The --branch option to clone, pull, etc., was introduced in 1.5, and
our handling of it assumes that Mercurial also provides it. As a
result, both documentation and the test are changed to reflect this.
This causes an access to the svnurl property to connect to the
repository. One of the tests uses an invalid URL, and so had to be
updated to bypass this.
The previously used method for checking the Subversion version,
subvertpy.wc.version(), reported back the version of the runtime
library used. This is not what we're interested in; we want to know
what version it was compiled against.
These functions were not available in Subvertpy 0.7.3, necessitating
the earlier bump of the version requirement to 0.7.4.
The core logic is cleaned up and moved to the wrappers module. The
test made to test that it works with original Mercurial changesets, is
cleaned up so that it can be more easily extended in the
future. Finally, documentation is added for the feature.
