Re: PostgreSQL 8.4 development plan

Gregory Stark wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>
>> Therefore, we can provide mirrors of the CVS repository in multiple formats.
>> And those mirrors exist already, I remember a GIT and a Subversion mirror off
>> the top of my head, and I bet there's others. After we have that, the master
>> version control system used doesn't matter for developers (except committers),
>> as everyone can choose to use whichever mirror he wants. The patches submitted
>> to pgsql-patches will look exactly the same regardless of the version control
>> system the patch submitter used to check out the source code.
>
> I don't think that's right. Developers care about more than just looking at
> individual commits of individual files.
>
> If I have a development version to which I've applied a bunch of pending
> patches, then fix some of them I want to be able to generate updated versions
> of those patches. I also want to be able to take updated versions of the
> patches without having to manually roll back the old versions.

Doesn't those capabilities depend only on the version control system
you're using, not on the one used in the master repository.

> And most importantly I need to be able to take the eventually committed
> version.

I've never found that to be a problem. When my patch gets committed, I
sometimes do a diff between my patch and the one that was committed to
see what was changed, but after that i just do fresh checkout. Perhaps
your patches are committed more often than mine? ;-)

> If it's coming from a mirror of a CVS repository then there's no
> information of which patch the committer is actually committing or even
> anything linking the commits to the various files together.

That's not true. At least in the git mirror, the conversion programs
group together commits to different files, so that they form a single
commit in the git repository. Since CVS doesn't have that information
explicitly, it's done by matching commit messages and the commit
timestamp. It seems to work just fine.

> subversion would allow committers to keep going as they are with a number of
> CVS problems eliminated (such as "thou shalt not rename files").

Now that is certainly true.

> git or its ilk would impact the lives of submitters and reviewers most.
> Basically it would allow two non-committers to collaborate, something which we
> can't really do effectively now.

Two git-using non-committers can do that already, regardless of the
master repository.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com