Manure alert! On Tue, Jun 23, 2009 at 02:16:39PM +0200, Hannah Schroeter wrote: > 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).
It isn't slow. I can check out a tree in a minute. Here is a nickel kid go buy yourself some real disks. > - 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. Oh I guess the cvsync tree I have on my laptop and all my development trees don't count. This is all uninteresting blabbing of someone who doesn't know how to use cvs. > > - 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. see previous. > > - 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). *yawn* > > - 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). Sure you found a nice feature but hardly killer or worth any downtime and relearning of some other retarded system that is full of unknown bugs. > > - 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). I do this all the time. You have no idea about cvs. > > - 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. I would never remember that. Not useful. > > - 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. Lear to commit with a proper procedure and you don't have to rely on hacks. > > - 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). Boooooooring > > >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. Now if it wouldn't shit itself all the time... > > 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!). Coordinate your commits; problem solved. These are the things people point at all the time but I never see them as an issue IN THE REAL WORLD. > > 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. Good for you! > > Kind regards, Thanks for your opinion, I now like git as much as I did before wasting my time answering this. > > Hannah.
