|There's more than one way to do things|
Re: [OT] Advanced CVS usageby hacker (Priest)
|on May 29, 2003 at 18:28 UTC||Need Help??|
There are several problems with Subversion in its current state, which prohibit people using CVS from migrating over to it (yes, my asbestos flamesuit coveralls are zipped up tightly):
There are really only a couple of things stopping CVS from being better; atomicity at the directory level, and finer-grained control over access methods. Now with CVS having ACLs and no need to have local user accounts to have protected access to repositories, that is not such an issue. You can also have anonymous ssh access to repositories if you wish.
There's two schools of thought about the ssh vs. pserver security "problem".
There are good points and bad points to either approach, but in the long run, using pserver is much safer for the code and for the server and the user's account itself. Not only is that password not the same as any other password that the user has, but since they don't have a local account on the box, getting that password gets the attacker absolutely nothing of value.
The atomicity can be an issue, if you don't know what you're doing. I've done major CVS surgery on directories, file renames, moving entire trees of directories under other subdirectories, and so on.. without losing a single byte of the historical data. It's possible, but it takes a bit of planning to get right.
That being said, Subversion looks good, but until someone can cleanly, seamlessly, and securely use it on a box that does not require a local account or a webserver, with the ability to import an existing CVS repository into it (full historical data intact), it will not catch on as fast as people hope.
CVS is well-seated, and lots of very high-volume projects use it, and continue to use it every day, including myself. I've wrapped a lot of tools around my public repositories to help developers manage their code better (4 different web-based code view/diff/graphing tools, cvs statistics pages, and other tools that enhance the usability of the repositories themselves), and these things just don't exist for Subversion. I'm sure that in a few years time, they will, but right now, it would be traumatic to migrate existing codebases over to Subversion.
YMMV though. For a completely new project where security isn't an issue, Subversion may be a perfect fit.