Re: git: uh-oh

On 08/09/10 00:37, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane  wrote:
>> Robert Haas  writes:
>>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>>> fairly good argument for his position.
>>
>> I haven't tested, but if I understand what Max and Michael are saying
>> about CVS, that operation would probably show the file as being there
>> on *every* date between REL8_4_STABLE splitting off and the actual
>> addition of it.po to the branch.  Because CVS isn't paying attention to
>> the evidence of the intermediate tags not being there, either.
>>
>> Nonetheless, having the file pop into being and then disappear again
>> between two observable points seems way too much like quantum physics
>> for my taste.  I think it has to be possible for cvs2git to produce a
>> less surprising translation.
> 
> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
> see it in the NEWS file) and that a checkout-by-date shows the file
> present during the time cvs2git claims it is present, then a less
> surprising translation wouldn't be a faithful representation of the
> contents of our CVS repository.

Correct. You'll have to decide whether you wish to represent your
current cvs repository, or attempt to doctor things to fix the insanity
CVS introduced.

> One thing I'm not quite clear on is
> how cvs2git thinks CVS "should" look given what we actually did vs.
> how it actually does look,

CVS from 1.11.18 kludges things to work right by inserting a file
revision on the branch in the dead (deleted) state with the same date as
the revision it branched from. This marks identifiably that it didn't
exist on the branch to start with, Then, a non-dead revision marks the
true addition of the file to the branch. I'm attaching a sample RCS file.

> but if our CVS repository is busted maybe
> we should be looking to fix that rather than complaining about
> cvs2git.

A possibility. We'd need a tool which would insert an extra node into
the history graph of an RCS file. Unless we can bodge it by using
x.y.z.0 as a revision id, it would also need to renumber all the
revisions on the branch. Still, cvs2git has code to parse the RCS
format, so it's probably achievable without too much work.

Max.