Hi! On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: >What is wrong with CVS? And no I am not talking about the hypotheticals >and some bugs that exist in the current code (that can also be easily >worked around).
- It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). - How often you've seen people (devs with commit access) do development without committing it because it wasn't ready for prime time, then committing it in chunks that can't be grokked any more because they have accumulated for months or even over a year? You can't have off-site development branches in centralized version control systems. You *can* with distributed ones. You can merge them *and keep history* later somewhat easier than without having distributed vcs abilities. - Non-committers can keep track of their local modifications in a more structured ways (because they can too have local inofficial branches) with a distributed vcs. So submission of patches can be more structured. - Did I mention: most current dvcs are *fast*. And you can usually mirror the repo (just as cvsync does, just you don't need an addon tool for it). - The history is still kept at a file level. While we see commit mails in a changeset form, if I want to look at what has been changed, I have to check per file (first cvs log, then cvs diff, or the equivalent thereof on the web). Even with svn I can do so with *one* svn log, then svn diff for the *whole* commit. With git I can do so with *one* git log -p for the whole commit (no further diff operation). - Disconnected operation. With cvs I can do nearly nothing (related to version control, that is) offline. (Devs working on the plane, anyone?) With svn I can just check the status and the diff against the *current* pristine version. With git, for example, I can inspect the *whole* history up to now, and I can create new structured history from now. The only thing I can't do offline is get new history from others (upstream or other devs or other users) or export my new history (to an official repository or "peer-to-peer" to other users/devs). - Sometimes even little features like git stash (put away uncommitted stuff for a moment in order to do something else, but ready to be retrieved again) or git add -i (prepare to only *selectively* commit changes) come handy. - Oh, when I notice a mistake immediately after the fact, I can (a)mend it with git up to the moment I exported my history! Less of "oops I committed this port to the wrong place". Of course without having to completely *manually* hacking the repository tree. - For versioning local things (like /etc), I don't need to dedicate a completely different place for the repository. One .git directory is good enough for everything (where cvs needs a CVS/ directory for every directory in the working tree *and* a separate repository directory hierarchy). Same gripe about svn, btw (a .svn in every directory in the working directory, even more bloated than cvs, and a separate repository tree, also quite fat). >I have used just about all versioning systems, including ones that have >the price tag of islands in the pacific, and ultimately they all suck in >their special ways. CVS works "well-enough". I beg to differ. I was somewhat relieved when we switched from cvs to svn at work (for our work projects). svn does suck, too, of course. For example, non-first-class tags and branches, big overhead in its working copies, and it's slow too, but at least it has real versioning across directory *trees*, so operations like ... log and ... diff actually make sense, you can actually look at the history in a tree/changeset granularity. Nowadays I still scorn svn here. But at the same time, I dislike cvs more. cvs up -APd on /usr/src, or /usr/ports is just *so slow* even with a *local* (cvsync) mirror. Even with async,noatime mounts and export CVSREADONLYFS=1. cvs commit is slow (and non-atomic!). Nowadays I use git-svn to make working with the company's svn service a bit more bearable. And I profit of the ability to keep local branches, to exporting new history at a time when *I* see fit, etc. Kind regards, Hannah.
