Before you try to modify this code, read hacking.adoc.

  • Progress reporting within files for large files with many commits?

  • The QED repo in the tests directory raises a branch cycle error.

This may reveal a bug in the second toposort function. There is a recipe for creating a close-to-minimal branch cycle testcase in tests/README.

  • tests/vendor.testrepo reveals an apparent bug in the new vendor-branch code.

Created as follows:

        mkdir vend-test1.vend
        cd vend-test1.vend
        echo 1 > FILE1
        cvs import -m v1 vend-test1 vend vend_1_0
        cd ..
        cvs co vend-test1
        cd vend-test1
        echo 1 > FILE2
        cvs add FILE2
        cvs commit -m c1
        cd ../vend-test1.vend/
        echo 2 > FILE1
        cvs import -m v2 vend-test1 vend vend_1_1
        cd ../vend-test1/
        cvs up
        echo 2 > FILE2
        cvs commit -m c2
        cvs tag lost-repo-state
        echo 3 > FILE1
        cvs commit -m c3

Loz says: Subset tag will probably paper over the problem. Imagine the repo didn’t have the +"lost-repo-state" tag. There wouldn’t be a commit for this state in the git repo."

  • Issue a warning when the same tag is attached to multiple commits. At the moment it’s just silently reported attached to the last.

  • Loz says: consider these two files from the emacs historic:

lisp/progmodes/cperl-mode.el lisp/textmodes/flyspell.el

These have differently named 1.1.1 branches (ILYA and FLYSPELL). Merging them into the same import-1.1.1 branch casues all sorts of weirdness with tagging. The tags (e.g. Ilya_5_23) only point to commits in one branch.

I think they need to treated as separate branch heads.

This didn’t work with the old or new vendor branch code.

  • When running multithreaded, the test

find tests/t9601.testrepo -name *,v | sort | cvs-fast-export >/dev/null

intermittently fails with error "cvs-fast-export fatal: child commit emitted before parent exists". This is known to be related to timestamp order not being well defined (many of the timestamps in the repo masters are identical) and commits being sorted into an order inconsistent with their parent-child partial ordering by the canonicalization code. It can be prevented with -F. A root-cause fix would be to improve the export.c:canonicalize() function to do a toposort assisted by date.