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
