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
184.108.40.206 in a particular file precede those made in revision 220.127.116.11 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
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