This effectively conditionalizes 7ac081713920. Some Linux distributions (like
CentOS 7) use really old versions, and the change referenced was causing
exceptions to be thrown.
Even though the deprecation warning says 'since 2.5.0', it wasn't marked as such
in 2.5.1, but is by 2.6.0. This was tested with 2.4.2 and 2.6.0 with
PYTHONWARNINGS=::DeprecationWarning, and both paths were exercized.
The `hg lfconvert --to-normal` command uses the convert extension internally to
work its magic, but that produced devel-warn messages if the convert extension
wasn't loaded by the user. The test in 658e7a6d93e0 (modified here) wasn't
showing the warnings because the convert extension was loaded via $HGRCPATH.
Most of the config options default to None/False, but 'hg.usebranchnames' and
'hg.tagsbranch' are supposed to default to True and 'default' respectively.
The first iteration of this was to ui.setconfig() inside lfconvert, to force the
convert extension to load. But there really is no precedent for doing this, and
check-config complained that 'extensions.convert' isn't documented. Yuya
suggested this alternative.
This partially backs out 448e09d8859d.
The next patch will wrap the conversion code, in order to write out a
requirement for 'lfs' when appropriate. Wrapping convcmd.convertsink() in an
afterloaded callback works fine when the convert extension is enabled by the
user. The problem here is that lfconvert uses the convert extension, whether or
not it was formally enabled by the user.
My first attempt was to have lfs install an afterloaded callback that would wrap
the convert sink if convert was loaded, or wrap lfconvert if it wasn't. Then
the lfconvert override could install an afterloaded callback to try wrapping the
convert sink again, before calling the original lfconvert. But that breaks down
if largefiles can't load the convert extension on the fly. [1] Further, some
tests were failing with an error indicating that the size of the afterloaded
list changed while iterating it.
Yuya mentioned that maybe some bits of convert could be moved into core, but I'm
not sure where to draw that line. The convertsink() method depends on the list
of sinks, which in turn depends on the sink classes.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108038.html
This seems like basic info to have, and will be used shortly when deciding
whether or not to wrap the class for lfs conversions.
The other option is to just add a function to each class. But this seems better
in that the strings aren't duplicated, and the constructor for most of these
will run even if the VCS isn't installed, so it's easier to catch errors.
This import was failing (because its invalid) which was resulting in
the following tests failing with chg running:
- test-convert-bzr.t
- test-convert-bzr-directories.t
- test-convert-bzr-ghosts.t
- test-convert-bzr-treeroot.t
- test-convert-bzr-114.t
- test-convert-bzr-merges.t
This commit fixes the import which in turn fixes the tests.
Test Plan:
Ran the aforementioned tests with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D936
Converting from CVS to Mercurial assumes that CVS log messages in "cvs
rlog" output are encoded in UTF-8 (or basic Latin-1). But cvs itself
is usually unaware of encoding of log messages, in practice.
Therefore, if there are commits, of which log message is encoded in
other than UTF-8, log message of corresponded revisions in the
converted repository will be broken.
To avoid such broken log messages, this patch transcodes CVS log
messages by encoding specified via "convert.cvsps.logencoding"
configuration.
This patch accepts multiple encoding for convenience, because
"multiple encoding mixed in a repository" easily occurs. For example,
UTF-8 (recent POSIX), cp932 (Windows), and EUC-JP (legacy POSIX) are
well known encoding for Japanese.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
Empty changelist descriptions are valid in Perforce. If we encounter one of
them we are currently running into an IndexError. In case of empty commit
messages set the commit message to **empty changelist description**, which
follows Perforce terminology.
