29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
Not sure yet if I should try to abort this at the beginning,
i.e. CVS integrity failure, force the user to manually edit
the RCS archives to bring the symbol used for the vendor
branch into sync. Or if I should allow the import to let this
slide by, by simply assuming that all such second changesets
should not try to create the :trunk: if it exists.
* An internal error thrown when trying to import bwidget of
tcllib shows that there have to be some situation I am not
handling correctly in the cycle-breaker and sorting passes.
It tries to import a changeset on the
'scriptics-sc-2-0-beta-branch' line of development (X), which
has no commits yet. So it goes to the parent LOD to get the
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
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
70
71
|
Not sure yet if I should try to abort this at the beginning,
i.e. CVS integrity failure, force the user to manually edit
the RCS archives to bring the symbol used for the vendor
branch into sync. Or if I should allow the import to let this
slide by, by simply assuming that all such second changesets
should not try to create the :trunk: if it exists.
---
Another possibility is to somehow identify such symbols and
rewrite the structures on my own, i.e. choose one of the
symbols as the canonical vendor branch V and rewrite all
revisions using other vendor branch symbols to use V. This
would have to happen somewhere in either pass CollateSymbols
or in pass FilterSymbols.
Thinking about it would have to happen before we even start to
aggregate the branch/tag/commit counts, so that all of them
apply to V later on, instead of spread over several symbols.
Luckily we have all the relevant information in the state
database, in the tables 'revision' and 'symbol'.
Thinking even more, this type of symbol rewriting, whether by
the importer, or directly in the rcs archives before doing the
import, will not address the fact that both changesets will
have file revisions in them which declare that they are the
last trunk changeset on the vendor branch, despite the second
changeset added about three years after the previous last
trunk changeset on the vendor branch.
It seems that I will have to rewrite the changeset import to
simply allow for this situation and force the second changeset
(and any further) to be non-trunk on the vendor-branch,
whatever I do after collecting the revision. And if I do that
I don't really a good reason to rewrite the symbols.
* An internal error thrown when trying to import bwidget of
tcllib shows that there have to be some situation I am not
handling correctly in the cycle-breaker and sorting passes.
It tries to import a changeset on the
'scriptics-sc-2-0-beta-branch' line of development (X), which
has no commits yet. So it goes to the parent LOD to get the
|