When converting directory additions/replacement with project directory set to
root, _iterfiles() sometimes returned paths starting with a slash making
following svn calls to fail.
I could not reproduce the issue with hand-crafted repositories.
Report and first analysis by Clinton Chau <clinton@clearcanvas.ca>
"mtn automate stdio" will break output larger than 32kB into several packets.
This ensures that we are processing all the output on the main stream and not
only the last packet.
Monotone treats branch closing ("suspending") in a similar manner to how we do
in mercurial - a cert is added to a revision that marks the branch to be hidden.
If a subsequent commit is made, the branch is effectively reopened.
Currently the convert extension spawns a new mtn process for each
operation. For a large repository, this ends up being hundreds of
thousands of processes. The following enables usage of monotone's
"automate stdio" functionality - documented at:
http://www.monotone.ca/docs/Automation.html#index-mtn-automate-stdio-188
The effect is that (after determining that a new enough mtn executable
is available) a single long-running mtn process is used for all the
operations, using stdin/stdout to send commands and read output.
This has a pretty significant effect on the performance of some parts
of the conversion process.
Converting from subversion specifying config.svn.trunk results
in storing trunk under branch named as config.svn.trunk, where `default'
brunch is expected. Submission contains patch and test.
Subversion python bindings check was not present in svn_sink source
class which made it fail while using svn as destination repository.
Added a more maintainble svn bindings check for svn_source and svn_sink
classes.
Use field list instead of option list in convert help, because the
option list format used, with defaults and type of argument is not
supported by docutils.
The p4 command-line client sometimes fails upon doing "p4 describe"
when trying to produce a patch. (I'm guessing it's a bug in p4.)
However, "hg convert" doesn't even make use of the patch, and it can
be elided by adding "-s" to the p4 command line here.
Changes the characters used as section separators, so different ones
are used for module docstring and command docstring.
This is done because the section from the docstring will be at
different levels in the restructured text output, therefore
different symbols have to be used.
This is a followup to dd4fb29994d3, which only fixed the conversion of
patches with UTF-8 metadata.
This patch allows a changelog to have any bytes with values
0x7F-0xFF. It parses the XML changelog as Latin-1 and uses
converter_source.recode() to decode the data as UTF-8/Latin-1.
Caveats:
- Since the convert extension doesn't provide any way to specify the
source encoding, users are still limited to UTF-8 and Latin-1.
- etree will still complain if the changelog has bytes with values
0x00-0x19. XML only allows printable characters.
Given a commit author or message with non-ASCII characters in a darcs
repo, convert would raise a UnicodeEncodeError when adding changesets
to the hg changelog.
This happened because etree returns back unicode objects for any text
it can't encode into ASCII. convert was passing these objects to
changelog.add(), which would then attempt encoding.fromlocal() on
them.
This patch ensures converter_source.recode() is called on each piece
of commit data returned by etree.
(Also note that darcs is currently encoding agnostic and will print
out whatever is in a patch's metadata byte-for-byte, even in the XML
changelog.)
Also document that
- empty lines are skipped and comment are supported in author map
- whitespace is not allowed in branch map entries since we split on it
when parsing the file
This aligns the authormap option with the other three mapping options.
The old --authors option is still supported and 'hg help convert -v'
will still show it.
