Re: Recovery Test Framework

>> I think the problems it would solve for us are (1) emailing huge
>> patches around sucks (it sucks unnecessarily because of the
>> mailing-list size limit, but even if someone fixes that, it still
>> sucks), (2) no need for a CVS-to-GIT conversion that may incur dirty
>> reads; (3) retention of history and authorship when merging patches
>> into core. It's possible that it might change our workflow in other
>> ways too, but even if we got only those three things I think that
>
> O.k. now the second part :)
>
> Does bzr, mecurial or monotone offer the same or better solution? Bzr in
> particular is in very wide use and I run into mecurial all the time.

I'm sure we could make any of them work, but the fact that
git.postgresql.org already exists and hg.postgresl.org,
bzr.postgresql.org, etc. do not may be suggestive of something - that
it would be less work to finish the job, if nothing else. I also
think there is some evidence to suggest that git is evolving very
rapidly. You could view that as a negative thing, but I don't mean
they're fixing bugs: I mean they're adding features. That suggests
both that (1) if git doesn't have feature X that you want now, it's
likely to have it in the not-too-distant future and (2) a lot of other
people like git well enough that they're both using it themselves and
contributing changes back to the community, which is an endorsement of
the product generally.

git definitely has some downsides. The initial repository clone is
kind of expensive, and there's a learning curve (though it's much
flatter than it was in the past). So I don't think it's the greatest
thing ever. But I think it's pretty good, and based on the spike in
a/... and b/... paths in recent patches, I'm not the only one.

...Robert