Re: cvs2svn conversion directly to git ready for experimentation

From: Steffen Prohaska <prohaska@zib.de>
Date: Aug 3, 2007, 06:48 UTC
Message-ID: <2FEBD7A5-9932-4636-955D-F7E258F8E56E@zib.de>
In-Reply-To: <Pine.LNX.4.64.0708030454200.14781@racer.site>

On Aug 3, 2007, at 6:03 AM, Johannes Schindelin wrote:

Show 37 quoted lines

> On Fri, 3 Aug 2007, Martin Langhoff wrote:
>
>> On 8/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> cvsps is not a conversion tool at all, though it is used by other
>>> conversion tools to generate the changesets.  It appears (I hope  
>>> I am
>>> not misinterpreting things) to emphasize speed and incremental
>>> operation, for example attempting to make changesets consistent  
>>> from one
>>> run to the next, even if the CVS repository has been changed  
>>> prudently
>>> between runs.  cvsps does not appear to attempt to create atomic  
>>> branch
>>> and tag creation commits or handle CVS's special vendorbranch  
>>> behavior.
>>>  cvsps operates via the CVS protocol; you don't need filesystem  
>>> access
>>> to the CVS repository.
>>
>> 100% in agreement. And though I can't claim to be happy with  
>> cvsps, in
>> many scenarios it is mighty useful, in spite of its significant  
>> warts.
>>  The "does incrementals" is hugely important these days, as lots of
>> people use git to run "vendor branches" of upstream projects that use
>> CVS.
>
> Me too: 100% agreement.  A couple of people seem to be content to  
> proclaim
> that their incomplete solutions are better, but in the end of the day,
> they are as bad as the programs they purport to replace: incomplete.
>
> For the moment, I help myself with tracking the different branches
> individually, but there, really, git-cvsimport is as good as the other
> "solutions", with the further advantage that they are actually  
> hackable,
> and not closed to everybody outside a very small community.

I just want to add a warning. You should be suspicious of branched imported using git-cvsimport (which is based on cvsps). If the time the branch is created differs from the time of the first commit to the branch git- cvsimport may get the branching point wrong. This introduces a race condition. Someone may have committed changes to a file that is later changed on the branch. At that point the history of the imported branch is broken and git reports _wrong_ changesets.

I ran into this issue and abandoned the use of git-cvsimport. It's too dangerous for me. The testcase in [1] illustrates the problem. I still strongly believe the warning should be stated in *BOLD* in the documentation.

I'm not saying git-cvsimport is useless. But you should be suspicious about the result of the import, especially if you plan to rely on changesets derived from the imported repo, for example if you plan to do cherry-picking or merging in git; or if you plan to blame people for their stupid changes based on what you see in gitk (almost happend to me ;).

	Steffen

[1] http://marc.info/?l=git&m=118260312708709&w=2