Re: PostgreSQL Developer meeting minutes up

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD