Serious flaws in "git cvsimport"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I really hate working with CVS, so I have set up a cronjob running
"git cvsimport" on regular basis to create a mirror of gnuplot
sources. I would use another tool, but until a few days ago I wasn't
aware of anything else that supported incremental updates, so that I
could run the conversion every few hours without the need to trash the
old conversions and make all my local/testing branches incompatible
with future development.

I had a lot of problems with the tool, but I was tolerating it (in the
spirit of numerous warnings that the tool isn't working properly):
- Files that have been deleted from CVS long ago don't get removed
from git (that's very very very annoying)
- I have numerous problems with file permissions (executable vs. non-executable)
- The first time when I do the import, all seems fine. But soon after
that I start getting numerous warnings during conversion in the spirit
of
    revision 1.X of file Y is tagged but not present
But maybe that's a bug in CVS.

But recently I discovered that a commit in the main branch of CVS
(trunk/master/whatever-they-call-it-in-cvs) which was important to me
was simply ignored by "git cvsimport". The commit modified three
files. Immediately after the commit, cvsimport claimed the repository
was already up-to-date. After other changes have been done in CVS,
bits and pieces from that important commit started appearing randomly,
together with other commits to CVS – for example when the same file
was modified in another commit, changes from that "important" commit
to the same file were included as well in that later commit (but they
didn't belong to each other).

My understanding was that warnings about bad behaviour of "git
cvsimport" were related mostly to inability to reproduce complicated
branching and merging with zillions of branches. That would be
acceptable to me because I wasn't interested in those zillions of
branches and tags anyway.

But it turned out that whatever is currently in the master branch of
the repository created by "git cvsimport" isn't even corresponding to
what's currently in CVS and some commits are simply missing from
history along with their commit messages. The git repository contains
too many files (those that have been deleted in CVS) and random other
differences in random files, so that I'm not even able to compile the
project any longer as a consequence.

I'm willing to provide the exact details about the failures, but from
what I understand the previous maintainer of the underlying tool
(cvsps) deprecated it due to too numerous problems and flawed design,
so I'm not sure if anyone would be willing to fix the bugs I'm running
into.

I'm currently testing cvs-fast-export of which I only heard a few days
ago in the desperate search for a replacement for "git cvsimport".

It would be nice to see if manuals of cvsimport would at least mention
the existence of that tool in the same way as it mentions cvs2git (it
took me a while to learn about cvs-fast-export) or even better, to
consider it as an alternative for cvsps via a special argument to
cvsimport if that's possible.

Thank you very much,
    Mojca

(Please CC me in replies.)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]