While I was away in Tokyo, NTTMCL switched from CVS to Subversion for their version control system. Perhaps it is just that I'm too accustomed to CVS's eccentricities, but so far I have to say the Subversion sucks. While I'm sitting here waiting for the checkout of one of our heavily-branched repositories to complete (45 minutes and counting!), I took the opportunity to read a little about how much more wonderful Subversion is than CVS.
So far, the best I've come up with is that Subversion is newer, therefore it is better. Yay. With subversion, I just get the delight of knowing I'm playing with a fresh(er) turd.
Sure, CVS sucks too. What bothers me about Subversion is that it sucks at least as much as CVS without giving anything in return. At least with CVS, I can tag a release or create a branch without having to make a whole other copy of the repository (on each developer's machine, no less!). At least with CVS, I can diff and merge files between branches or tags without developing a Repetitive Strain Injury. At least with CVS, the repo files are text so I can recover when it screws up. At least with CVS, I don't have to run a friggin' web server just to do revision control.
So, yeah, maybe I'm just an old fogey. Or maybe Subversion sucks so much, it actually makes me long for CVS. Wouldn't that be sad.
7 comments:
I must admit that I have found 'svn merge -c' to be far easier for doing MFC's of changes in FreeBSD since switching to subversion. However, the merge intelligence even with mergeinfo is still far inferior to that of p4.
I do find that I still use cvsweb on the replicated CVS mirror of FreeBSD to track changes across branches. It is not as easy with svn web UIs to see which changes have been merged to branches.
I have also found svn to be slow over NFS if the NFS server is overloaded. With a more functioning NFS server it is not too bad, but still slower than 'cvs up' or 'p4 sync'.
However, at least it supports sub-tree checkouts unlike git. :)
@Ben: Holy smoke, SVN requires a book? I learned CVS from the info/man pages. I guess I better start cracking.
Judging from your comment, I think you missed the point of my complaints regardining SVN. For example, my complaint with merges in subversion was that it requires a ton of typing (hence, the RSI reference). Typing -j OTHERBRANCH isn't nearly as long as typing http://svn.example.com/myrepo/OTHERBRANCH. In other words, I find URLs bad identifiers for branches. Especially when you consider that you can't diff against branches in other repositories, having to type out the FQDN of the repository server, the path to the respository, heck even the access protocol, every time is overkill.
Yes, I praise CVS for having a system that human beings can inspect and, if necessary, manually edit. Just like I prefer my documents to be human-readable rather than binary blobs. You do hear people saying "I won't use Word because, you know, I can't read its DOC files".
FYI, I've never used CVS's pserver. Every organization I've even encountered used SSH to access their central CVS server. SVN doesn't offer anything as secure and yet easy to use as CVS+SSH. Unless you'd suggest subversion's credential cache, hah.
But I guess you would have known all that if you had ever used CVS. Anyway, I'd say that I was sorry I offended you by pointing out deficiencies in your favorite VCS system.
All I was saying is that I was surprised that for all the effort that went into a "CVS-killer" I'm amazed they managed to produce someone merely on-par with CVS. It seems to me that, for everyone 1 thing subversion improves there is 1 thing is does worse. And, unfortunately, your comment did nothing to dispel that impression.
@John: Thanks for the informed feedback. I too found myself comparing subversion against perforce and found it coming up short. I guess that isn't a big surprise since perforce is pretty pricey.
I think the thing that has really surprised me is that subversion isn't better than it is. I suppose that explains the proliferation of alternative VCS software in recent years.
So we're using subversion at work now and I guess I have to get used to it. But for my personal repository at home, I'm still using CVS. Perhaps I should switch it over to git or mercurial, though, just for the opportunity to play with those (even if I am the only developer).
@Ben: Just to follow-up to my own reply-comment. Since posting my previous response, I learned you were one of the designers of subversion. I can understand your eagerness to defend it now. :)
I'm sitting down reading the SVN book now. Coming from a background where revisions were an extra dimension from the directory hierarchy, the subversion approach of integrating revisions into the directory hierarchy feels hackish, but I suppose I'll get used to it. It does explain why checking out the root of a project is taboo in subversion but not in CVS (for the record, no one checks out the root of a repo unless their repo consists of only 1 project, so your comment to that effect was a strawman attack).
Doing it wrong? Hmm... I have read the book, and my experience over the last 4 years or so I guess is that the problems outweigh the advantages. Back compatibility or lack thereof being one issue - the server changes versions and all my development tools refuse to talk to it, my existing workspaces are left hanging in the wind and need to be re-checked out - not to mention that 'choices' in connectors for eclipse - The fact that eclipse doesn't just svn out of the box without all the installation hassle is crazy too. I only need to install it when I change eclipse versions, which is infrequent and when I do upgrade I have to spend at least 2 hours getting it re-installed. I'm looking for a good alternative now - any suggestions folks?
At the company I work for we have been using cvs for many years. We maintain a multi million line application and often have 4 or 5 teams of 6 developers a team working on different branches of the same code at the same time and then merging.
I don’t get all the bad press about cvs. If you are diligent about tagging your code in preparation for merging it works almost flawlessly. We do some very harry things like merging from branch to branch, merging from the head back to the branch, and then even merging back to the head again. As long as what you are doing is logical cvs is right there with you. I also love how with the eclipse plugin cvs allows you to preview differences between merging them locally, and the review history of the file in line if you desire etc.
So, we have just recently switched to svn. I hate svn already, and all of the book reading about it is just convincing me more what an overrated piece of crap it is. The main thing wrong with it is that it tries to do your merging for you, and keeps its own list of what you’ve already merged. Gee, that works great in simple situations where I am bringing a single banch to the head. What happens when my teams branch needed some code from the head for this effort and then we want to merge other code back again. How do we block out those differences from bouncing and showing us a bunch of weird conflicts.
Svn simply does not give you the control you need to do advanced things, and it will automatically hide diffs from you that it thinks you already merged. Back out a merge and decide to merge it again later for instance. Svn doesn’t like it and it will fight you every step of the way. Even simple thinks like deleting a directory gives svn fits.
Svn doesn’t allow the true previewing of merges. Instead it insists that you merge and then requires you to perform surgery on any conflicts that it decided to make spaghetti out of.
Stick with CVS. There is reason its been around for the computer business equivalent of eternity, because it works damn good.
Try git, with git you get decent branches and you can checkout or clone the root of the project, instead of having to append trunk/.
Not to mention that you can still work while the main repository is down, because you have your own copy of the repository.
Post a Comment