From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
Cc: | 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 14:24:03 |
Message-ID: | 45DDA783.5010806@dunslane.net |
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.
CVSup is not required, and is absent from most existing clients. I don't
use it any more since the Fedora project stopped supporting it.
Buildfarm was designed to be able to run anywhere that a build from our
repo could run, without requiring anything extra - I have even tried to
keep to a minimum the perl modules required.
The point you are missing is that, while we know existing buildfarm
members all have CVS installed, we don't know that they have SVN or
whatever, and requiring them to install it will involve significant
distributed pain. It will also involve some considerable localised pain
(probably on my part) in rewriting the client. Right now I'm thinking it
might make some sense to future-proof buildfarm by creating some sort of
snapshot server. OTOH, if we avoid use of whatever SCM system that the
project uses, we aren't testing that part of the process.
>
>> 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.
You're making Tom's point again :-)
>> Of course, SVN is better at disconnected operation than CVS,
>
> Really? I've dropped subversion exactly because it sucks big time when
> disconnected. But again, I'm probably not comparing against CVS...
IIRC you don't need to be connected to the repo to run "svn diff",
whereas you do to run "cvs diff".
>
>> I have no doubt we'll change someday to something better. I don't
>> know what it is and I don't think we need to be in any hurry. This
>> space is still very fluid.
>
> Yup. Good to hear you see it that way. As I understand, you have good
> reasons to be still using CVS, but are open to good suggestions.
> That's a very good thing, but easily slips by when reading all the
> critics and pro-CVS statements. ;-)
We know the warts. If this were a green fields project there is no doubt
we would not use CVS. But many proponents of other systems ignore the
downside of changing.
One thing I want to know is that whatever we change to will still be
there, maintained and in widespread use, many years down the track. So
far I am not sure about that for any possible replacement, with the
possible exception of SVN.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2007-02-22 14:32:57 | Re: autovacuum next steps, take 2 |
Previous Message | Jim C. Nasby | 2007-02-22 14:23:38 | Re: autovacuum next steps, take 2 |