Re: git: uh-oh

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Haggerty <mhagger(at)alum(dot)mit(dot)edu>
Cc: Max Bowsher <maxb(at)f2s(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: git: uh-oh
Date: 2010-09-08 14:21:08
Message-ID: 2537.1283955668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Haggerty <mhagger(at)alum(dot)mit(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-09-08 14:22:46 Re: Synchronization levels in SR
Previous Message Stephen Frost 2010-09-08 14:18:02 Re: plan time of MASSIVE partitioning ...