Re: [PATCH] git-cvsexportcommit can't commit files which have been removed from CVS

From: Nick Woolley <nickwoolley@yahoo.co.uk>
Date: Jul 6, 2009, 13:23 UTC
Message-ID: <4A51FAD3.7010306@yahoo.co.uk>
In-Reply-To: <e2b179460907020650u672d8724p45f67173668332aa@mail.gmail.com>

Mike Ralphson wrote:

Show 12 quoted lines

> debug.out contains the following:
> 
> # before adding file
> cvs status: nothing known about attic_gremlin
> ===================================================================
> File: no file attic_gremlin             Status: Unknown
> 
>    Working revision:    No entry for attic_gremlin
>    Repository revision: No revision control file
> 
> ===================================================================
> File:  space            Status: Needs Patch

This is what I get on this line:

  File:  space           	Status: Up-to-date

Which might explain why it fails the 'up to date check' in your case - it seems that CVS hasn't synchronised the " space" file with the respository? Or is this an artifact created by the race condition Robin mentioned? I gather the problem appears intermittently.

Show 13 quoted lines

> 
> CVS/Entries for the file has
> / space/1.1/Thu Jul  2 12:50:17 2009//
> 
>> You might also try commenting out the following part of my test, so that it
>> should trivially work, and see if there's still an error:
>>
>> #      rm attic_gremlin &&
>> #      cvs -Q rm attic_gremlin &&
>> #      cvs -Q ci -m "removed attic_gremlin"
> 
> It all goes a bit fun if I do that...
>

Actually, I get the error you do here - my mistake, I should have told you to comment out the whole clause, i.e.:

# (cd "$CVSWORK" && # echo >attic_gremlin && # cvs -Q add attic_gremlin && # cvs -Q ci -m "added attic_gremlin" && # rm attic_gremlin && # cvs -Q rm attic_gremlin && # cvs -Q ci -m "removed attic_gremlin") &&

I've checked this passes for me.

> Would it be acceptable to simply reorder the tests so this previously
> unreported error goes away again?

Speaking personally, I can't see why not, although I don't understand the mechanism of the race condition in question. Wouldn't a race condition like this potentially cause similar errors to crop up all through the test script, whenever git-cvsexportingcommit gets a bogus "Needs Patch" status?

An alternative might be to start my particular test by creating a new CVS repository.

Cheers,

ps I've patched git-cvsexportcommit.perl to get rid of the warnings I can also see in your output, and will submit those to this list separately.