Re: subversion is NOT cultural replacement of CVS. I decided NOT to migrate.
I realize this is a fairly old post, but... pretty much everything in it is either unsubstantiated opinion or factually wrong.
> 1. subversion is NOT cultural replacement of cvs. In their fevor to
> improve, they broke too many things. I would not mind slight
> changes in syntax, but the whole flavour is alien. Essentially
> using subversion requires you to learn entirely new version
> control system and very few lessons learned from CVS will carry
Unsubstantiated opinion. I used CVS for ten years before switching to Subversion and had no trouble at all adapting. The only things I needed to learn from scratch were Subversion features that CVS simply doesn't have.
I still use CVS extensively, but I vastly prefer Subversion.
> 2. subversion is "modern" software. This means it
> depends on ten other projects. They do not bother
> to document these dependencies in a comprehensible way and
> the ./configure script fails in mysterious ways (apart
> from taking forever to run before it fails). It also
> seems there is good deal of bloat and needless abstractions
> that do not serve a useful purpose.
Building Subversion from scratch instead of using the prepackaged version provided by your OS or distribution of choice was entirely your own decision.
The abstractions you complain about are far from useless; they make Subversion extremely portable while allowing the developers to focus on functionality rather than portability.
> 3. subversion abandoned the CVS flat file philosophy and
> went for BerkeleyDB. Then they noticed that people actually
> considered flat plain text files a good thing(tm) and tried
> to retrofit it. As such, it does not seem to be anywhere
> near the level of stability of the BerkelyDB backend.
Factually incorrect. The fsfs backend was written because of stability and consistency issues with the bdb backend (when accessing a repo over NFS, for instance) and because it makes repo corruption more easily recoverable. It is significantly faster and more stable than the bdb backend, and has been the preferred backend for quite a while (since 1.2).
> But even if you wanted to use BerkeleyDB, they have added
> gazillion dependencies to specific versions of BerkeleyDBs
> so your standard install BerkeleyDB does not work. You will
> need to hand craft a BerkeleyDB that is palatable to
> subversion. Hardly portable, eh?
Factually incorrect. The only issue is that accessing a bdb repo directly (not remotely) with a client built against a newer bdb version will automatically upgrade the repo, rendering it inaccessible to older clients. If all your users access the repo over SSH, you will never run into this problem.
> 4. subversion ssh support seems complicated and much more bloated
> than cvs. In effect subversion is geared towards WebDAV and
> when you try to do ssh, it resorts to trying to emulate
> WebDAV locally on the host where you ssh to. Frankly, cvs
> is much easier to understand.
Factually incorrect. CVS and Subversion implement SSH access in pretty much the same manner.
> 5. subversion simply does not seem to be addressing the need
> we have: ssh accessed repository. They spend all their
> powder on snazzy remote access via WebDAV but forget the
> home base.
Factually incorrect. See above. SSH access works very well - far better than with CVS, in fact, because every time you update or diff a CVS working copy over SSH, CVS does a partial checkout of the corresponding parts in /tmp on the server.
> 6. cvs is not seriously broken. It meets Symlabs needs pretty
> well and only occacionally behaves "mysteriously". It has
> strong culture and has widely available "googlebase" so you
> can get your problems solved. cvs never lost a file for
> us (though some users did by not fully understanding how
> it works).
Bully for you. Projects with large CVS repos that have been around for a while (FreeBSD, for instance) have experienced both repo corruption and other issues caused by changes in repo syntax over time.
Remember, by the way, that disks sometimes fail, and even RAID controllers have been known to silently corrupt data on the way to or from disk.