Fossil SCM
Added some musings to one of the situations to deal with.
Commit
812c91bb8da14910a5d9418bcbf1b92b0ebe8505
Parent
e1dbf3186dd4076…
1 file changed
+29
+29
| --- cvs2fossil.txt | ||
| +++ cvs2fossil.txt | ||
| @@ -31,10 +31,39 @@ | ||
| 31 | 31 | the RCS archives to bring the symbol used for the vendor |
| 32 | 32 | branch into sync. Or if I should allow the import to let this |
| 33 | 33 | slide by, by simply assuming that all such second changesets |
| 34 | 34 | should not try to create the :trunk: if it exists. |
| 35 | 35 | |
| 36 | + --- | |
| 37 | + Another possibility is to somehow identify such symbols and | |
| 38 | + rewrite the structures on my own, i.e. choose one of the | |
| 39 | + symbols as the canonical vendor branch V and rewrite all | |
| 40 | + revisions using other vendor branch symbols to use V. This | |
| 41 | + would have to happen somewhere in either pass CollateSymbols | |
| 42 | + or in pass FilterSymbols. | |
| 43 | + | |
| 44 | + Thinking about it would have to happen before we even start to | |
| 45 | + aggregate the branch/tag/commit counts, so that all of them | |
| 46 | + apply to V later on, instead of spread over several symbols. | |
| 47 | + | |
| 48 | + Luckily we have all the relevant information in the state | |
| 49 | + database, in the tables 'revision' and 'symbol'. | |
| 50 | + | |
| 51 | + Thinking even more, this type of symbol rewriting, whether by | |
| 52 | + the importer, or directly in the rcs archives before doing the | |
| 53 | + import, will not address the fact that both changesets will | |
| 54 | + have file revisions in them which declare that they are the | |
| 55 | + last trunk changeset on the vendor branch, despite the second | |
| 56 | + changeset added about three years after the previous last | |
| 57 | + trunk changeset on the vendor branch. | |
| 58 | + | |
| 59 | + It seems that I will have to rewrite the changeset import to | |
| 60 | + simply allow for this situation and force the second changeset | |
| 61 | + (and any further) to be non-trunk on the vendor-branch, | |
| 62 | + whatever I do after collecting the revision. And if I do that | |
| 63 | + I don't really a good reason to rewrite the symbols. | |
| 64 | + | |
| 36 | 65 | * An internal error thrown when trying to import bwidget of |
| 37 | 66 | tcllib shows that there have to be some situation I am not |
| 38 | 67 | handling correctly in the cycle-breaker and sorting passes. |
| 39 | 68 | |
| 40 | 69 | It tries to import a changeset on the |
| 41 | 70 |
| --- cvs2fossil.txt | |
| +++ cvs2fossil.txt | |
| @@ -31,10 +31,39 @@ | |
| 31 | the RCS archives to bring the symbol used for the vendor |
| 32 | branch into sync. Or if I should allow the import to let this |
| 33 | slide by, by simply assuming that all such second changesets |
| 34 | should not try to create the :trunk: if it exists. |
| 35 | |
| 36 | * An internal error thrown when trying to import bwidget of |
| 37 | tcllib shows that there have to be some situation I am not |
| 38 | handling correctly in the cycle-breaker and sorting passes. |
| 39 | |
| 40 | It tries to import a changeset on the |
| 41 |
| --- cvs2fossil.txt | |
| +++ cvs2fossil.txt | |
| @@ -31,10 +31,39 @@ | |
| 31 | the RCS archives to bring the symbol used for the vendor |
| 32 | branch into sync. Or if I should allow the import to let this |
| 33 | slide by, by simply assuming that all such second changesets |
| 34 | should not try to create the :trunk: if it exists. |
| 35 | |
| 36 | --- |
| 37 | Another possibility is to somehow identify such symbols and |
| 38 | rewrite the structures on my own, i.e. choose one of the |
| 39 | symbols as the canonical vendor branch V and rewrite all |
| 40 | revisions using other vendor branch symbols to use V. This |
| 41 | would have to happen somewhere in either pass CollateSymbols |
| 42 | or in pass FilterSymbols. |
| 43 | |
| 44 | Thinking about it would have to happen before we even start to |
| 45 | aggregate the branch/tag/commit counts, so that all of them |
| 46 | apply to V later on, instead of spread over several symbols. |
| 47 | |
| 48 | Luckily we have all the relevant information in the state |
| 49 | database, in the tables 'revision' and 'symbol'. |
| 50 | |
| 51 | Thinking even more, this type of symbol rewriting, whether by |
| 52 | the importer, or directly in the rcs archives before doing the |
| 53 | import, will not address the fact that both changesets will |
| 54 | have file revisions in them which declare that they are the |
| 55 | last trunk changeset on the vendor branch, despite the second |
| 56 | changeset added about three years after the previous last |
| 57 | trunk changeset on the vendor branch. |
| 58 | |
| 59 | It seems that I will have to rewrite the changeset import to |
| 60 | simply allow for this situation and force the second changeset |
| 61 | (and any further) to be non-trunk on the vendor-branch, |
| 62 | whatever I do after collecting the revision. And if I do that |
| 63 | I don't really a good reason to rewrite the symbols. |
| 64 | |
| 65 | * An internal error thrown when trying to import bwidget of |
| 66 | tcllib shows that there have to be some situation I am not |
| 67 | handling correctly in the cycle-breaker and sorting passes. |
| 68 | |
| 69 | It tries to import a changeset on the |
| 70 |