"Heikki Linnakangas" <heikki@enterprisedb.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.
And most importantly I need to be able to take the eventually committed
version. 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.
subversion would allow committers to keep going as they are with a number of
CVS problems eliminated (such as "thou shalt not rename files").
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.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
