Re: SCMS question - Mailing list 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