"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend