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?
On Wed, May 15, 2013 at 2:24 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 05/15/2013 12:19 AM, Junio C Hamano wrote:
>> Eugene Sajine <eugu...@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
> 188.8.131.52 in a particular file precede those made in revision 184.108.40.206 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.
> the cvs2svn/cvs2git maintainer
> Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html