Introducing Subversion (SVN) Into Your Team
Posted by Dan | Posted in Automation / Scripting, Development, Subversion | Posted on 10-29-2011
0
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.




































