Re: [WORKAROUND] parsecvs losing files

From: Alex Bennee <kernel-hacker@bennee.com>
Date: May 30, 2008, 10:08 UTC
Message-ID: <b2cdc9f30805300308x2620e34cqca5d55c82e337393@mail.gmail.com>
In-Reply-To: <20080528170332.GB16996@artemis.madism.org>

On Wed, May 28, 2008 at 6:03 PM, Pierre Habouzit <madcoder@debian.org> wrote:

>  Sorry for the top posting but the git list isn't really the upstream
> for parsecvs. I'm now Cc-ing keithp who is the author :)

I shall keep CC'ing git@ for visibility if anyone else comes across this :-)

Show 7 quoted lines

>
> On Wed, May 28, 2008 at 04:53:30PM +0000, Alex Bennee wrote:
>> On Wed, May 28, 2008 at 3:50 PM, Alex Bennee <kernel-hacker@bennee.com> wrote:
>> > Hi,
>> > <snip>
>> > Anyway today I noticed it had failed to import a sub-directory of the
>> > project (not a bit I usually build).

<snip>

Show 20 quoted lines

>>
>> Well in answer to myself parsecvs does get confused. In an example
>> failed to import file:
>>
>> Load:                          third-party/libxml/runtest.c,v   8207 of 79070
>> /export/git/master.cvs/third-party/libxml/runtest.c,v spliced:
>>        1.1.1.1
>>        1.1
>> Sorted heads for /export/git/master.cvs/third-party/libxml/runtest.c,v
>>       master 1.1
>>       master > BRANCH-3-5-branch 1.1.1.1.0.2
>>       master > BRANCH-3-5-16-branch 1.1.1.1.0.4
>> building branches for /export/git/master.cvs/third-party/libxml/runtest.c,v
>> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19
>> file sha1: b694d565caf10fedbc7566f2bf15b893c57d5a19
>> file has 2 revisions
>>
>> An lo, looking at the branches mentioned these missing files are
>> there. Trouble is the files should be in a number of branches, looking
>> at the ,v file in question:

<snip>

>>       BRANCH-3-3-20-red-e1-opt-branch:1.1.1.1

<snip>

>> I notice
>> looking at the log for some of the files that did make it that the CVS
>> revisions for all the branches have a .0.[something] suffix which the
>> missing branches in this case don't have.

<snip>

So I understand how this has happened. This particular module was imported directly into the working branch at the time (BRANCH-3-3-20-red-e1-opt-branch) where as other modules where imported into the CVS HEAD and then branched into the current working branch. As a result the branch tag didn't have the magic 0 in it.

We where able to work around the import failure by deleting the branch tag from the module and then branching it again. The new branch tag became:

BRANCH-3-3-20-red-e1-opt-branch:1.1.1.1.0.6

which parsecvs was able to correctly parse and assign to the correct GIT branch on import. I'm guessing this is a corner case that could do with better handling but in our case it was solved by tweaking our CVS repository.

-- 
Alex, homepage: http://www.bennee.com/~alex/