Re: Fwd: git cvsimport implications
- From
- Eugene Sajine <euguess@gmail.com>
- Date
- May 15, 2013, 18:03 UTC
- Message-ID
- <CAPZPVFZTZFQrCF3gcwcff5LFm9MHhZm-DauLvfzCYrMTw4nQfA@mail.gmail.com>
- In-Reply-To
- <51932A1A.4050606@alum.mit.edu>
Hi
My primary goal was to understand better what are the real problems that we might have with the way we use git cvsimport, so I was not asking about the guarantee of the cvsimport to import things correctly, but if there is a guarantee the import will result in completely broken history. IF there is a situation when cvsimport can do things right and when it definitely going to fail?
Anyway, thanks a lot for the info. I do know that cvs2git is an option.
If the cvsimport is that broken - is there any plan to fix it?
Thanks, Eugene
On Wed, May 15, 2013 at 2:24 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 51 quoted lines
> On 05/15/2013 12:19 AM, Junio C Hamano wrote: >> Eugene Sajine <euguess@gmail.com> writes: >> >>> What if there are a lot of branches in the CVS repo? Is it guaranteed >>> to be broken after import? >> >> Even though CVS repository can record branches in individual ,v >> files, reconstructing per branch history and where the branch >> happened in each "changeset" cannot be determined with any >> certainty. The best you can get is a heuristic result. >> >> I do not think anybody can give such a guarantee. The best you can >> do is to convert it and validate if the result matches what you >> think has happened in the CVS history. > > Junio, you are correct that there is no 100% reliable way of inferring > the changesets that were made in CVS. CVS doesn't record which file > revisions were committed at the same time, unambiguous branch points, > etc. The best a tool can do is use heuristics. > > But it *is* possible for a conversion tool to make some more elementary > guarantees regarding aspects of the history that are recorded > unambiguously in CVS, for example: > > * That if you check the tip of same branch out of CVS and out of Git, > you get the same contents. > > * That CVS file revisions are committed to Git in the correct order > relative to each other; e.g., that the changes made in CVS revision > 1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of > the same file. > > git-cvsimport fails to ensure even this minimal level of correctness. > Such errors are demonstrated in its own test suite. > > cvs2git, on the other hand, gets the basics 100% correct (if you find a > discrepancy, please file a bug!), in addition to having great heuristics > for inferring the details of the history. > > There is no reason ever to use git-cvsimport for one-time conversions > from CVS to Git. The only reason ever to use it is if you absolutely > require an incremental bridge between CVS and Git, and even then please > use it with great caution. > > Michael > the cvs2svn/cvs2git maintainer > > -- > Michael Haggerty > mhagger@alum.mit.edu > http://softwareswirl.blogspot.com/