Re: PostgreSQL 8.4 development plan
От | Gregory Stark |
---|---|
Тема | Re: PostgreSQL 8.4 development plan |
Дата | |
Msg-id | 87zlucperg.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.4 development plan ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: PostgreSQL 8.4 development plan
|
Список | pgsql-hackers |
"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!
В списке pgsql-hackers по дате отправления: