Here’s a listing of items that may be of challenge when introducing it to a team who has no previous SVN experience. Version control is a rewarding experience, and once you get the hang of it, you’ll be wondering how you lived without it.
1. (Most) everyone using SCM for the first time. Have to be familiar with: a. Subversion concepts i. Terminology ii. Best practices b. Tools: i. Tortoise Concepts ii. Subclipse (Programmers) c. Quirks i. Sometimes the icon overlay won’t show in Explorer ii. Thumbs.db file can make the status of the directory misleading iii. Updating code in MacOSX’s finder can corrupt the SVN metadata because a native SVN shell (e.g. Tortoise) isn’t being used. d. Troubleshooting (I sent out a list of 10+ SVN issues and how to troubleshoot) i. What do you do when you get this type of error? e. Undoing the way things were done before an SCM tool was used 2. SVN Performance a. Performance of the SVN repository is dependent on use i. If programmer-A does intensive SVN operations, like checkouts, it slows down operations for everyone else – programmer B has to sometimes up to 20 minutes to view the revisions of 1 file. b. Performance of SVN client is dependent on network 3. Development Workflow between all members 4. Deployment to STAGING + PRODUCTION a. A better process for deploying to STAGING: i. If a change set that has to be deployed to STAGING is small (e.g. <10 files under 1 folder), it can be done manually, which takes seconds. ii. If a change set is large (10 files, however, dispersed throughout a code base), gets more error prone (done by hand) and is better done through automation.