Re: cvsexportcommit and cvsimport's -k option

From: Lars Noschinski <lars.noschinski@rwth-aachen.de>
Date: May 2, 2008, 20:11 UTC
Message-ID: <20080502201102.GA24914@lars.home.noschinski.de>
In-Reply-To: <200804292146.42262.robin.rosenberg.lists@dewire.com>

Hello!

* Robin Rosenberg <robin.rosenberg.lists@dewire.com> [08-04-29 22:56]:

Show 18 quoted lines

>tisdagen den 29 april 2008 19.15.06 skrev Lars Alexander Noschinski:
>> ... hack away ...
>> git-cvsimport -i -r cvs -kk -v -d $CVSREPOS
>> git-rebase cvs # If work was done in the meantime
>> git-cvsexportcommit -cpuv $COMMIT # Multiple times, if necessary
>> git-cvsimport -i -r cvs -kk -v -d $CVSREPOS
>> git-checkout -b master cvs # commit ids are changed now
>>
>> As far as I am concerned, this works fairly well, accept when for any
>> reason a line containing a CVS keyword (e.g. $Id$) is contained in a
>> changeset. In this case, patching fails, and I have to investigate why it
>> fails, eventually just copying the old version from the cvs repository.
>>
>> Would it be possible to add an option to cvsexportcommit to detect such
>> killed keywords and ignore them?
>
>Sure, but is it necessary? If the cvs checkout you use is checked out
>with -kk there shouldn't be any problem.

Errm, now as you mention it ... Even it is clearly mentioned in git-cvsimport(1), it did not realize, that -k just invokes cvs with -kk. I think this is a perfectly fine solution.

>If not, start by thinking up a few testcase for inclusion in
>t9200-git-cvsexportcommit.sh that illustrates the problem. Then we can
>change cvsexporcommit until the new tests pass.

As cvs can do this for us, I think it is not necessary to introduce another source of potential errors.

Thanks for your quick answer and sorry for me being dumb,
     Lars