[gkya]

For my use case, it's way more preferrable:

a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex.

b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS repo preserving it's history: move the ,v files to $CVSROOT/$MODULE/.

c) The repository model of CVS is as transparent as it gets.

d) The keywords like $Id$ are really useful.

e.g. I keep my system configuration in "~/Checkouts/system-config", and I have a script that cp's the files to appropriate locations using a map file. When I'm not sure if the active config is not up to date, I can verify very easily. And I can be sure that dirty files won't be active as long as I don't expressly copy them. I know that SVN has this too, but I find CVS easier to use in general.

I guess for fast paced, very active development, yes CVS is sub-par, but for personal stuff, or for something that is patched say at most two-three times a month, it's O.K. It boils down to personal preference.

[aidenn0]

SVN is way simpler at the interface than CVS, you should really look into it. SVN is a spiritual successor to CVS, and is trivially easy for a CVS user to pick up. We switched from CVS to SVN at work several years ago and everyone was happy with the change.

[zwischenzug]

We did the same and plenty were _unhappy_. In the end git took over.

There were plenty of things I didn't like about SVN (separate folders per branch? yuk), having used CVS, and didn't find it 'trivial' to pick up.

[aidenn0]

Really, it's hard to handle branching worse than CVS does, and if SVN doesn't do a stellar job either, I don't see it as a barrier to switching.

[jfoutz]

there are two things that are nice about svn if you use it just like cvs.

1, atomic commits. I edit ten files, that's one checkin, rather than the per file checkins of cvs. On a low volume project, not a big advantage. if you've ever conflicted on a bigger project with cvs, it can be kind of a pain to resolve. seeing the whole commit of the other guy is helpful. If you don't run into this more than, say, monthly, it's not worth it.

2. offline diffs. svn has a whole copy of the repo, so you can compare history even if the central repo is down, or you're working from the beach. This one is pretty nice regardless.

svn is a pretty nice upgrade, if you're working with a distributed team.

[gkya]

All appreciated, but nowadays my biggest repo is my emacs config, some tens of thousand SLOCs, about 2000-2500 of which I authored (I commit packages I use too, no elpa). And my repositories are local, i.e. they are in /var/cvsrepos. Other than that, I admit that SVN is indeed superior.

I believe that one should use the best tool for the case, not the overall best tool in every case.

That said, I'll give a look at SVN. I can consider switch when I have the time if it is easy to import from RCS, because I do use it a lot here and there, mostly for plain text documents. I do not like maintaining unrelated things in a single repository.

[jfoutz]

If it's just you, everything is local, it's probably not worth the overhead. Sounds like you have a good, efficient setup.

If you're learning for the sake of learning, i'd dig into git. i'm getting better, but some cases still frighten me.

[gkya]

> If you're learning for the sake of learning, i'd dig into git.

Well, nearly everything moved to git. I've used it for a while, mostly commit/pull/clone. I actually moved to CVS from git :) It's a bit like perl, git, you either need to be an expert at it, or else you can get going, but at the end you create a mess.

> [...] it's probably not worth the overhead. Sounds like you have a good, efficient setup.

Mostly, yes, but mostly because I don't really need that much more than recording my history, and occasionally looking at what I did in the past and more rarely working on short-lived branches. But there are a couple tools that if I ever code them up, I will make opensource. Tho if I ever do, and they take on, I'll use a 'just send a patch on the mailing list' approach. I believe it's easier to deal with. No flamewars on VCSes :)