> > 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!
Pulled the newest linux binary of fossil and looked at the help
... Confirmed, the 'branch new' syntax is identical to 'tag branch'
with respect to what I am using it for.
>From the older fossil I have
fossil tag branch ?--raw? TAGNAME UUID ?VALUE?
And the new
fossil branch new BRANCH-NAME BASIS ?-bgcolor COLOR?
At the core both provide
fossil XXX TAGNAME UUID
fossil XXX BRANCH-NAME BASE
so we are good.
> >> 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
Hm. Time to source dive.
% grep -rn rpatch .
./tools/cvs2fossil/lib/c2f_file.tcl:454: fileutil::writeFile
$dir/rpatch $data
That is the procedure Expand1 ... I.e. the code which expands a RCS
file into all revisions stored in that file by incrementally applying
all the deltas, following the connections between revisions.
Oh, oh ... The relevant line is
# Writing the patch to disk is just for better
# debugging. It is not used otherwise.
fileutil::writeFile $dir/rpatch $data
IOW, while it is unclear why this file has become unwritable (*), this
piece of code is not directly relevant to the import at all. We can
comment this line and should be ok.
(*) I see nothing which would change the permissions of that file
after the fact ... Actually, there is no 'file attributes
-permissions' or 'exec chmod' in entire cvs2fossil code base.
Wait. You are on Windows, right ?
Did you have that file open in some editor or other
application ? Something like that can cause Windows to set a
lock on the file, thus preventing it from being opened or
written to by other processes.
On the other hand, that does not explain why the failure
happened only a few files into the process and not
immediately.
Well, except in the convoluted circumstance that the rpatch
file was opened in an editor/other app while the import was
running.
Regardless. Disable the command saving to the rpatch file.
> > What cvs repo are you working with
> +1800 files
> +12 branches
> +14 authors
Actually the question was more directed at 'what is the name of the
project/cvs' so that I can look for it. However from what you say
later (x) it is clear that this is a private and/or company-internal
repository.
> > '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"
No, shouldn't be.
> 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
I know that there was one problem at the time I completed the
cvs2fossil, which was with 'tag cancel'.
Based on the log output the cvs2fossil properly issues 'tag cancel'
commands to stop unwanted propagation of tags into a branch. And
inspecting the resulting repository the 'tag cancel' tickets were,
apparently, present. Despite this the fossil web server showed the
tags propagating through the cancellation, i.e. not being canceled. I
do not know if that was ever changed.
> 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.
(x)
That is ok.
> > > 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.
The cvs2svn sources should have a directory doc/ containing their
design notes. I am attaching the notes I have to this mail now.
--
So long,
Andreas Kupries <[email protected]>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
cvs2svn-notes.tgz
Description: cvs2svn-notes.tgz
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
