Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
