Rene de Zwart wrote: > Andreas, > > I changed c2f_fossil.tcl (changed tag branch to branch new)
Was that all which was needed ? I.e. has 'branch new' the exact same syntax as 'tag branch' ? Only then a 1:1 replacement is possible. Otherwise more code changes will be needed to adapt to the changed syntax. > I tried the option -passes ImportFiles:ImportFinal with the old Statefile > no dice. Hm. What errors did you see ? > I had to redo the whole import. First think in the situation we are in is to save the statefile before retrying the passes, so that you have a fixed state you can re-try from multiple times, i.e. copy saved state to working state, then re-try. And then basically go backwards through the passes to see from where a restart is possible and ok. For the passes where a restart showed to be not possible we will have to preserve error messages and logs to see what is going wrong there. > It takes a lot of time (+8 hours) What cvs repo are you working with > especially the breakcycle Topological sorting and complex processing of changesets for conflicts, yeah. > and import branches take a lot of time. 'Import branches' I would have expected to take less time than 'Import files'. As the latter has to stash any and all revisions into the database and the 'import branches' then 'just' does the changesets and their connections. > I have no ideas how to speed up the process. I actually sped up a few of the phases by rewriting them, this should actually all be in the fossil history of cvs2fossil. However the import phases ... To make them faster I fear I believe that I would need support from fossil for bulk loading things ... Actually drh already made fossil faster in that area IIRC, by capping the length of delta-chains for revisions of the files. Another possibility for making the import area faster would be to have C package implementing these parts of fossil. Then the import would 'just' be invoking Tcl commands, instead of 'exec'ing the fossil application over and over again. > Is there any documentation on > the "cvs normalization process"? No, not really. > I looked at cvs2subversion but other than > the program I could not find info about the inner workings. cvs2svn actually has some docs about the problems they encountered with cvs and how that affected their code and the general architecture. I did not copy the relevant files into cvs2fossil because the whole of cvs2svn is GPL and I did not wish to taint the cvs2fossil code base. I worked of cvs2svn, using it as spiritual guide but the code of cvs2fossil is completely new. The architecture with the phases is similar tough, and the phases also match quite closely. > (how to > determine what constitutes a check-in, branche merge etc) > probably a case of "goto the source Luke" ;-) Unfortunately yes. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
