Re: [PATCH 3/3] docs/cvs-migration: mention cvsimport caveats

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

 



On Thu, Sep 22, 2016 at 09:15:26AM -0400, Eric S. Raymond wrote:

> Jeff King <peff@xxxxxxxx>:
> > Back when this guide was written, cvsimport was the only
> > game in town. These days it is probably not the best option.
> 
> It is absolutely not.  As I have tried to point out here before, it
> is *severely* broken in its processing of branchy CVS repositories.
> 
> Nobody wanted to hear that, but it's still true. Recommending it
> is irresponsible.

I think your points came across, and that is why we have the big warning
in git-cvsimport in the first place. This is really just adding a
pointer to that warning from another relevant location (that frankly, I
didn't even know existed until fixing a nearby problem).

I _do_ think cvsimport, buggy as it may be, may still have some
potential value over other solutions (if you have a simple history, and
it is easier to install or run than the alternatives). But I converted
all of my CVS history to git over ten years ago and have never looked
back. I really don't know if that is the case or not.

So personally I have no objection if somebody wants to rewrite the
gitcvs-migration page to discuss the other options more thoroughly, or
warn more clearly about cvsimport's flaws. These patches were just
"Jeez, we are not even warning people _at all_, so at the minimum we
should do so". I am not qualified to write on the current state of
the art in CVS importing.

-Peff



[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]