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 http://www.serpentine.com/bugzilla/show_bug.cgi?id=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).
Degrading to bug, workaround exists.
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.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:07 EDT --- This bug was previously known as _bug_ 2084 at http://mercurial.selenic.com/bts/issue2084
Fixed by http://selenic.com/repo/hg/rev/61f1223ab358 Ben Goswami <bengoswami@fb.com> splicemap: move parsesplicemap to convcmd.py (issue2084) parsesplicemap is only referenced from convcmd.py This move is necessary to enable other changes related to this issue (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/58e782f076e7 Ben Goswami <bengoswami@fb.com> splicemap: improve error handling when source is hg (issue2084) 1. Introduced 2 levels of error handling for splicemap files a. Check the splicemap file for rules which are same across different types of source repos. This is done through enhancing parsesplicemap function b. Check revision string formats. Each repo may have their own format. This is done usign checkrevformat function c. Implemented the above two for hg (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/478a04605ce1 Ben Goswami <bengoswami@fb.com> splicemap: improve error handling when source is git (issue2084) Implemented similar error handling that is done for hg in an earlier revision. These are: a. add checking for splicemap file format b. add checking for each revision string formats (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/83973dc1bfe9 Ben Goswami <bengoswami@fb.com> splicemap: improve error handling when source is subversion (issue2084) Implemented error handling on splicemap file when source is subversion (This checks are similar to when source is hg or git). The revision string is expected to be of svn:<uuid><path>@<number> format. the test case has been enhanced to check this format. (please test the fix)