SCMS question

Warren Turkal <wt@penguintechs.org> writes:

Are there any plans to move to another SCMS in the future?

Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.

regards, tom lane

On Thursday 22 February 2007 00:05, Tom Lane wrote:

Not particularly.  We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.

Some of the other options just seem to have much nicer user interfaces. I was
playing with Bacula and they just changed to Subversion. It really is much
nicer than the CVS they used to use. Git seems interesting as well. I guess
Subversion and git are the two big ones right now. What would you look for if
you were to check out new SCMSes? Would you want distributed like Git or
centralized like CVS/Subversion?

wt
--
Warren Turkal (w00t)

Warren Turkal <wt@penguintechs.org> writes:

On Thursday 22 February 2007 00:05, Tom Lane wrote:

Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.

Some of the other options just seem to have much nicer user interfaces. I was
playing with Bacula and they just changed to Subversion. It really is much
nicer than the CVS they used to use. Git seems interesting as well. I guess
Subversion and git are the two big ones right now. What would you look for if
you were to check out new SCMSes? Would you want distributed like Git or
centralized like CVS/Subversion?

I think you just made my point for me.

regards, tom lane

On Thursday 22 February 2007 00:42, you wrote:

I think you just made my point for me.

I wasn't trying to convince so much as get an opinion.

wt
--
Warren Turkal (w00t)

Warren Turkal <wt@penguintechs.org> writes:

On Thursday 22 February 2007 00:42, you wrote:

I think you just made my point for me.

I wasn't trying to convince so much as get an opinion.

Well, sure, it's all opinion ;-). But the overall costs of changing
SCMS are pretty enormous IMHO. We're not going to do it just to find
out if the grass might be greener on the other side of the fence.
If you'd like to see it happen then you need to make some convincing
arguments ... starting with recommending one specific SCMS that we
should change to. If you haven't got a clear and defensible opinion
on that, then you've already lost my interest.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Warren Turkal <wt@penguintechs.org> writes:

On Thursday 22 February 2007 00:05, Tom Lane wrote:

Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.

Some of the other options just seem to have much nicer user interfaces. I was
playing with Bacula and they just changed to Subversion. It really is much
nicer than the CVS they used to use. Git seems interesting as well. I guess
Subversion and git are the two big ones right now. What would you look for if
you were to check out new SCMSes? Would you want distributed like Git or
centralized like CVS/Subversion?

I think you just made my point for me.

Not really. That's not a "preferred value of $foo changing" so much as
different styles of systems.

If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems. There isn't really any other mature SCM system in that style and
I've heard nothing but satisfaction from its users. It has definitely taken
over CVS's top spot in free software mindshare.

If we wanted to go to a whole new way of working using a decentralized system
which might fit better with our system of submitting patches then one of those
other systems like GIT might be better.

While I think our system of working independently and submitting patches
actually fits GIT better, if we're so conservative that we're still on CVS
despite its problems I suspect we're better off not trying to change
operational models at this point.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:

If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.

Erm ... but this is not an argument in favor of changing.

AFAIR the only real disadvantage of CVS that we've run up against is
that it's hard to shuffle files around to different directories without
losing their change history (or more accurately, making the history
harder to find). Now that is a pretty considerable annoyance on some
days, but it's not sufficient reason to change to something else.
I have no doubt that every other SCMS has annoyances of its own.

... if we're so conservative that we're still on CVS
despite its problems I suspect we're better off not trying to change
operational models at this point.

Conservatism is kind of inherent in our problem domain, no? I mean,
you might have great arguments why XYZ is the best operating system
since sliced bread and everyone should migrate to it immediately, and
you might even be right --- but you'd be foolish to expect quick uptake
by the average DBA. There is great value in being familiar with one's
tools.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Gregory Stark <stark@enterprisedb.com> writes:

If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.

Erm ... but this is not an argument in favor of changing.

AFAIR the only real disadvantage of CVS that we've run up against is
that it's hard to shuffle files around to different directories without
losing their change history (or more accurately, making the history
harder to find). Now that is a pretty considerable annoyance on some
days, but it's not sufficient reason to change to something else.
I have no doubt that every other SCMS has annoyances of its own.

Oh we have tons of problems with CVS, it's just that we've worked around them
for so long we've forgotten.

Why are side projects like bitmapped indexes and the variable varlena stuff
sitting on people's personal hard drives instead of in a branch of the main
tree? It makes it awfully hard for developers to collaborate if they have to
mail patches back and forth, merging conflicts manually and constantly
negotiate what version of postgres the patches are against.

Why are so few people committers? The normal work-flow on other projects is
that you want any substantial changes in the revision control system as soon
as possible so other people can see and work with them and use the revision
control tools to manage them. The review process can either back them out or
keep the production code on a separate branch and merge in the changes when
they're approved.

The answer to both questions is because CVS limitations make it hard to do
better. There are no access control mechanisms and creating and managing
branches is awkward and easy to get wrong.

Mailing around patches basically limits us to one-person projects that can be
reviewed by a single committer in a single sitting. Any larger and the people
involved have no tools to coordinate or the committer has to deal with code
drift in the main tree during the time he's reviewing the patch.

[on a related note, is something wrong with my cvs rsync tree or is configure
in the CVS repository? It's causing my patches to bloat considerably since I
added one line to configure.in]

Conservatism is kind of inherent in our problem domain, no? I mean,
you might have great arguments why XYZ is the best operating system
since sliced bread and everyone should migrate to it immediately, and
you might even be right --- but you'd be foolish to expect quick uptake
by the average DBA. There is great value in being familiar with one's
tools.

It's also why we have so many posters asking whether it's really necessary for
them to upgrade from 7.0 which is working fine for them. Transaction
wrap-around only happens once in a blue moon. And the weekly outages for
vacuum fulls are scheduled and approved by management so we don't have to care
about them any more.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:

[on a related note, is something wrong with my cvs rsync tree or is
configure in the CVS repository? It's causing my patches to bloat
considerably since I added one line to configure.in]

cat CVS/Entries

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

"Peter Eisentraut" <peter_e@gmx.net> writes:

Gregory Stark wrote:

[on a related note, is something wrong with my cvs rsync tree or is
configure in the CVS repository? It's causing my patches to bloat
considerably since I added one line to configure.in]

cat CVS/Entries

$ cat CVS/Entries
D/config////
D/contrib////
D/doc////
D/src////
/configure.in/1.501/Wed Feb 14 11:43:15 2007//
/COPYRIGHT/1.13/Thu Feb 15 14:31:14 2007//
/GNUmakefile.in/1.46/Thu Feb 15 14:31:14 2007//
/Makefile/1.13/Thu Feb 15 14:31:14 2007//
/README/1.32/Thu Feb 15 14:31:14 2007//
/README.CVS/1.3/Thu Feb 15 14:31:14 2007//
/aclocal.m4/1.18/Thu Feb 15 14:31:14 2007//
/configure/1.534/Wed Feb 7 00:28:54 2007//

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

On Thu, 22 Feb 2007, Tom Lane wrote:

Gregory Stark <stark@enterprisedb.com> writes:

If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.

Erm ... but this is not an argument in favor of changing.

AFAIR the only real disadvantage of CVS that we've run up against is
that it's hard to shuffle files around to different directories without
losing their change history (or more accurately, making the history
harder to find). Now that is a pretty considerable annoyance on some
days, but it's not sufficient reason to change to something else.
I have no doubt that every other SCMS has annoyances of its own.

It's not a problem for the project but I personally experience pain with
CVS. I often want to take a bunch of commits and merge them into seperate
trees (like Greenplum DB or my private bitmap index tree). This is a lot
easier with the patch set based SCMs like darcs/monotone/git/etc.

Just my thoughts.

Gavin

Tom Lane wrote:

Gregory Stark <stark@enterprisedb.com> writes:

If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.

Erm ... but this is not an argument in favor of changing.

AFAIR the only real disadvantage of CVS that we've run up against is
that it's hard to shuffle files around to different directories without
losing their change history (or more accurately, making the history
harder to find). Now that is a pretty considerable annoyance on some
days, but it's not sufficient reason to change to something else.
I have no doubt that every other SCMS has annoyances of its own.

Oh, goody! My favourite non-productive debate! :-)

I work daily with SVN, and it certainly has some of the CVS pain points
fixed, plus one or two nice gadgets. It's annoyed me a couple of times
too, although I can't remember exactly how.

Let me throw another couple of data points into the mix.

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, 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.

2. Many people (and some buildfarm members) operate against mirrors of
the main repo which are created with rsync or CVSup. I am not aware of
any way to do the equivalent with SVN - any info would be gratefully
received. Of course, SVN is better at disconnected operation than CVS,
so it might be a non-issue for many. Even so, it might be a pity to have
to forego the facility.

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.

cheers

andrew

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.

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.

2. Many people (and some buildfarm members) operate against mirrors of
the main repo which are created with rsync or CVSup. I am not aware of
any way to do the equivalent with SVN - any info would be gratefully
received.

You might want to have a look at svk. It can do exactly that. And the
Blog of Thomas explains how, see [1]Remote Backup Of A Subversion Repository http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/.

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...

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. ;-)

Regards

Markus

[1]: Remote Backup Of A Subversion Repository http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/
http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/

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

Hi,

[ I've CCed the monotone-devel list, as I'm sure those people are
interested, too. ]

Stefan Kaltenbrunner wrote:

Beside that - are all of the currently supported Platforms officially
supported by the proposed SCMSes ?

I can only speak for monotone. We have (had) buildbots for x86 (linux,
netbsd, freebsd, win32), amd64 (linux), ppc (osx) and one sparc (osol).
So far all gcc compiled, AFAIK.

We are very interested in increasing portability of monotone. If you
could give me (or other monotone devels) ssh access to some of the more
obscure boxes, that would help a lot. Please contact me privately.

most of the issues with CVS in that regard have already been worked
around (and are therefore "solved").

Huh? How do you guarantee the correctness of a local checkout? At best,
you can check an md5 sum of a tar archive, but CVS itself does almost no
integrity checking. Does the buildfarm code check somehow? Against what?
(Note that we've already had quite some disk failures uncovered by
monotone, which does extensive integrity checking. But I'm sure database
people know how important that is, don't you?)

Or quickly test experimental patches? Is that solved?

Or merging between branches, to add another major annoyance of CVS (and
subversion, for that matter).

I currently fetch the whole PostgreSQL repository via cvsup and then
import it into monotone to be able to do serious work. Of course that's
possible, and you can work around all the other limitations of CVS
somehow, but it's annoying.

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).

I certainly agree that switching to another VCS is a major undertaking.
And I'm working on easing migration to monotone. And I'll quite
certainly try again to convince you again, *at some point in the
future*. I would not vote for switching the PostgreSQL repository to
monotone, yet. (As if I had a vote...;-) )

Regards

Markus

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

On Thu, Feb 22, 2007 at 03:13:49PM +0100, Markus Schiltknecht wrote:

one sparc (osol). So far all gcc compiled, AFAIK.

I think, that buildbot was gcc on solaris9/sparc. I care for support of monotone built with sunpro on solaris10
(and opensolaris) on x86 and sparc (but no buildbot for those).

there was once some work on msvc support, but I have no idea what happened to that.

patrick georgi

Hi,

Andrew Dunstan wrote:

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.

..which is quite understandable, concerning the PITA compiling modula-3
gives you (or at least has given me, it still hurts).

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.

Okay, I certainly agree that CVS is much more wide spread and available
than most (if not all) other VCSes. Let's change that ;-)

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.

Did I mention that monotone is a very good snapshot server? *duck*

You probably don't want to reinvent the weel, as 'snapshot serving' is
exactly what a VCS should do (among other things).

You're making Tom's point again :-)

Yeah, sorry, couldn't resist :-)

IIRC you don't need to be connected to the repo to run "svn diff",
whereas you do to run "cvs diff".

Yes, in the simplest case of comparing against the immediate successor
revision. But certainly not for: svn diff -r${FURTHER_IN_THE_PAST}, as
subversion does not have that data available (nor does CVS, for that
matter).

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.

Well, I guess many advocates for other VCSes (like myself) simply don't
particularly like to talk about the downsides... But they are probably
more aware of them than most other people.

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.

That's certainly a valid concern, too. Probably *the* one where monotone
is weaker compared to git and mercurial. :-( We are working on that
issue, though.

Regards

Markus

If I may, I'll add a few words to this discussion:

Basically, I'm seeing that three things need to be decided upon:

1. Do you want to stay with CVS or do you want to move to something
else?
2. If you want to move, when? Is now a good time, or is it better
to look at it another time. This may be a question of what
people you have who'd do the job, what kind of time they have for
the moment and so on.
3. What would you want a replacement to be able to do?

When those questions are answered and people are behind it, then it's
time to look at the different systems and see what' the best match to
your desires.

So far, I'm getting the sense that there are a lot of opinions on what
replacement system to use, a bit carelessly before having answered the
above questions thoroughly.

HTH.

Cheers,
Richard

--
Richard Levitte richard@levitte.org
http://richard.levitte.org/

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis