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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
