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>
The sort modes flags and convert.cvsps options were indented while the
convert.hg, convert.svn, and convert.p4 options were not. I've now
un-indented all of them.
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
Convert now handles errors from p4 during conversion more gracefully.
If keyword expansion is enabled in a P4 file then keywords will be
unexpanded in hg.
Added testcase for p4 filetypes and keyword (un)expansion.
This testcase ignores UTF and Apple files to avoid binary data.
Edited by pmezard: fixed collation issue on OSX
This records the branches starting at individual CVS file revisions,
using the symbolic names map rather than just the branches
information. This information is used to generate Mercurial
changesets. Despite the changes, the CVS conversion still suffers
heavily from cvsps' deficiencies in generating a correct
representation of the CVS repository history.