Re: SCMS question - Mailing list pgsql-hackers

"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