Fossil SCM
Finally committing another disabled integrity constraint for changesets, explanations in the comments.
Commit
fd93aa26a6abff8a2e7539c7c50f108ab6410c3a
Parent
c78475148507669…
1 file changed
+49
-23
+49
-23
| --- tools/cvs2fossil/lib/c2f_integrity.tcl | ||
| +++ tools/cvs2fossil/lib/c2f_integrity.tcl | ||
| @@ -660,33 +660,59 @@ | ||
| 660 | 660 | WHERE U.count > 1 |
| 661 | 661 | AND B.bid = U.iid |
| 662 | 662 | AND S.sid = B.sid -- get symbol of branch |
| 663 | 663 | AND P.pid = S.pid -- get project of symbol |
| 664 | 664 | } |
| 665 | - # All branches have to agree on the LOD their changeset | |
| 666 | - # belongs to. In other words, all branches in a changeset have | |
| 667 | - # to refer to the same line of development. | |
| 668 | - # | |
| 669 | - # Instead of looking at all pairs of branches in all | |
| 670 | - # changesets we generate the distinct set of all LODs | |
| 671 | - # referenced by the branches of a changeset, look for those | |
| 672 | - # with cardinality > 1, and get the identifying information | |
| 673 | - # for the changesets found thusly. | |
| 674 | - CheckCS \ | |
| 675 | - {All branches in a changeset have to belong to the same LOD} \ | |
| 676 | - {: Its branches disagree about the LOD they belong to} { | |
| 677 | - SELECT T.name, C.cid | |
| 678 | - FROM changeset C, cstype T | |
| 679 | - WHERE C.cid IN (SELECT U.cid | |
| 680 | - FROM (SELECT DISTINCT CI.cid AS cid, B.lod AS lod | |
| 681 | - FROM csitem CI, changeset C, branch B | |
| 682 | - WHERE CI.iid = B.bid | |
| 683 | - AND C.cid = CI.cid | |
| 684 | - AND C.type = 2) AS U | |
| 685 | - GROUP BY U.cid HAVING COUNT(U.lod) > 1) | |
| 686 | - AND T.tid = C.type | |
| 687 | - } | |
| 665 | + if 0 { | |
| 666 | + # This check has been disabled. When the converter was run | |
| 667 | + # on the Tcl CVS several branches tripped this | |
| 668 | + # constraint. One of them was a free-floating branch, and | |
| 669 | + # its handling has been fixed by now. The others however | |
| 670 | + # seem semi-legitimate, in the sense that they show | |
| 671 | + # inconsistencies in the CVS history the user is not | |
| 672 | + # really able to solve, but it might be possible to simply | |
| 673 | + # ignore them. | |
| 674 | + | |
| 675 | + # For example in Tcl we have a branch X with a prefered | |
| 676 | + # parent Y, except for a single file where the prefered | |
| 677 | + # parent seems to be created after its current parent, | |
| 678 | + # making re-parenting impossible. However we may be able | |
| 679 | + # to ignore this, it should only cause the branch to have | |
| 680 | + # more than one predecessor, and shifting it around in the | |
| 681 | + # commit order. The backend would still use the prefered | |
| 682 | + # parent for the attachment point in fossil. | |
| 683 | + | |
| 684 | + # So, for now I have decided to disable this and press | |
| 685 | + # forward. Of course, if we run into actual trouble we | |
| 686 | + # will have to go back here see what can be done to fix | |
| 687 | + # this. Even if only giving the user the instruction how | |
| 688 | + # to edit the CVS repository to remove the inconsistency. | |
| 689 | + | |
| 690 | + # All branches have to agree on the LOD their changeset | |
| 691 | + # belongs to. In other words, all branches in a changeset | |
| 692 | + # have to refer to the same line of development. | |
| 693 | + # | |
| 694 | + # Instead of looking at all pairs of branches in all | |
| 695 | + # changesets we generate the distinct set of all LODs | |
| 696 | + # referenced by the branches of a changeset, look for | |
| 697 | + # those with cardinality > 1, and get the identifying | |
| 698 | + # information for the changesets found thusly. | |
| 699 | + CheckCS \ | |
| 700 | + {All branches in a changeset have to belong to the same LOD} \ | |
| 701 | + {: Its branches disagree about the LOD they belong to} { | |
| 702 | + SELECT T.name, C.cid | |
| 703 | + FROM changeset C, cstype T | |
| 704 | + WHERE C.cid IN (SELECT U.cid | |
| 705 | + FROM (SELECT DISTINCT CI.cid AS cid, B.lod AS lod | |
| 706 | + FROM csitem CI, changeset C, branch B | |
| 707 | + WHERE CI.iid = B.bid | |
| 708 | + AND C.cid = CI.cid | |
| 709 | + AND C.type = 2) AS U | |
| 710 | + GROUP BY U.cid HAVING COUNT(U.lod) > 1) | |
| 711 | + AND T.tid = C.type | |
| 712 | + } | |
| 713 | + } | |
| 688 | 714 | # All branches have to agree on the project their changeset |
| 689 | 715 | # belongs to. In other words, all branches in a changeset have |
| 690 | 716 | # to refer to the same project. |
| 691 | 717 | # |
| 692 | 718 | # Instead of looking at all pairs of branches in all |
| 693 | 719 |
| --- tools/cvs2fossil/lib/c2f_integrity.tcl | |
| +++ tools/cvs2fossil/lib/c2f_integrity.tcl | |
| @@ -660,33 +660,59 @@ | |
| 660 | WHERE U.count > 1 |
| 661 | AND B.bid = U.iid |
| 662 | AND S.sid = B.sid -- get symbol of branch |
| 663 | AND P.pid = S.pid -- get project of symbol |
| 664 | } |
| 665 | # All branches have to agree on the LOD their changeset |
| 666 | # belongs to. In other words, all branches in a changeset have |
| 667 | # to refer to the same line of development. |
| 668 | # |
| 669 | # Instead of looking at all pairs of branches in all |
| 670 | # changesets we generate the distinct set of all LODs |
| 671 | # referenced by the branches of a changeset, look for those |
| 672 | # with cardinality > 1, and get the identifying information |
| 673 | # for the changesets found thusly. |
| 674 | CheckCS \ |
| 675 | {All branches in a changeset have to belong to the same LOD} \ |
| 676 | {: Its branches disagree about the LOD they belong to} { |
| 677 | SELECT T.name, C.cid |
| 678 | FROM changeset C, cstype T |
| 679 | WHERE C.cid IN (SELECT U.cid |
| 680 | FROM (SELECT DISTINCT CI.cid AS cid, B.lod AS lod |
| 681 | FROM csitem CI, changeset C, branch B |
| 682 | WHERE CI.iid = B.bid |
| 683 | AND C.cid = CI.cid |
| 684 | AND C.type = 2) AS U |
| 685 | GROUP BY U.cid HAVING COUNT(U.lod) > 1) |
| 686 | AND T.tid = C.type |
| 687 | } |
| 688 | # All branches have to agree on the project their changeset |
| 689 | # belongs to. In other words, all branches in a changeset have |
| 690 | # to refer to the same project. |
| 691 | # |
| 692 | # Instead of looking at all pairs of branches in all |
| 693 |
| --- tools/cvs2fossil/lib/c2f_integrity.tcl | |
| +++ tools/cvs2fossil/lib/c2f_integrity.tcl | |
| @@ -660,33 +660,59 @@ | |
| 660 | WHERE U.count > 1 |
| 661 | AND B.bid = U.iid |
| 662 | AND S.sid = B.sid -- get symbol of branch |
| 663 | AND P.pid = S.pid -- get project of symbol |
| 664 | } |
| 665 | if 0 { |
| 666 | # This check has been disabled. When the converter was run |
| 667 | # on the Tcl CVS several branches tripped this |
| 668 | # constraint. One of them was a free-floating branch, and |
| 669 | # its handling has been fixed by now. The others however |
| 670 | # seem semi-legitimate, in the sense that they show |
| 671 | # inconsistencies in the CVS history the user is not |
| 672 | # really able to solve, but it might be possible to simply |
| 673 | # ignore them. |
| 674 | |
| 675 | # For example in Tcl we have a branch X with a prefered |
| 676 | # parent Y, except for a single file where the prefered |
| 677 | # parent seems to be created after its current parent, |
| 678 | # making re-parenting impossible. However we may be able |
| 679 | # to ignore this, it should only cause the branch to have |
| 680 | # more than one predecessor, and shifting it around in the |
| 681 | # commit order. The backend would still use the prefered |
| 682 | # parent for the attachment point in fossil. |
| 683 | |
| 684 | # So, for now I have decided to disable this and press |
| 685 | # forward. Of course, if we run into actual trouble we |
| 686 | # will have to go back here see what can be done to fix |
| 687 | # this. Even if only giving the user the instruction how |
| 688 | # to edit the CVS repository to remove the inconsistency. |
| 689 | |
| 690 | # All branches have to agree on the LOD their changeset |
| 691 | # belongs to. In other words, all branches in a changeset |
| 692 | # have to refer to the same line of development. |
| 693 | # |
| 694 | # Instead of looking at all pairs of branches in all |
| 695 | # changesets we generate the distinct set of all LODs |
| 696 | # referenced by the branches of a changeset, look for |
| 697 | # those with cardinality > 1, and get the identifying |
| 698 | # information for the changesets found thusly. |
| 699 | CheckCS \ |
| 700 | {All branches in a changeset have to belong to the same LOD} \ |
| 701 | {: Its branches disagree about the LOD they belong to} { |
| 702 | SELECT T.name, C.cid |
| 703 | FROM changeset C, cstype T |
| 704 | WHERE C.cid IN (SELECT U.cid |
| 705 | FROM (SELECT DISTINCT CI.cid AS cid, B.lod AS lod |
| 706 | FROM csitem CI, changeset C, branch B |
| 707 | WHERE CI.iid = B.bid |
| 708 | AND C.cid = CI.cid |
| 709 | AND C.type = 2) AS U |
| 710 | GROUP BY U.cid HAVING COUNT(U.lod) > 1) |
| 711 | AND T.tid = C.type |
| 712 | } |
| 713 | } |
| 714 | # All branches have to agree on the project their changeset |
| 715 | # belongs to. In other words, all branches in a changeset have |
| 716 | # to refer to the same project. |
| 717 | # |
| 718 | # Instead of looking at all pairs of branches in all |
| 719 |