It can be really confusing that format errors are undetected or silently
ignored. Also, the help text is misleading:

$ hg help convert

[...]Each entry contains a key, followed by a
space, followed by one or two comma-separated values:

      key parent1, parent2
[...]

It shows a space after comma but actually no space is allowed except the one
between key and parent1.

Degrading to bug, workaround exists.

The convert command ignores lines in the splicemap that it does not know what to do with. This 
includes:

- Mercurial revisions specified using the short, 12-digit hash;
- Subversion revisions naively thought as being specific enough with the revision number only 
(see #2083);
- Two parents separated by a space instead of a comma, as per the incorrect help text of a 
previous version (see #1582).

The expected, nice behaviour would be:

- if the revision ID in the source revision control (the key) does not match the format for a 
revision ID of the source repository, fail as soon as the line is read, i.e. before starting a 
possibly lengthy conversion that will obviously not turn out as the user expected (since he 
took the trouble of writing that splicemap line);

- if one or both of the parents do not match the format for a revision ID of the source 
repository or for a full, 40-digit Mercurial revision hash, fail immediatly;

- if a line does not match the either "rev1 rev2" or "rev1 rev2,rev3", i.e. the formats for 
one or two parents, specifically if rev2 and rev3 are separated by a space instead of a comma 
or if there is extra, non-whitespace text after the laste revision, fail immediately;

- if a splicemap line had no effect because the source revision or one or both of the parents 
were not found (e.g. typo or incorrect path or UUID for a Subversion revision), do not fail 
(since the conversion already happened) but warn the user with a list of ignored splicemap 
lines at the end of the conversion.

The idea here is that I wouldn't have lost half a day trying to convert a very basic 
Subversion repository with only one merged branch if Mercurial had complained about my 
mistakes (basically all of the above). I would have fixed them one by one and it would have 
been dealt with in an hour. I would even not have suffered too much from bug #1582 (because of 
course, I first read the incorrect text, then after trying for a couple of hours updated 
Mercurial to take advantage of the branchmap option, but didn't notice the correction until I 
saw the example line in http://mercurial.selenic.com/bts/issue1764).