From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Warren Turkal <wt(at)penguintechs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SCMS question |
Date: | 2007-02-22 13:20:25 |
Message-ID: | 45DD9899.1010603@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Schiltknecht wrote:
> Hi,
>
> Andrew Dunstan wrote:
>> 1. The buildfarm is very heavily dependent on CVS, and any change to
>> anything else will be quite painful. There is no guarantee that all
>> the members even have SVN installed,
>
> But you can guarantee they have CVS or even cvsup installed? That seems
> dubious to me.
getting CVS on a box is still way easier than SVN (I don't want event
talk about more esoteric ones) especially on older and/or special
platforms. As someone who operates a large number of buildfarm members
switching to something else would put a large burden(both in terms of
installation and configuration changes/upgrades of the buildfarm client)
on me for no appearent gain.
Beside that - are all of the currently supported Platforms officially
supported by the proposed SCMSes ?
>
>> let alone anything else. And someone would have to code and test
>> significant client changes. That said, a lot of the tortuous logic
>> could be removed - change detection would almost just resolve to
>> comparing two tree numbers with SVN, for example.
>
> ..and a *real* VCS (as in monotone :-) ) would provide not only that,
> but give you correctness guarantees, built in certification of revisions
> (i.e. each buildfarm member could issue a cert on successful testing)
> and lightweight branches, so you could much easier test experimental
> patches of different authors. Just to name a few additional advantages.
most of the issues with CVS in that regard have already been worked
around (and are therefore "solved").
But I agree that for developers especially those that are doing large
patches over a long period of time might gain something from another
SCMS, but it is not really clear what that SCMS should be or if it
warrants the imho enormous switching costs (and the potential disruption
in development until that switch is done which might take days if not
weeks).
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2007-02-22 13:24:06 | Re: HOT for PostgreSQL 8.3 |
Previous Message | Markus Schiltknecht | 2007-02-22 13:05:33 | Re: SCMS question |