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