TO DO

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 causes 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.