Re: Recovery Test Framework

On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
> >> No, git really does help with this. If Simon were making his changes
> >> in git and pushing them to a git branch on git.postgresql.org, you
> >> would be able to see exactly what he changed and when he changed it.
> >
> > Well, if that's actually an archival repository then it would work.
> > But wasn't I just reading something about having to wipe that repository
> > and re-import the CVS history to fix various problems?
>
> Not sure; I hope not.

Actually yes we did. There was a bug in git-cvs that we fixed. Its is
talked about here:

http://archives.postgresql.org/pgsql-www/2008-12/msg00182.php

But... that wasn't really the fault of git.

> I think we'd be well-served by getting rid of
> CVS permanently and using git for the master branch. That would
> eliminate the possibility of git reading a partial commit from CVS and
> any other possible issues of needing to go back and reconstruct git
> things based on unexpected wankage in the CVS repository. We could
> keep the list of committers exactly the same as what it is now; they'd
> just be people with rights to push the master git branch rather than
> rights to commit to CVS.
>

There are specific problems with git that people should be aware of
before we start the idea of migrating full to it. The most bothersome to
me is that you must check out the ENTIRE repo. It isn't possible to say:

git clone https://git.postgresql.org/postgresql/7.3

It is all or nothing. I know why this is but that doesn't mean I like
it :)

> I am sure this would involve a fair amount of work but I think it

Actually the work is relatively minimal as we have git infrastructure in
place. The larger problem is:

What is the problem we are trying to solve?
Does git actually solve it?

Sincerely,

Joshua D. Drake

--
PostgreSQL
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997