Introducing Subversion (SVN) Into Your Team

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.