David Abrahams wrote:
Walter Landry <wlandry@ucsd.edu> writes:
So it really sounds like you should see how well the new host works with CVS before committing to svn.
That's an interesting thought.
I wanted to comment, in backing the move from CVS to SVN, that I have found using SVN, particular with TortoiseSVN on Windows, immensely easier than using CVS, even with WinCVS. The fact that I can visually get the latest updates from any part of an SVN repository to any directory, that I can checkout from any part of an SVN directory to any directory, that I can commit at any level, that my copies, moves, and deletes are automatically picked up by SVN, makes SVN a no-brainer of a choice over CVS. I realize I do not know CVS nearly as well as I know SVN, but I do know that from the end user's perspective, SVN is sublimely easy to use and fairly easy to understand. I could never say that personally about CVS. That, even if all other things were equal between SVN and CVS, which I doubt given SVN's more integrated functionality, would be a good enough reason for me to switch from any CVS based system to an SVN based repository system, and I am very happy that the last company for whom I consulted, and the current company for whom I am employed, both use SVN. I have also found the SVN NGs, both the main one, gmane.comp.version-control.subversion.user, and the TortoiseSVN one, gmane.comp.version-control.subversion.tortoisesvn.devel, very helpful and responsive, and the documentation for Subversion and TortoiseSVN fairly decent. Finally another word about SVN. If using the Apache Server for the repository, as opposed to the SVN server, control of any path in a repository can be implemented. Without it, and using the SVN server, the only type of control occurs on the repository as a whole, which may be good enough if one wants to allow write access to a repository to a group of people, such as Boost developers, and read access to Boost users. Of course with SVN, one can set up as many repositories as one wants.