Re: git: uh-oh - Mailing list pgsql-hackers

From Tom Lane
Subject Re: git: uh-oh
Date
Msg-id 2537.1283955668@sss.pgh.pa.us
Whole thread Raw
In response to Re: git: uh-oh  (Michael Haggerty <mhagger@alum.mit.edu>)
Responses Re: git: uh-oh  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Tom Lane wrote:
>> Well, even if the goal is to faithfully represent the bogus history
>> shown by CVS, cvs2git isn't doing a good job of it.

> Them's fightin' words :-)

Yeah ;-), but they were mainly directed at Robert, who AIUI was
asserting that the behavior of "cvs co -D" ought to be taken as defining
what the CVS history means.  I don't particularly buy that, and clearly
you don't either.

> Incorrect.  The CVS history implies three user-initiated events in this
> neighborhood:

> 2010.02.19: version 1.7 committed to trunk
> unknown date: file added to branch REL8_4_STABLE (1.7.6)
> 2010.05.13: file modified on branch REL8_4_STABLE to create 1.7.6.1

Right.  The problem I've got is that cvs2git takes "unknown" as meaning
"I can do whatever I want, the more random the better".  It would seem
to me to be good software engineering to recognize that you don't have
enough information and to provide some way for cvs2git's users to modify
its behavior on this point.

Anyway I think the solution path for us is probably going to be to
retroactively add the information, along the lines suggested by Max.
I was hoping that somebody would have tried a conversion by now with
the partial patch I suggested last night, but maybe I'm going to have
to do it myself.  Where can I find the version of cvs2git we're using?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: plan time of MASSIVE partitioning ...
Next
From: Simon Riggs
Date:
Subject: Re: Synchronization levels in SR