Re: missing file in git repo

Magnus Hagander wrote:
> On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan <andrew@dunslane.net> wrote:
>   
>> Kevin Grittner wrote:
>>     
>>>> The reported source of the software seems to have gone away. I can
>>>> let you have my copy, which reliably reproduces the error, so we
>>>> have a good failure test case.
>>>>
>>>>         
>>>  If it's not as recent as this:
>>>  http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132
>>>  we might want to bring in (or at least review) what's been committed
>>> since we grabbed our copy.  Some of the fixes mentioned sound like
>>> they might possibly be related.
>>>
>>>
>>>       
>> OK, there is good news on this front. When last I looked this repo was
>> giving errors, so I worked from the copy of the code I already had. (So
>> thanks to Kevin for prodding me to check again.) With the latest fromcvs and
>> rcsparse packages downloaded from this site I can now make and run the 7.4
>> and 8.1 branches from the imported repository (I haven't checked other
>> branches yet.)
>>     
>
> What exactly did you test? Did you run it from scratch, or did you run
> it on top of the existing git repo? Because AFAIK the bug isn't
> consisten in that if you just do a fresh migration, it often works -
> even with the current version we have deployed. I haven't checked that
> in detail though - was this included in your tests?
>   

On the version of the code I was using was fetched from the Mercurial 
repo. The versions I originally tested with are   rcsparse-1a3116e80c2e and   fromcvs-186299486bdc.

The versions I have had success with are   rcsparse-75d93404707d and   fromcvs-c31a1dd9cbb2

On the older versions I tested, the errors appeared each time I ran the 
initial imports on the CVS clone I was testing with. With the latest 
version it has not.

>
>   
>> So we need to look at how hard it would be to upgrade the scripts on
>> git.postgresql.org, and if by doing so we can fix its versions of the back
>>     
>
> Upgrading the script is trivial. It's working off a git checkout with
> a specific hash,iirc, because there were no actualstable releases at
> the time, so if you can tell me which commit to check out, that's
> easy.
>
> Will this automatically fix the backbranches, or do we need to do
> something more than just upgrading it?
>   

I think what we'd need to do is remove the back branches that are 
failing and let it reimport them completely. AFAIK this should work 
without disturbing the branches we didn't remove. But it should be 
tested rigorously before being tried.

>
>   
>> branches. It would also be a good idea to have a script that regularly
>> checks out the important branches from git and checks that they are
>> identical to what is in CVS. That might help to increase Tom's confidence
>> level.
>>     
>
> Yes, that would be very good. ISTR there's a script somewhere, but it
> didn't run without showing some issues? Particularly related to the
> keyword expansion stuff?
>
> If someone has such a script ready today, it should be easy to deploy
> it on the git server for regular checks. If not, volunteers are most
> welcome to write one :-)
>
>   

What I have done is to set up my own mirror and I will be testing it on 
all the live branches with a git-ized buildfarm client.

I can probably pull together a script that exports from both git and cvs 
and compares.

cheers

andrew