Fix as proposed by Frank Kingswood.
Avoids
UnboundLocalError: local variable 'mode' referenced before assignment
when cvs fails.
This alsa partially fixes issue1592.
For a CVS repository checked out with "cvs co .", the prefix used to strip of
what we get from CVS was previously erroneously set to "repopath/.".
We now prevent the dot to be added.
Test folded in test-convert-cvs and simplified by Patrick Mézard
<pmezard@gmail.com>.
The bzrlib try to import the ElementPath module but had a fallback in
case the import fails. Lazy import of this module leads to later
failure.
The bzrlib is used by the convert extension.
Otherwise when processing a changeset that in fact changes no files
(perhaps due to bug in import from CVS) can get something like:
unexpected svn output:
abort: unable to cope with svn output
Bug report and patch draft by Jesse Glick <jesse.glick@sun.com>
convert extension tries to guess the remote repository type with HTTP probes.
Unfortunately, it does not handle authentication or HTTPS handshakes, so regular
svn repositories may be excluded. Instead, when a non-404 error is retrieved,
we keep trying with the svn bindings. The drawback is missing svn bindings will
make the conversion to fail even for non-svn targets. This can be avoided with
--source.
The Perforce convert extension uses the p4 -G command line option and
marshal.load to obtain information about the history of a Perforce depot.
The method marshal.load must be provided with a binary stream (mode='rb') in
order to function reliably. Certain changelist descriptions or other elements
in a depot history could trigger a premature EOFError, causing the conversion
process to fail.
This may resolve the issue discussed in the following thread:
http://www.selenic.com/pipermail/mercurial/2009-July/026813.html
When using hg.tagsbranch, all conversions fail at
transcribing the source repo topology with conversion
scenarios interleaving:
- initial repo conversion,
- then upstream tag
- then later incremental conversion
The problem is caused by the usage of the last source
revid as source revid for the tagnode in the revision
map.
On a later incremental conversion, when resolving some
child commit of the true last source revid, convert
will parent the nodes to the tag node. If using
tagsbranch you get a bad topology where all incremental
commit nodes end up in the tag branch.
Analysis and test by Edouard Gomez <ed.gomez@free.fr>