1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
= 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.
|
