> 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 guess it is the same!
>> I tried the option -passes ImportFiles:ImportFinal with the old >> Statefile >> no dice. > > Hm. What errors did you see ? > after a few files I get: couldn't open "E:/cvs2fossil/cvs2fossil_wspc_4y2oHUEz7c/rpatch": permission denied >> 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 +1800 files +12 branches +14 authors > >> 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. > maybe the change to "branch new" >> 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. a libfossil.so ? I know I brought up the subject of speed, but that is caused by the fact that my attempts with cvs2fossil fail to produce a working repository. It breaks first on tag branch second on importing branches third on redoing the passes It doesn't matter, to me, if it takes 48 hours for the conversion as long as it produces a working repository. I'm not sure if my cvs repository is a mess. I'm doing a bad job of using cvs2fossil, problems with cvs2fossil or all of the above. Unfortunately I'm not at liberty to offer you my cvs repository to see for your self. > > > 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
