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 gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
