Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
My $0.02. I was encouraged to use svn over cvs for an open source project (perl module) that I work on. I did not have my source available via any internet-sharable repository. I was pleasantly surprised to see how easy it was to move to svn from cvs. Some differences that I notice are: - .svn directory in each "controlled" directory contains copies of all files (be ready to handle that when you have that perl script that modifies all the files in a tree!) The downside is the extra copy and what you can accidentally do to it. The upside is that I can be completely disconnected and still do svn diff...:) - tags -- I like tags in CVS better, because I feel it's more of a read-only snapshot. In svn it's a simple "copy" (which just updates it's database -- copying is VERY cheap) and people can checkout a tag, then update from there. I'm sure there is a way to make a tag read-only, but I haven't taken the time. I just don't want an accidental update to happen there. - mv / cp / rm operations are fully tracked in the system. I really like this. Java refactoring, renaming case-sensitive files and still keeping a history of where it came from and when is really nice. In practice, I haven't pushed this yet. - branching/merging -- Tony -- would you ever consider pushing your branching and mergepoint knowledge and efforts to SVN??? (doesn't that say enough?). Seriously, I know that's in the plans for svn, but right now you have to manually track your branches and merges. The recommended method is via log comments. That's going to cause issues and having true branching and mergepoints is what is needed. - setup: cvs has less dependancies and svn is *very* new and has dependancies on more updated packages (neon, bdb, etc), so I would expect cvs to setup faster and easier (and it does). You also have more options with svn, in terms of how to set it up, but I would probably always choose the WebDAV front-end and the associated extra work to set that up. - protocols & authentication: here's where it gets sticky. CVS supports *so* many protocols, but I still use :pserver:... My developers, when they need to get in from outside, use vpn to access the databases anyway, so it's not a significant issue for me at this time. Small network, small dev team. Authentication options for CVS are more straight-forward, but I honestly can't tell you if it has more options (out of the box yes, but read on). The authentication options for CVS seem better, but I haven't dug in. I will presume that the vast majority who will use svn will setup the apache WebDAV front-end, because that provides the most flexibility -- HTTP or HTTPS + all the mod_auth_xxx modules that apache provides/allows -- which seems to be a lot. There is a mod_auth_sspi, mod_auth_ldap, etc. That will probably cover many windows installations. Generally speaking, svn is on the right track, but needs some more soaking time and 3rd party support. I will use it for OS projects and might use it for more personal ones, but I'm not pushing it on my developers yet due to lack of IDE support in Oracle's Jdeveloper -- which I'm sure will be coming. When the stronger branching is there, it will be complete enough to replace CVS in many more areas. > > However, this is in no way a reflection on the fine work > that Tony has > > been > > doing with CVSNT. We have been very happy and much more > productive because > of > > Tony's extensions to CVS. It's just time to move on to the next > > generation > > system... I'd like to echo John's sentiments that Tony has done a fine job! I wouldn't be using CVS if it weren't for cvsnt and Tony's efforts... I'd still be using VSS (ouch). Regards, Jeff