e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: Known problems and areas to work on e1dbf3186d 2008-02-04 aku: =================================== e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: * Currently not properly tracking when a file is removed on some e1dbf3186d 2008-02-04 aku: branch (detectable by a 'dead' revision (optype)) during the e1dbf3186d 2008-02-04 aku: import of changesets. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: * Not yet able to handle the specification of multiple projects e1dbf3186d 2008-02-04 aku: for one CVS repository. I.e. I can, for example, import all of e1dbf3186d 2008-02-04 aku: tcllib, or a single subproject of tcllib, like tklib, but not e1dbf3186d 2008-02-04 aku: multiple sub-projects in one go. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: * An internal error thrown when trying to import tcllib of e1dbf3186d 2008-02-04 aku: tcllib shows that I am apparently not properly handling the e1dbf3186d 2008-02-04 aku: possibility of more than one symbol used to create a e1dbf3186d 2008-02-04 aku: vendor-branch with. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: In tcllib most files (18) have 'tcllib-vendor-branch' as the e1dbf3186d 2008-02-04 aku: name of their vendor branch, done in 2000, however two files e1dbf3186d 2008-02-04 aku: use the name 'vendor' instead, they were done in 2003. Each e1dbf3186d 2008-02-04 aku: set of files corresponds a single changeset. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: This causes the code importing the changesets to flip out when e1dbf3186d 2008-02-04 aku: the second changeset tries to create ':trunk:' and finds it e1dbf3186d 2008-02-04 aku: already existing (both changesets are the last trunk-changeset e1dbf3186d 2008-02-04 aku: on the vendor branch :) ) e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: Not sure yet if I should try to abort this at the beginning, e1dbf3186d 2008-02-04 aku: i.e. CVS integrity failure, force the user to manually edit e1dbf3186d 2008-02-04 aku: the RCS archives to bring the symbol used for the vendor e1dbf3186d 2008-02-04 aku: branch into sync. Or if I should allow the import to let this e1dbf3186d 2008-02-04 aku: slide by, by simply assuming that all such second changesets e1dbf3186d 2008-02-04 aku: should not try to create the :trunk: if it exists. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: * An internal error thrown when trying to import bwidget of e1dbf3186d 2008-02-04 aku: tcllib shows that there have to be some situation I am not e1dbf3186d 2008-02-04 aku: handling correctly in the cycle-breaker and sorting passes. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: It tries to import a changeset on the e1dbf3186d 2008-02-04 aku: 'scriptics-sc-2-0-beta-branch' line of development (X), which e1dbf3186d 2008-02-04 aku: has no commits yet. So it goes to the parent LOD to get the e1dbf3186d 2008-02-04 aku: state we are spawning from. This parent is e1dbf3186d 2008-02-04 aku: 'scriptics-sc-1-1-branch' (Y). And is has no changesets e1dbf3186d 2008-02-04 aku: committed to it yet. That should not be possible, the ordering e1dbf3186d 2008-02-04 aku: constraints should have put all changesets for Y before the e1dbf3186d 2008-02-04 aku: changesets of X, and Y had to have at least one changeset, e1dbf3186d 2008-02-04 aku: from which the branch could be spawned. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: This need deep diving into the various linkages to understand e1dbf3186d 2008-02-04 aku: what is happening, or not happening, depending. e1dbf3186d 2008-02-04 aku: e1dbf3186d 2008-02-04 aku: Note: The code I had before more fully tracking the workspace e1dbf3186d 2008-02-04 aku: state of the various lods wrongly slid over this problem e1dbf3186d 2008-02-04 aku: without erroring out. e1dbf3186d 2008-02-04 aku: