Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

From Greg Smith
Subject Re: PostgreSQL Developer meeting minutes up
Date
Msg-id alpine.GSO.2.01.0905281203530.13556@westnet.com
Whole thread Raw
In response to Re: PostgreSQL Developer meeting minutes up  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PostgreSQL Developer meeting minutes up  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 28 May 2009, Robert Haas wrote:

> My understanding is that the histories of some of the branches we have
> now are flat-out wrong.  I don't have a problem keeping those
> alongside the corrected history for ease of rebasing and porting
> commits, but I don't want to punt the problem of figuring out what the
> one, true, and correct history is to the user.

Right.  There has to be "one true repo" for the history here, and if it 
takes another repo conversion to do it that's unfortunate for people 
already using the existing repo, but as pointed out there are tools 
available to help them out.  You can't prioritize users of this early test 
repo ahead of the long-term goals here, and making it easier for new 
people to quickly start hacking on the codebase is very much a motivating 
factor behind the conversion.

Because the mapping of CVS commits into git ones has a bit of fuzziness to 
it, it's possible to turn fine-tuning the repo history into an endless 
project.  Wandering down that road helps no one.

The best way to control the scope creep here is to avoid doing that, and 
instead focus on what you really need from the repo conversion.  In this 
case, it's a hard requirement that current and back branches that are 
still maintained must produce a checked out result that is identical to if 
you were to check that version out of CVS.  There's already been some spot 
checking of that already, it may make sense to write up an official QA 
spec here.

Reconversion of the old history needs to happen as many times as necessary 
until that goal is reached for git to be adopted by the project one day. 
Because I think that's going to require an iterative process 
(convert/test/fix/repeat) I'm not sure what value there is to the better 
conversion tools that can't be used incrementally here.

If the goalposts are moved to "every ancient tag/release ever must build 
perfectly and have sane history no matter how nasty its CVS history was", 
history conversion is doomed.  I don't think it's unrealistic to plan 
reaching a point where you can say "we've confirmed every release build 
from 7.4 forward builds identically from git; older releases, betas, and 
similarly early builds should instead be built from the deprecated CVS 
repo".  If the scope of the conversion has higher standards than that, and 
I can't imagine why it should, there's going to be an enormous amount of 
time wasted playing around with tags that results in no benefit to users 
of the software.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: "David E. Wheeler"
Date:
Subject: Re: search_path vs extensions